Re: [AD] library dependencies... |
[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]
On Mon, 5 Jan 2004 06:38:58 +0100 Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote: > Weird. Could you upload a compressed version of config.log somewhere? It is attached. > > It would be much simpler to change the linking of X extensions by > > editing Makefile.am instead of makefile.in > > Why? > > > (btw, many unix people refer to makefile's with a capital M ). > > Both are recognized automatically by GNU make, so this doesn't really > matter. > The only good reason I can supply to using Makefile as opposed to makefile is that the auto tools, automake, produces Makefile, not makefile. Most other unix projects that use the auto tools will eventually produce Makefile and thats what people know to look for. Theres nothing wrong with it and if you dont want to change it I wont harp about it anymore. > > Basically Im wondering where did makefile.in come from and can we > > switch to makefile.am? > > Why? > In my experience, Makefile.am is much easier to make changes to than Makefile.in. Makefile.am contains all the files you want compiled and a few variables where you can set which libraries to link in, as opposed to Makefile.in where you have to specify all of the rules as well. In my project, which is of comparable size to Allegro, Makefile.am is 296 lines while Makefile.in is 925 lines. I get the feeling that I will have to come up with Makefile.am and prove that is better. Although I hesitate to do this, becuase im not all that great at the automake tools, I will make something that hopefully someone can improve upon later. Basically you are doing automake's job yourself. I see that you are using autoconf to generate configure, so why not use automake to generate Makefile.in? later--, jon
Attachment:
config.log.gz
Description: Binary data
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |