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

2010/1/26 pancake <pancake_AT_youterm.com>:
> Anselm R Garbe wrote:
>>
>> What about the good old way of providing one master makefile for each
>> platform instead of these scripts that are doomed to fail anyways
>> sooner or later?
>>
>>
>
> It's not only about platform, for small projects i find single makefiles ok,
> but for big ones you need to separate the configuration/build steps, because
> you need to get information about which libraries, include files, programs,
> etc.. are in the system. In some situations just create a .mk file with such
> information, but you will probably need to export some of the information
> into a .h file.
>
> Sometimes the configuration step is not as simple as run this and tell me
> if it works or not. This makes a shellscript much more manageable than
> a makefile, because it's not a task of the make and you end up forking from
> make which is inneficient and ugly to maintain.
>
> About having one different mk file for each platform..well I always find
> anyoing
> to have to maintain N files that does the same, or for building..it's a mess
> for packaging because there's no standard on this, and automatize the
> build or do some packaging becomes a mess.
>
> You get the package and you have to spend few seconds to identify which
> makefile you have to use, and then if you get compilation errors you have to
> guess which dependencies are missing. then you can try to find INSTALL or
> README files to see whats missing or try to fix the program if you get that
> its not a dependency problem. So this makes the build process simpler, but
> less error-prone and more annoying for packagers and users.
>
> The only good thing from autotools is that they are the standard, and this
> hardly simplified the steps of development, packaging, compilation and
> deployment. This is: make dist, make mrproper, automatic detection of
> file dependencies, check for dependencies, etc.
>
> For suckless projects i dont find logic to use such a monster, but for big
> projects it is many times a must. Because you end up with conditional
> dependencies, recursive checks to ensure consistence of a program, etc.
>
> If you have a build farm or any massive-compilation environment, you expect
> that all the packages are going to build and react in the same way. But this
> is not true. There are some basics in the software packaging that not
> everybody understand or know.
>
> Things like sand-boxing installation (make DISTDIR=/foo), cross-path
> compilation (VPATH),
> optimization flags detection for compiler, make dist, etc. are things that
> many of the
> makefile-only projects fail to do. I'm not trying to say that those are
> things that all
> packages must have, but it's something that standarizes the build and
> install process,
> and simplifies the development and maintainance.
>
> I wrote 'acr' because i was looking in something ./configure-compatible, but
> lightweight
> and simpler to maintain than the m4 approach. It works for me quite well,
> but I try to
> only use it for the projects that really need to split the build in two
> steps. For building
> in plan9 I just distribute a separate mkfile which doesnt depends on the
> configure stage.
>
> But plan9 is IMHO a quite different platform to not try to support it from
> the acr side,
> because the makefiles should be completely different too.

Well I've heared these reasons before and I don't buy them. There are
toolchains like the BSD ones and they proof pretty much that the
"everything is a Makefile approach" is the most portable and
sustainable one. Running a configure script from 10 years ago will
fail immediately.

I know that your problem vector is different, but I think reinventing
square wheels like autoconf again is not helping us any further. And I
really believe that sticking to mk or make files in large projects
saves you a lot of headaches in the long term (think years ahead, like
10 years or so).

Cheers,
Anselm
Received on Tue Jan 26 2010 - 10:06:44 UTC