Re: [Gnucap-devel] New experimental build system using CMake

[Felix Salfelder]

Hi Al.

On Tue, May 21, 2013 at 03:57:41AM -0400, al davis wrote:
> Autoconf [..]
> To a developer, it does create an additional dependency.  

this one is true. don't forget that this is pretty much standard, like
a compiler or a linker.

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

i've never read about the trouble part on this list. (im not saying
problems cannot exist).

> 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.  

nowadays, the casual user installs software using the package manager of
her/his favourite software distribution. a casual user, who installs
from source knows how to quickly install autotools, as (s)he needs that
for most software. gnucap should focus on users, not developers.

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

i've implemented most of it. it's in the autotools-WIP branch. tell me
whats wrong with it, or just ask me to merge it into master.

> Some basic requirements ....
> 
> It is not acceptable to require another configuration for each 
> additional plugin.

plugins within the gnucap source tarball are configured together with
gnucap (of course?). to compile plugins outside the gnucap tarball, we
should add a small gnucap-plugin-compiler script that turns .cc into
.so. i havent bothered to implement it, but a similar script is included
within gnucap-adms, turning .va into .so.

> 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.

so the configure script needs to implement different presets for plugin
collections (or even single-plugin {in,ex}clusion). this is trivial to
do, but absolutely lowest priority (to me).

> 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.

so let's call a shell, the compiler/linker and maybe make a run time
dependency for gnucap. what are the implications on the build system?

i've been compiling plugins (on the "regular user" side) for quite some
time now. all that is needed for this is the header files (+ the shared
library in the latest release) installed correctly (which again has
nothing to do with the build system).

regards
felix