This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Tired of make. Anyone interested in a guile-based replacement?


> It would be especially bad if fooconfig in turn required (say) perl,
> which wouldn't build with the native C compiler, so I need gcc too,
> which requires fooconfig to configure it, which needs perl, ....  (No,
> perl does *not* come preinstalled on all UNIX systems these days. :-)
> Or, to shorten the loop, what if configuring guile to build required
> having guile already installed?  (It's a problem with gcc on some
> platforms that don't ship with C compilers at all, but I think that's
> a special case people are prepared to deal with.  I don't think we
> should add more such cases.)

There is a generic problem that you have to depend on SOMETHING in order
to bootstrap yourself and I agree that you want to depend on as few things
as possible. From my perspective, I write code with the indention that it
be used with gcc and gmake for the simple reason that those tools are
more widely portable than any other comparable tools. Now it is true that
there are systems that have cc but its not gcc compatible, never the less,
if I want to write for one compiler along then I write for gcc.

Naturally, it is better not to target any particular compiler but instead
to write to ANSI standard or some such thing, for the most part I do, it
just isn't always the easiest thing to do <shrug> the world is less than
perfect.

As for depending on perl, my feeling is that I need SOMETHING to do the
necessary regex transforms on my files and I could equally use awk, sed
or even guile. I could write something in C that did it too. At the time,
perl seemed the most widely available and easiest option. Maybe writing
straight C would be more portable but then I have to write my own regex
functions (since trusting system regex is really dangerous). Maybe writing
a thing that tries perl, if that fails it tries awk, then sed, etc would
be OK but that is also a lot more work.

> But from a design perspective, having a language specifically for
> doing configuration stuff, which could be easily translated to sh or
> other simple languages, but which could actually be analyzed for
> dependency info, would (I think) be much cleaner than what we've got
> now, even if translations to other languages never actually get done.

Yes, I agree completely. The makefile language is good for dependencies
but not good for autoconfiguration and not good for handling multiple
levels of directories. For a new language to actually be better, it would
have some very difficult jobs to do:

* Allowing for dependencies to be both manually entered and also
  generated (like scanning for header files).

* Allowing for automatic detection of system capabilities

* Handling multiple levels of directory in a logical manner

* Letting the user build small parts of the project as uni test programs
  which allow debugging some feature in isolation

* Supporting configuration options that result in dependencies
  changing (for example, with readline or without readline)

* Allowing alternatives with respect to dependencies
  (eg use curses or ncurses depending on what is available, switch in
  different code depending on which one is used)

* Switching in library replacement code (if some library is available
  then use it, otherwise use our own code)

* Consider both shared and static linking

Maybe just collecting together all of the difficult cases in the one
bucket would be a step towards a solution.

> Of course, it would have to include primitives such as "look for this
> string in this file".  And some loop or list processing constructs may
> turn pretty ugly when translated to sh.  But as I see it, debugging
> the sh code is like debugging the assembly code generated by gcc
> ... it's not meant to be pretty and easy to understand, it's meant to
> me functional and efficient.

I disagree here. Remember that the person who downloads your project
and tries to compile it has only the final simple-language files to
work with. You make the assumption that everything is working and then
figure that no one would want to debug it. People start debugging when
things stop working so rethink everything on the assumption that the ugly
constructs are broken somewhere and you are the person staring at them
wondering what will make it work.

	- Tel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]