Re: [dev] [OFFTOPIC] Recommended meta-build system

On Jan 30, 2010, at 3:58 PM, Uriel <lost.goblin_AT_gmail.com> wrote:

>>
>
> Plan 9 solves this, the standard set of mkfiles you can use are
> described here: http://doc.cat-v.org/plan_9/4th_edition/papers/mkfiles
>
Will take a look. Thanks
>
>> The configure stage is in many situations innecessary, but its just
>> a way
>> to do different actions to 'configure' the project. This is:
>> - detect libraries, programs
>> - check for endianness
>
> If your program needs to check for endianness, it is broken, period.
>

Really?

>> - check cpu
>
> If your program needs to check for cpu, it is probably broken, and if
> not, it will break cross compiling and it should allow building
> versions for each architecture no matter what the current environment
> is, ideally as the Plan 9 compilers do actually implemented as
> independent programs.

Think in a crossplatform debugger/profiler. You need to know the CPU
and the OS otherwise is not portable.

>
>> - check for include files
>
> This is hopeless, the only proper solution is to provide somewhere for
> the user to manually define where to find include files and libraries,
> otherwise your program will be unportable, unless magically it can
> predict where any system ever created in the past and future will have
> its headers, which is impossible and is why auto*hell ends up failing
> miserably at finding shit.
>

There are standard ways to place and locate include files. It's not
that cathastrofic at all.

I hate programs failing at compile time. A simple check to cache paths
for incldes, files,.. Can make the build cleaner and faster.

>> - check OS (target,host,..) useful for crosscompiling
>
> Why the fuck does one need a configure step for crosscopiling?
> Actually not having one makes crosscompiling infinitely more sane and
> convenient.

Did you ever compiled a compiler and have specified different host,
target and build profiles? Tell me how can you set those options
outside the configure stage.

Note that this stage doesnt needs to specially be a ./configure script.

In dwm you also have a configuration stage, but it is not a
shellscript. It's just manual hack of mk and .h files which is also
ok, but still a configuration stage.
>
>> - check for system-related libraries to fit certain features (-
>> lsocket in
>> solaris. fex)
>
> If you depend on system-specific features your code is not portable,
> period, and pretending otherwise is madness.

Think on a profiler or a debugger. Or just any piece of code that is
not posix you need to change the build stage to adapt to the system.
This is.. To compile other sources or change include path.
>
> Also note that all kinds of build time 'configuration' exponentially
> increase the difficulty of testing and debugging as you basically stop
> being a single version of your program, and instead you have one
> version based on what features happen to be 'enabled'.
>
Suckless software promotes patches, which is ok for small programs.
But for big ones you usually want to simplify the compilation by
setting up the build with some options easily defined by a single line.

Which is easily integrable in many build systems. Probably more than
replacing files or changing environment variables. Which makes errors
and problems appear if trying to cmpile without the correct env

> Also this encourages #ifdef 'pseudo-portability', which is *always*
> the *wrong* way to do it.
>
Yeah, but how you drop ifdef without a way to change the makefiles to
use other files depending on some options.

>> If you have to do all this job for every project you do.. you will
>> probably
>> fail at some point. This is why is good to have a centralized
>> project that
>> generates the proper checks to get all this information in a way that
>> works on most of systems and most of arquitectures.
>>
>> If you find a problem in a certain arquitecture you just need to
>> fix it
>> in one point, not in all your projects.
>>
>> The problem is that GNU configure sucks, is slow, is dirty, is
>> bloated, is
>> full of weird hidden features and lot of collateral issues can
>> easily appear
>> which are really hard to debug.
>
> This is completely wrong, the problem with auto*hell is not the
> implementation, but the concept and idea itself, the implementation
> sucks so much mostly as consequence of how idiotic and retarded the
> idea is.
>

I still think that a configuration stage is useful, but I think that
an neither make, sed or configure are the right ways to do such step.

But until nobody does it right we will stick discusing as trolls about
that.
Received on Sun Jan 31 2010 - 21:16:29 UTC