On Sun, 2009-08-16 at 13:37 +0200, Pierre Lorenzon wrote:
> Hi Eric,
> First I should say that now ede-proj-regenerate works without
> any error ! since your last changes. (I updated my cedet
> version yesterday.)
> Now I have a question. Why did you implement automake projects
> with the same class as make projects ? Looking at methods code
> I personally had implement it as a subclass. In particular,
> `ede-proj-setup-buildenvironment' could be implemented like
> this :
> (call-next-method) ... and the rest. Is the reason that with
> current implementation user can easily change from make to
> automake by simply changing makefile type slot and without
> difficult cast ? Anyway I feel taht all these tests in methods
> checking if we are in the make or automake context in methods
> are not following object oriented code writing. But it's just
> my feeling and I might not understanding everything !
Mostly, that's just the way it grew. The Make part came first, and
adding Automake seemed like a very simple thing to just stick on the
side, and I liked the idea of being able to convert a project from Make
to Automake with a simple switch.
There are certainly OO ways of doing something similar better, such as
separating the Project.ede storage from the code generators. Over the
past several years, however, the Make part of the project has been
running the CEDET Makefiles quite well, and I have been focusing on
If you are interested in growing EDE past it's current limitations, I
would be happy to debate various designs. To answer a question in your
next email, there is no reason for EDE to continue supporting older
autoconf styles. It would be preferable for it to track the latest
features, though I am no longer the person to do that. I originally
wanted to port my old gnutalk app over to EDE, but no-one uses the old
unix talk protocol anymore, so I stopped maintaining it.
If you are interested in building a new code generator for the make
system, however, I would recommend a very different style based on
SRecode. Instead of writing out, and dynamically editing Makefiles or
AC files, it would be much easier to create an SRecode dictionary, and
just keep adding things to different sections. Then in one mightly
splurt, SRecode will write out Makefiles, autoconf.ac files, or
whatever, from a singly maintained dictionary. Retargeting from Make to
Automake might be as simple as different sets of template files.
And how cool would that be. Yea, I thought so.
I was going to do that a while ago as a proving ground for SRecode, but
because I had no tests, I had no way to prove I had done it correctly.
Now we have some basic tests. (It only took a year and a half. ;) If
we can prove they are complete, we could probably safely do a rebuild of
the EDE makefile generator.
Anyway, here is what I had planned, but not done.
1) Add a "Make2" build type next to Make and Automake
2) Build a new code generator based on SRecode dictionary & templates
3) Use some tests (which I hadn't written at that time) to make sure
Make and Make2 did the same thing.
4) Do the same for Automake.
5) Replace the old with the new, and delete lots of code.
I then realized that I needed to do 3.1 first, so I wrote the
integration tests, but didn't get any farther.
I think this safely answers both your email.