Re: [AD] include path fixup patch.

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2008-01-06, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> On Sun January 6 2008, Thomas Fjellstrom wrote:
> > On Sun January 6 2008, Elias Pschernig wrote:
> > > On Sun, 2008-01-06 at 05:50 -0700, Thomas Fjellstrom wrote:
> > > > I've got a patch to fix up a ton of references to include/allegro in
> > > > 4.9 that are now incorrect.
> > > >
> > > > Apply if you will, otherwise I can.
> > >
> > > Does the autotools build work again after applying this?
> >
> > No, but I'm working on it now, so ignore this patch.
> 
> I have found out some interesting things while going along.
> 
> For instance the deplib.sh script has been broken for a long time. So the 
> dependencies haven't been generated properly in an equally long time.
> 
> The idea behind manually doing dependencies the way Allegro's autotools build 
> system does is very flawed imo.

I guess it was to avoid a dependency on gcc.

> Also, with the changes that have been made over the past couple months, theres 
> a lot of cruft in the autoconf files. cruft and wrongness. I've managed to 
> get it to build a shared release lib, docs and examples, but this is where I 
> stop. IMO, it is not worth messing with the current autoconf setup. In my 
> mind there are two options, scrap autoconf all together, or write a new set 
> that isn't in such a mess*.
> 
> I'll volunteer for doing the work for option #1, but someone else is going to 
> have to be the one to mess with allegro's autoconf build from now on.

For now, don't delete it, in case it needs to be resurrected.
Save your energy.

> *) Things that need to be looked at are:
> 1. remove asm

Yes.

> 2. remove the unsharable lib if at all possible

Should be possible now.

> 3. remove any and all unsupported parts of the unix build (freebeaf?)

Good.

> 4. remove old examples from building

Why have you guys been doing this?  I'm okay with not building the old
examples by default, but they are going to be the basis of testing any
compatibility layer.

> 5. remove dga 1 and 2

Yes.

> 6. let autoconf handle the dependencies, or at least use a simpler generator 
> (gcc -MM anyone?)

autoconf doesn't handle dependencies.  There ought to be a tiny,
portable .c program around that can generate dependencies.

> Now, I've attached a patch of what I've done to get it to at least build (no 
> guarantees about installing or running properly), let me know if theres 
> anything horrendously wrong with it.

I didn't really look at it, but already I noticed some mistakes so don't
apply it.

Peter