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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user