Re: [AD] include path fixup patch.

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Sun January 6 2008, Peter Wang wrote:
> 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.

Screw that. I added a little perl script that'll handle it just fine. I can't 
see even an ancient version of perl not being installed on a unix box.

> > 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.

Mind telling me what they are?

> Peter
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/



-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/