Re: [Gnucap-devel] autoconf-WIP branch

[Kevin Zheng]

On 07/19/2013 21:59, Felix Salfelder wrote:
>> I still have issues with the complexity and clutter of 
>> autotools, which is why don't want to make it the only way.
> 
> the more options, the better.

I don't think the clutter should be a big deal; autotools is a mess, but
git is good at cleaning up the resulting pile of junk. Users who aren't
tracking the sources in git probably aren't going to hang on to the
sources after a successful compile/install, anyways.

>> 1. Is there a way to hide the clutter?  Files like config.guess, 
>> depcomp, ....  These really shouldn't be up front where they are 
>> the first thing people see.  Can this stuff be in a subdir 
>> "autoconf-generated-files"?
> 
> until now, i haven't found anything. apparently nobody else cares
> since i'm short on time right now, i'd prefer to make it work and change
> aesthetic aspects later.

Not that I know of; but you can quickly dispose of it with git clean.
CMake is nice enough to let you do the build stuff in a separate folder.

Speaking of CMake and the resulting build system wars, I think it's
important to have around some 'common' build system that a few people
here and there have worked with. This makes package/port maintenance a
lot easier and gives you a better chance to git the user something
he/she knows how to work with.

>> 3. The essense of the "old" system, which predates autoconf and 
>> was never intended as a complete system, is a 3-part Makefile, 
>> that splits the program specific part (Make1), the requested 
>> (generated in this case) configuration (Make2), and a part that 
>> is always the same (Make3).  An equivalent of "configure" would 
>> generate Make2 and cat the 3 parts.  Autotools seems to scramble 
>> it into an unreadable mess.  How about using autotools to 
>> generate Make2, and allowing a Make1 to be used without 
>> processing?  This would allow users to configure the apps, and 
>> provide a base for compiling plugins.

Based on my inexpert opinion, I *think* it's worth the while to work on
a new build system. The autoconf documentation warns against 'custom'
configure/build systems for multiple reasons, you can find it here [1].

> some things are a pain to do with static Makefiles/Cmake/whateverelse.
> but that doesn't mean autotools is a requirement. i'd like to focus on
> the user, who will never have to mess with the internals.

Although I'm certainly biased, I think using a well-known build system
makes it easier for users and maintainers.

Thanks,
Kevin Zheng