Hi everybody,
As some of you are aware, one of the blocking items [1] for gEDA/gaf
1.5.3 (and eventually 1.6.0) is a unified build system, with the whole
of the suite distributed in a single tarball. This will have benefits
for developers and packagers.
In the 'build-system' branch [2] of my personal git repository, I have
managed to:
- Rewrite the configure script and write new m4 files for all of the
checks we need to do. The result is readable and maintainable.
- Convert all of the tools to be compiled by the new build system.
- Write new top-level 'README' and 'NEWS' files.
- Add support for embedding the 'git describe' version string in the
compiled applications (none of them do this yet, though).
gEDA can be successfully compiled and installed in one pass, with none
of the, "Install X, *then* you can compile Y," messing about that we
currently have. Check it out!
git clone git://repo.or.cz/geda-gaf/peter-b.git
git checkout origin/build-system
./autogen.sh && ./configure && make
Unfortunately, you'll quickly realise there's a big problem. The
testsuite doesn't work unless you 'make install' first, and 'make
distcheck' doesn't work at all.
Why is this? Let's examine what happens when (say) gsymcheck starts up.
1. gsymcheck attempts to load $GEDARCDIR/system-gafrc, ~/.gEDA/gafrc,
./gafrc, $GEDARCDIR/system-gsymcheckrc, ~/.gEDA/gsymcheckrc, and
./gsymcheckrc. If none of those can be found, libgeda kills it.
2. If one of those was, by any chance, successfully found, libgeda
tries to initialise the gEDA font -- even if the program won't ever
actually use it (AFAIK only gschem ever actually uses the font). If
the font can't be found, libgeda kills the program (there's a theme
here).
3. If system-gafrc is loaded, it in turn searches the Scheme load-path
for "geda-font" (we install $GEDADATADIR/scheme/geda-font.scm). If
it's found, geda-font.scm tries to load the font from
$GEDADATADIR/sym/font/. If that directory doesn't contain at least
the question-mark character, yep, you guessed it, the program gets
killed.
4. And so it continues...
Basically, the problem is that at the moment a large number of files,
From all over the gEDA source and build directories, need to be arranged
in a precisely-defined structure in a single location in order for any
of the tools to even *run*. In the past this problem has been almost
entirely masked by the fact that the 'libgeda' and 'symbols' packages
always needed to be installed before any of other tools could be built.
Unfortunately, that's not true if everything's in a single package.
A number of ways forward present themselves.
1. If we got rid of the font entirely, many of these problems would go
away. Hopefully Pango support is coming Soon(tm), but unfortunately
might require a rethink of how printing is done. Peter C. can
expand on that.
2. Many of the problems could similarly be alleviated by making the
question-mark character be built-in to libgeda, and making failure
to load rc files or the font *not* call exit(-1) from a library.
*scowl* *shakes fist*
3. Neither options 1 nor 2 would allow gschem to be run without being
installed. In the longer term, therefore, we need to both:
a. Try to always determine data and configuration directories at
runtime, and provide command-line options to all the programs to
control how this is carried out. wcalc, pcb and gerbv all seem to
manage this okay.
b. Reorganise the source tree so that the system configuration files
and scheme files are grouped together in a vaguely sane layout.
This goes hand-in-hand with providing the aforementioned
command-line options.
4. Other options I haven't thought of.
I would be very grateful if people could look at the problem, have a
think about how it could be addressed, and let me know if you come up
with any ideas. Or patches. Patches are good too.
Regards,
Peter
[1] http://geda.seul.org/wiki/geda:todos
[2] http://repo.or.cz/w/geda-gaf/peter-b.git?a=shortlog;h=refs/heads/build-system
P.S. Since what you see in that branch has been a couple of *months*
hard work, I'm not keen to discard it. "Stick with the current
packaging," is not a suggestion that would make me happy! ;-)
--
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre
Attachment:
pgphZgVJLr0sE.pgp
Description: PGP signature
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user