[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] New experimental build system using CMake
From: |
al davis |
Subject: |
Re: [Gnucap-devel] New experimental build system using CMake |
Date: |
Tue, 21 May 2013 03:57:41 -0400 |
User-agent: |
KMail/1.13.7 (Linux/2.6.32-5-amd64; KDE/4.8.4; x86_64; ; ) |
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.