Re: New experimental build system using CMake

On Friday 10 May 2013, Kevin Zheng wrote:
> While I was working on updating the version of Gnucap in the
> FreeBSD Ports Collection, I realized that I didn't really
> like the existing build system, for multiple reasons.
> Feeling adventurous, I cloned the repository and tried to
> set up a build system using CMake.

> I know that build systems bring big changes (and
> dependencies), but I would like the project to consider the
> prospect of moving to a simpler, more elegant build system.

Thanks for trying it.  I don't really like the existing build 
system either, but to be honest I have never found a build 
system I really liked.

I looked at CMake a while back.  In most ways I thought it was 
better than autoconf.  It is certainly "simpler" and "more 
elegant".  The big problem with it, a show-stopper for me, is 
that it introduces a new dependency.  Everyone would need to 
have CMake installed to build the package.  As it stands, and I 
would like to keep it this way, Gnucap has no dependencies other 
than a working C++ compiler.

Having said that, if you are willing to maintain it and it's 
just one file (or one per subdirectory) I would not have a 
problem with including that file so those who want to use CMake 
would be able to use it.

Autoconf attempts to address the issue of the additional 
dependency by pre-generating a script and including parts of 
itself every time.  So, to most people just compiling the 
program to use, it seems to solve that dependency on itself.  
The price is a bunch of files (10?) in the most visible project 
root of every project.  To someone who is not well versed in 
autotools, these files might as well be non-text object files.  
To a developer, it does create an additional dependency.  
Actually several of them .. autoconf, automake, libtool, ...  So 
that advantage that Autotools has over CMake is only to a casual 
user who doesn't want to do anything fancy.

The use of autoconf has been on-and-off several times, and has 
been trouble-prone for a long time.

Packagers (the people packaging programs for distros) like and 
need these tools.  On the original development side, they really 
get in the way.  To a casual user installing from source, 
autoconf usually gives ton of cryptic blabber that is hard to 
decipher.  

I think I have a pretty good idea what is needed. I just don't 
have the time to do it.

Some basic requirements ....

It is not acceptable to require another configuration for each 
additional plugin.

The "apps" subdirectory is really a collection of plugins, the 
ones loaded by default.  Changing that list of files is 
something a casual user might do.

When complete, building plugins from source is an activity that 
will be done by regular users.  Anything required to build 
plugins is considered a RUN TIME dependency for gnucap.