On Jan 30, 2010, at 3:58 PM, Uriel <lost.gob...@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.
