W3C home > Mailing lists > Public > www-amaya@w3.org > October to December 2006

More questions abour the build system

From: Régis Boudin <regis@boudin.name>
Date: Sat, 14 Oct 2006 20:42:12 +0100
To: www-amaya@w3.org
Message-Id: <1160854932.10259.33.camel@localhost.localdomain>
Hi,

I've been digging a bit through the build system, trying to clean up
things a bit, and I have a couple of remarks/questions :

1/According to what's in the configure.ac, plugins are not supported
anymore. Would you be interested by a patch getting rid of references to
it in in configure/Makefile.in files ?

2/ I noticed that the redland RDF library is only used with the
bookmarks. The annotations module only needs the raptor library. Knowing
this, what do you think of the following ideas
* getting rid of the --enable-redland configuration flag, and
automatically care about it if someone asks for the module needing it.
* do the same with libraptor.
* add a "--enable-system-raptor" flag which would make it possible to
use the builtin redland with shared libraptor or link against a shared
one without redland when it's not needed. I'm not certain about the
"static raptor & shared redland" situation, however.

3/I started cleaning up the configure.ac file, rewriting the
--enable-XXX flags to make a better use of the autoconf macros (standard
display of options, default choice, etc...). If you are interested, I
will be happy to try and continue on this.

Also, to react on Hugh Sasse, I certainly second the request to have a
tarball unpacking everything into a subdirectory. Though I'm trying to
move away from the fullsrc archive for the Debian package, I was
disappointed to end up with 5 directories the first time...

I would also suggest to move to automake instead of the home-made
Makefile.in, and would be happy to do some work on that.

Attached is a patch which contains the following changes :
-remove the "#include <redland.h>" where it's not needed
-remove all references to the plugin module in
configure.in/Makefile.in/Options.in
-get rid tests against non-existing variables in configure.in
-rewrite most of the --enable tests to make better use of the autoconf
features.

Any comment is more than welcome. Any suggestion whether I should
continue to work on this sort of thing or not would be appreciated as
well :).

Regards,
Regis




Received on Saturday, 14 October 2006 19:42:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:37 UTC