On Thursday 01 March 2007 05:11:59 Igor2 wrote: > 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 ... make is not that default either, Um...yes it is! <snip> > 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. This is always a good idea. (Apart from using the registry, that's always a bad idea :P ). > 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 :) On the other hand, you now have a vast collection of custom scripts that *no-one* coming to the project from outside has a hope of understanding fully without a serious investment of time and effort. If someone has a problem building GPMI due to a bug in your configuration system, they're unlikely to invest the time required to fix it themselves (even if its well within the realms of their expertise), meaning that you get a bug report rather than a patch, for instance. When the libgeda rewrite gets underway, I'm hoping to use glib more extensively for portability -- I'm a big fan of reusing other people's work where appropriate! Cheers, Peter -- Fisher Society committee http://tinyurl.com/o39w2 CUSBC novices, match and league secretary http://tinyurl.com/mwrc9 CU Spaceflight http://tinyurl.com/ognu2 v3sw6YChw7$ln3pr6$ck3ma8u7+Lw3+2m0l7Ci6e4+8t4Gb8en6g6Pa2Xs5Mr4p4 hackerkey.com peter-b.co.uk
Attachment:
pgp4EZitR4Ua4.pgp
Description: PGP signature
_______________________________________________ geda-dev mailing list geda-dev@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev