Vincent Belaïche writes:
> This still needs some elaboration, but I could not do this because I
> corrupted my source tree (I don't anymore a makefile under
> cedet/list/cedet), and I could not get again the latest source code, I
> tried:
>
> bzr branch bzr://cedet.bzr.sourceforge.net/bzrroot/cedet code
>
> But this does not work.
Wrong URL. See
http://cedet.sourceforge.net/bzr-repo.shtml
> Anyway, I wanted first to know whether this kind of evolution is
> welcome. It seems to me that this makes the Makefiles harder to read
> when going to all these macro definitions to be multi-platform.
Changing EDE to generate multi-platform Makefiles like this is indeed
out of the question. Our Makefiles are already too complicated.
Generating Makefiles for other systems like Windows would have to be a
separate EDE project type. Now, building CEDET through such a project is
a different issue; at least I could not properly test and maintain that,
and frankly, I still don't see the need for such a build, because...
> I know that somebody is going to say "anyway you can build with
> cedet-build.el".
...yep.
> - con: You re-invent what GNUMake does perfectly, that is to say,
> most of the time you do a re-build all and lose all the
> partial build and parallelization that GNUMake can do.
cedet-build.el doesn't do a full rebuild. Parallel builds are another
matter entirely; we don't support it, neither through cedet-build.el nor
through GNU Make. It simply might or might not work with the latter,
since GNU Make cannot magically solve dependencies between targets.
> - use a build system that is more platform independent that GNUMake, the
> only candidate that come to my mind is ant.
There are many build systems out there which are more patform
independent than GNU Make. Scons, Rake, Maven, Cmake, just to name a
few. Supporting one of those in EDE - now that would be nice
addition. Someone should totally code that.
-David
|