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

On Sun, Jan 31, 2010 at 10:16 PM, pancake <pancake_AT_youterm.com> wrote:
>
>
> 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?

Yes, really, any competent programmer should know how to write
portable code that works fine no matter the endianness of the host.

>>> - 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.

Wrong again, doubly wrong even, a crossplatform debugger/profile has
even more reason to not care what environment it is built under,
specially if it is sane enough to allow transparent access over the
network to work on processes running on other machines that might run
a completely different architecture.

For example, see acid: http://doc.cat-v.org/plan_9/4th_edition/papers/acid

>>
>>> - 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.

There are retarded standards for all kinds of crap, too bad that there
are thousands of standards and nobody follows them anyway.

It is simple, the system user knows much better where shit is than the
developer can dream knowing, if the developer tries to guess he will
invariably fuck it up and waste even more of the user's time.

If you want pre-chewed software, use whatever packaging system your OS
provides and let packagers deal with this, expecting the original
software developers to do it is extremely naive.

At most the source might include a set of system-specific makefiles
that are known to work on certain given systems and let the user pick
which one to use or customize as needed.

> 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.

Please, do not insult my intelligence and do not make me do all your
homework: http://man.cat-v.org/plan_9/1/2c

Just because you are used to terminally braindead software doesn't
mean that software needs to be that way.

> 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.

No, it is not OK, the gratuitous fiddling with the .h files is one of
the most retarded things about dwm.

And I'm done with this discussion, I have provided more than enough
references to show software doesn't need to be built in totally
retarded ways that require totally retarded 'configure' steps.

uriel

>>
>>> - 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 - 22:00:58 UTC