Ralf Wildenhues wrote: > How about adding it to a convenience archive, and then adding that to > your build. In this case, add > > noinst_LIBRARIES = libcore.a > libcore_a_SOURCES = core.c > > to src/Makefile.am, and add > gtkapp_LDADD = ../libcore.a > > to gtk/Makefile.am. Inside src/Makefile.am, ensure that files in the > current directory are built before recursing, e.g., by > SUBDIRS = . gtk
To expand on the logic here a little bit, the reason that you have to use a library to communicate objects across different .am files is that the name of an object built by automake is considered an implementation detail and is not stable. Only the .am file that is responsible for building the object knows for sure what its name and location will be, as there are all kinds of things that could cause it to have to munge or obfuscate the name. If you take that conclusion a little farther you realize that it then really only makes sense to think about automake-managed objects as belonging to a library or a program (or both), but not lying about loose and unassociated. This explains why your attempt to get the top-level .am to compile the object by specifying "SOURCES = core.c" didn't do anything. There's probably a chance that you find this totally ridiculous: "Why do I need to create a library just to refer to an object in another dir?" For one thing remember that convenience libraries are never installed, so it's not like this will ever exist outside of your build tree. And here is where I would say that if it bothers you then you should instead just consider "gtkapp_SOURCES = gtkapp.c ../core.c". But you've ruled that possibility out for reasons unstated. I'm assuming it's because core.c is used elsewhere as part of some other component or something, but that's even more reason to express this situation as a library: two or more things reusing the same code. Maybe there is a better solution if we knew more of the details, but without them it's hard to tell you anything more than "use a library." There are two additional other things to consider: one, you could switch to a non-recursive setup with just a single .am file (or possibly multiple files that are 'include'-ed together to make one file) at which point everything is visible to everything else without the need to use a convenience archive in this way, though it still might make sense to group logical components together. And two, the .am file is meant to allow arbitrary Makefile syntax to be used, so if you really want to build an object in one .am file and refer to it in another you can go ahead and write the rules to do so just as if you were writing any ordinary Makefile. Sometimes, that's what it takes to do the job and that's the only way to do what you need. But in this instance automake has a perfectly valid way of handling the situation, so it really seems wrong to encourage coloring outside of the lines. Brian
