example of using ant to drive a gcj build

Fri Jan 10 14:35:00 GMT 2003

On Thu, Jan 09, 2003 at 02:33:55AM -0800, Adam Megacz wrote:
> I guess my gripes come down to two issues and one non-issue:
>> - I find shell commands (specifically, all the "magic" non-[A-Za-z0-9]
> characters) very unreadable. Note that this is completely
> orthogonal to using XML or not. I could envision a better make that
> didn't rely on the shell but still had a nice, simple, non-XML
> syntax. That would be nice. I wonder if the Python people have
> something like this...

make has been reimplemented a zillion times, so I'm sure some of
them have. ;-) Obviously, when make was written, shell was the
natural "extension language", and everyone could be expected to know
it. (I'd still say that knowing shell is good for you!)
Shell is still the natural choice for writing most rules, don't you
agree (not that it wouldn't be nice to have a choice)? If make's
automatic variables ($<, $@, $^, etc) were more intelligible, that
would make the biggest difference. It's in other places where I
curse being stuck with only make's limited built-in constructs, or
shell. Like filtering out all the .o files in a given directory.
Here you want a real programming language.
> - The "arguments" that make passes to the various steps of the build
> process keep getting concatenated into a string and then parsed back
> into a list. This process also tends to assign special meaning to
> various characters (like the space character). This makes me
> nervous.

As long as you don't have filenames with spaces in them (in which
case, make is useless), it doesn't tend to bite. And you would have
a big project before the inefficiency mattered. So I just put this
kluge out of my mind.
> Essentially, I want my build tool (and its command-execution
> language) to actually have a legitimate parser that distinguishes
> between identifiers and string literals, and maintains that
> distinction from end to end.

You can mostly close your eyes and imagine that "file sets" are
being maintained as structured objects. Of course, if they really
were, you could potentially do more powerful things.
> I also think I need to learn more about make ;)

make solves its problems pretty well, if you can put yourself in a
1970's mindset. (And GNU make's documentation is pretty good, once
you get past the gatekeeper that is the info reader.)
Andrew