Re: [Gnucap-devel] Autotools build system

[David Fang]

Hi,
	I'd be very interested in helping with this effort.  The last time 
I did anything about it was a few years ago, until I got distracted with 
school (a rather long distraction, at that).
	Is the latest snapshot a good place to start, or has there already 
been some work offline?

> On 6/8/2009 7:44 PM, al davis wrote:
> > On Sunday 07 June 2009, Kevin Bowling wrote:
> >
> > > I would like to fix up the autotools build system and address
> > > any short comings Gnucap is having.  You've said before that
> > > it is broken or not optimal.  Can you list any specific
> > > cases?  I will post patches to the list when this work is
> > > complete.
> >
> > In spite of that, I acknowledge the need for it, and feel that
> > for now there is no alternative, as I look with trepidation at
> > updating the gnucap autoconf system as is needed for plugins.
> >    What is needed now is update of both versions to properly handle
> > plugins.  Also needed is a refactoring of code separating core,
> > includes, main, and plugins.
> Indeed, autotools are not a magic bullet.  However, maintaining our own build 
> system seems unnecessarily time consuming.  It also will make it hard for 
> users to build Gnucap on platforms we don't have access to.  A lot of this 
> comes free with auto*.

I've still been using autotools actively over the years; I'm more than 
happy to help write or test.  But yes, architecting the organization of 
features is paramount, regardless of build system.

> Having two build systems is both confusing to users/developers and 
> cumbersome.  My vote is to take the time now and fix one or the other, and 
> only carry it in the default package.  I have confidence that autotools can 
> be made to work since many complex projects make use of it.

> > Henrik suggested making most of the core a library, with a very
> > minimal main program.  I agree that we need to do at least what
> > Henrik suggested, most likely more.  Since we are rearranging
> > anyway, it is probably appropriate to do it now.
> These two items need to be elaborated on.  Do you have any idea what parts 
> you'd like to handle, and what others might do so we are not stepping on 
> toes?  Perhaps we can do task assignments with a system like I am using to 
> run the + project, or something else if you prefer (Gnucap wiki?).

> > I consider choosing which plugins to static link to be something
> > a regular user building the program should be able to do.  This
> > is not supported by autotools as far as I know.

Is there a compelling reason to force plug-ins to link statically?  They 
work very well dynamically.  Won't configure --disable-shared do the 
trick?

> I believe we can set conditionals.  For example, in configure.in:
>
> AM_CONDITIONAL(STATICPSS, test "$enable_staticpss" = yes)
>
> When the user specifies ./configure --enable-staticpss, this variable will be 
> passed to the Makefile.
>
> In the plugin directory's Makefile.am (gnucap/plugins/pss):
>
> if STATICPSS
> lib_LIBRARIES = libpss.a
> libpss_a_SOURCES = pss.cc
> endif
>
> In the main Makefile.am:
> if STATICPSS
> gnucap_LDADD += $(top_builddir)/plugins/pss/libpss.a
> gnucap_CPPFLAGS += -I $(top_builddir)/plugins/pss/pss.h
> endif

And you might list conditional dependencies (libtoolized) like:
EXTRA_LTLIBRARIES = libpss.la

so the tools know statically, the set of all possible libraries.

> This is a bit simplified, but I think a solution using something like this 
> would be elegant.  We would need to set defaults for which modules to build, 
> but could also parse --disable-<x> statements to remove core static modules.

For features, AC_ARG_ENABLE lets you declare defaults in the optional 
trailing argument.  As does AC_ARG_WITH, for dependencies.

> > The installation needs to produce something like this:
> > - a main executable, installed where executables normally go.
> > - includes, installed where includes normally go
> > - plugins available system-wide, intalled like libraries.

I would recommend pushing plug-ins into pkglibdir, to make it clear that 
they go with gnucap.  (I even do this for regular shared libraries.) I 
also push include headers down a directory, into pkgincludedir, to 
minimize clutter in the installed space.  It makes it easier to isolate 
include paths per package.  A bin_SCRIPT like 'gnucap-config' would report 
the locations of these files accordingly (--cflags, --libs).

> Seems easy enough by making use of PREFIX and such during make install and 
> directing files where they need to go.
> > - each plugin must be considered separately
> How will dynamic plugins compare with static?  I suppose the conditional 
> system could be used here as well.  They would be dumped in 
> {PREFIX}/{LIBDIR}/gnucap.
> > - a simple way to build user plugins with a simple Makefile
> > - a place for things like spice-wrapper.cc and the plugin Make2.
> Can you elaborate details on these requirements.
> > Is this enough to get you started?
> Yes.  It looks like we will have to discuss my questions and comments before 
> proceeding.
>
> Regards,
> Kevin

Eager to hear further developments!


Fang


David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/