Re: gEDA-user: scons

[Igor2 <igor2@xxxxxxxxxxx>]

On Wed, 28 Feb 2007, al davis wrote:

>The problem (please correct me if I am wrong) is that it creates 
>a dependency on guile.  Someone needs guile to work on a 
>program that doesn't use guile anywhere else.

<snip>

>I looked at the web page ..  It looks like the files are python 
>scripts.  ok .. now we have a dependency on python.  Someone 
>needs python to work on a program that doesn't use python 
>anywhere else.
>

Completly true, however bash or make is not that default either, however I
prefer project which have simple configure/make. Somehow I find it
annoying to have an 500k long configure script to create Makefiles for a
program that finally will end up only 200k itself. 

In the following (sorry, long) mail I will share my experience about a
project of mine that doesn't use autotools but custom
configure/makefiles. It has nothing to do with gEDA so feel free to skip
it if you are not interested.

It's always a hard thing to decide: use custom written
configure/make/compatibility stuff or use autotools. Autotools offer that
your program will run on systems you have never seen without needing to
care too much about portability while coding. Still I often find ifdefs
for system-specific things in projects using autotools... So when we had
the same problem with libgpmi, we decided to use custom solutions. 

The configure script is a shell script (unfortunately depends on bash,
not sh). It's modular: there's a huge (20k) central script that
coordinates all the tests and file generation but most of the actual work
is done in subscripts collected in a lib/ dir. There's another directory
called data/, which has all the template files (so they are not embedded
in the configure script - it is easier to find and modify them this
way). General settings (like prefix or whether an option is enabled or
not) are simple shell variables during the configuration and some of them  
end up in an includable Makefile and in an includable shell file so later
other Makefiles or scripts can use settings without running the whole
configure process again. There's a shell file that has the default
settings for all these variables with rich comments; the comments are
structured in a way that a small script (<7k) can present a menuconfig
using dialog(1) - it looks like menuconfig of the Linux kernel, with
nested submenus. The user can use --with arguments for the configure
script or use a local.conf file where he can modify any of the
variables (note that this file is a shell script so he can build some
basic logic here).

Because libgpmi optionally depends on interperters of 7 different
languages, it is worth looking at the script detection part. The user
can either describe cflags and ldflags directly so no autodetection will
be done but flags are simply tested or if this omitted, the script tries
to autodetect the version and compilation settings for the given
language. This is done by external scripts: each language has its own
script. they usually follow the same scheme, having a thin c test program
embedded which calls the interpreter to do something trivial and checks
the results then a function that tries specific combinations of
flags. Some script configs look around in some system dirs to find the
version of the installed interpreter, but as they are shell scripts,
anything is possible: using pkg-config (if presents on the system) or
running any language-specific configuration program installed with the
interpreter.

After the configure finished, we have the Makefile and shell script
plugins with the results mentioned above. The templates are also processed
and specific variables are replaced in them before producing the resulting
Makefiles. 

We have generated and handwritten Makefiles to separate system specific
parts from the logic (i.e. which files to compile). The biggest generated
Makefile is about 4.5k and a typical hand written Makefile is a few
hundred bytes. Hand written Makefiles usually list source and header files
in variables, set package name and relative installation paths (also in
variables). Optionally they can add some cflags and ldflags, more rearely
they contain local rules. Makefiles are recursive and we usually have 2
classes of subdirectories: hub ones do not compile anything themselves but
compile recursively in subdirs and leaf directories contain the actual
code. Following this rule of thumb keeps Makefiles simple and we can
generate most of them from templates during the configuration.

Finally, portability: as mentioned above, I don't really believe that
autotools can save one from having #ifdefs for some portability problems 
at the end. However, I hate to be interrupted in the code, either when I
write it or when I read it, by huge chunks of #ifdef HAVE_* code. It
really affect readability if you can't concentrate on _what_ the code does
but you have to read trough _how_ it is done on specific systems. So in
gpmi we decided to separate these issues into os_dep.c/os_dep.h; I'm so
happy with this scheme that I tend to follow it in other projects as
well. The idea is to create a compatibility layer which has all the
ifdefs. For example we have gpmi_path_init() call there, which sets up
some basic paths: on windows using the registry and using backlashes, on
UNIX using the prefix info got from Makefile (and indirectly
configure) and slashes. We need to do foobar but that is done differently 
in BSD and in windows? We just add a foobar() in os_dep. Sometimes it's
just a wrapper to call the same functions with different names for
different systems or to rearrange the call arguments, sometimes the whole
logic differs.

Yes, this is definetly reinventing the wheel. For example Apache has a
nice compatibility lib or actually even automake offers solving the
porting problem. I am sure automake knows more systems than I do, and I am
also sure Apache devs know more about porting than me. Still, if one of my
aims is to keep things small and simple, I simply shouldn't reuse their
work. Sometimes reusing existing work/code saves time, sometimes it wastes
time :)

--
Igor2






_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user