I finally responded to Mark, here is a "short" version for everybody. I was not entirely serious when I suggested to just use bash, but if you don't mind to recompile the whole thing everytime, its not a bad idea to get rid of extra complexity make introduces if you are not using the benefits it gives you. The end users are not affected, but the developers very much so. Just make is not really an option for Java projects, as make is not equipped to deal with the complexity of Java's interclass dependancies. My real suggestion is to take a look at IBM's open-source Java compiler called jikes, which can be very clever about feeding make. You will be spoiled. I never got around to write a Makefile for my own quite sizeable Java project, because jikes *.java returns pretty much instantaneously on my Ultra 10. I think even when you simply call jikes as in above example without any options, there is a lot of clever dependacy analysis going on and you get an incremental build. Don't you love IBM when they are pissed?
I haven't written a shell script myself in years and I think it's a good riddance. I remember quoting problems driving me insane. Perl is a perfect substitute for shell scripts and comes with every Unix these days. Windoze is a problem though, but do you care? You are pitching a development tool and there is no interesting development being done on Windoze these days. Everything is on the Unix servers running the Net. I heard not a single startup planning to develop software for Windows has been funded in the last ten years or more. VCs are just about smart enough to stay out of the way of the Seattle steamroller. If your Windows product is any good, Microsoft is going to clone it and bundle the clone for free with the OS until you go belly up. Of course, there are still more Windows developers out there than for any other platform, but most of them are VB monkeys writing in-house glue code. Those people are IT, not engineering and by no means your customers. They are not going to try any piece of code before it is blessed by the trade press and thousands of other lemmings. Maybe I am wrong, so lets have a vote. Anybody who really has to develop for Windows, please speak up. I have no great love for Linux and Java, but I sure do appreciate their hype machines, now big enough to make a dent in the grey mass of corporate IT developers. My point is that I think, being an OSS project not trying to make money, you could easily abandon Windows platform if that makes your life easier. Let the Linuxes, the Apaches, the Perls and the Javas fight M$ for the mindshare of 100% of developers out there. Meanwhile you can concentrate on getting the 5% who really need you, but don't know it yet. I figured writing Makefiles is not a core competence of current E developers and neither it is mine unfortunately, so the make problem can wait until you recruit a make wizard who'll rewrite your Makefile in a couple of hours. I've seen people who never in their life even edit their Makefiles manually, but let their emacs magically generate it. I always found writing Makefiles boring, so I always simply stole wizard's Makefiles and modified them. Almost forgot, you can't really have a decent Makefile on Windows, at least not with command.com for a shell, because the length of a command line is limited to 128 characters or something like that, which is often not enough to accomodate all the options you want.
As far as Java is concerned, yeah it kind of sucks, but it could've been worse. When Sun adds async networking and stops its idiotic anti-M$ jihad and allows native compilation, it will even be a useful C++ replacement. If you ask me, the perfect existing technology to piggyback on is not Java and not Perl (oramatcher was a great move IMHO, though. Perl has the best regexps, which aren't technically regexps anymore of course), but K. I don't think K is ever going to squish Java or Tcl, because the requirments on the quality of the developer are too intense, but if it were to be open-sourced (working on it :), it will roll over every database product in the market, from Access to Oracle Enterprise Edition due to recently added SQL wrapper. I am the first one to point out the better mousetrap does not always win, but if the chasm between the better mousetrap and the second contender (sorry, good old Postgres :( ) is sufficienly large it transcends the better mousetrap category and becomes known as destructive technology.
On Fri, 2 Jun 2000, Mark S. Miller wrote:
> At 11:56 PM 6/1/00 , Paul Snively wrote:
> >http://jakarta.apache.org/ant/ and I sure will!
>
> make's syntax is so terrible that I figured any attempt from scratch would
> have to be an improvement. I just took a look at Ant and, by using XML,
> they have succeeded at proving me wrong. Ant make-rules look even less
> maintainable than Makefiles. Quite an achievement! I have this image of
> Marlon Brando at the end of Apocalypse Now rubbing his bald head and saying
> "The verbosity, the verbosity." If you really wish to go in this direction,
> please first read my "Quasi-Literals and XML"
> http://www.erights.org/elang/grammar/quasi-xml.html and start by designing
> an ANTLR-based grammar for expressing these make rules readably.
>
> But even if you do this, we would still be waiting for the integration of
> ANTLR into E that note describes. We would then have a circular build
> dependency: our build tool would depend on code in the system we're using it
> to build. This can probably be resolved, but are we really making our lives
> easier?
>
> Andrei Moutchkine (cc'ed on this email) has suggested that we dispense with
> make anyway, and just write bash scripts for remaking everything. He
> correctly points out that we aren't using make's one distinguishing feature:
> incremental rebuilds based on modify dates. Each of our make-targets builds
> from scratch everything it makes. Since
>
> 1) bash scripts should be more maintainable than either Makefiles or
> Ant-rules (even though bash scripts are a maintenance nightmare),
> 2) our build process already depends on bash,
> 3) our make-rules are already expressed in bash (as a sublanguage of make), and
> 4) bash does not depend on E,
>
> I find this suggestion very appealing. If there's no objection, at some
> point I will proceed to do this.
>
>
>
> Cheers,
> --MarkM
>