Make, Automake, Configure, Autocong, GPRbuild etc (was: Why no socket package in the standard ?)

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Dmitry A. Kazakov wrote on comp.lang.ada:
> On Fri, 27 May 2011 07:46:43 -0400, Stephen Leake wrote:
>> Ludovic Brenta writes:
>>> Adam Beneschan writes on comp.lang.ada:
>>>> Ludovic Brenta wrote:
>>>>> Yannick Duchêne wrote on comp.lang.ada:
>>>>>> Peter C. Chapin a écrit:
>>>>>>> It also true that autoconf is a travesty... a throwback to a
>>>>>>> darker age when the POSIX standard did not exist (or at least
>>>>>>> was not widely implemented).
>>>>>>
>>>>>> I do not know that much about Autoconf, so I can't really
>>>>>> understand what that mean and implies (someone else here
>>>>>> also say a bit the same as you too).
>>>>>
>>>>> Make was invented to overcome the deficiencies of C, notably
>>>>> the lack of modular programming and dependency management.
>>>>>
>>>>> Automake was invented to overcome the deficiencies of make,
>>>>> notably the poor maintainability of Makefiles.
>>>>>
>>>>> Configure was invented to overcome the deficiencies of early
>>>>> UNIX systems, notably the lack of conformance to POSIX, and
>>>>> their impact on the maintenance of Automake files.
>>>>>
>>>>> Autoconf was invented to overcome the deficiencies of
>>>>> Configure, notably the sheer size and horror of the configure
>>>>> scripts, which routinely consist of hundreds of thousands of
>>>>> lines of illegible POSIX shell code.
>>>>
>>>> I was going to ask what was the invention to overcome the
>>>> deficiencies of autoconf, but I think I figured it out ...
>>>> rm -rf, right?
>>>>
>>> Opinions differ but I'd tend to side with you :)
>>
>> No! Ada and gprbuild :) we finally got it right :)
>
> No, it was only one step forward. There are still mseinstall,
> rpmbuild, dpkg mess around there.

I think it is appropriate to separate the building of the binary
software from the packaging for a particular target platform.  For
starters, the author of the software does not necessarily have access
to all target operating systems.  The package maintainer requires
intimate knowledge of the target operating system, its package
management system, its policies, the names of existing packages, etc.
These are different concerns best addressed by different build
systems.  The things you mentioned (mseinstall, rpmbuild, dpkg)
naturally sit on top of the build system provided as part of the
software source distribution.  I don't think they should be merged.

That said, simplicity in both the build system and the packaging is of
course a Good Thing.  In Debian I've taken that approach to extremes
at times, bypassing the fragile Autoconf-based build system of some
software and replacing it with a single GPR project file and a couple
of rules in the packaging Makefile.

--
Ludovic Brenta.