Re: substitution vs expansion in Makefile.am
I'd like to thank everyone who responded to my questions regarding substitution vs expansion. I think I have a good handle on this issue now. To summarize: 1. Use make variables everywhere you can in makefiles, as opposed to autoconf substitution variables because doing so gives you more flexibility on the make command line. 2. Don't use either autoconf or make variables in automake file lists because it may confuse dependency management code - VPATH is your friend here. Thanks again! John On Wed, Mar 5, 2008 at 10:39 AM, John Calcote <[EMAIL PROTECTED]> wrote: > Erik, > > I believe I understand Harlan's method. My understanding is that make > actually prefixes all targets not found relative to the current > directory with each path (relative or absolute) specified in VPATH, > until it finds the file (or not). To use my original example, here's > my directory structure: > > project > common > mySleep.c > server > registrar.c > dbg-build > common > server > Makefile <-- > > The dbg-build directory is one I created from which to build a debug > version of my code. The indicated Makefile contains: > > VPATH=../../server > > registrarTest_SOURCES = registrar.c ../common/mySleep.c > > Of course, make is able to find registrar.c in project/server because > of the VPATH. It didn't find it in the current directory, so it looked > (effectively) in $(VPATH)/registrar.c. Obviously VPATH is more than > just a variable, but I'm using it in this manner here for the sake of > illustration, because it contains only one component. > > But what about mySleep.c? Well it works the same way. It doesn't find > ../common/mySleep.c relative to the current directory, so it looks in > $(VPATH)/../common/mySleep.c, which resolves to > ../../server/../common/mySleep.c, which finally resolves to > ../../common/mySleep.c. > > hth > John > > > > Harlan Stenn wrote: > > > > You can use: ../common/mySleep.c in your foo_SOURCES list. > > If the sources are in /home/user/src and you go to /home/usr/build > and do "../src/configure" the above will be completely wrong. > > The correct way to do it is to use "$(top_srcdir)/common/mySleep.c" > which will work under all circumstances. > > Erik > > > > On Tue, Mar 4, 2008 at 4:29 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote: > > John, > > > > > > > Bob, server/Makefile's VPATH only contains the expansion of > > > @top_srcdir@/server, which in this case is ../../server. This means > > > that make won't be able to find any sources listed that exist in > > > directories other than ../../server. So I think I HAVE to use > > > $(top_srcdir)/common/mySleep.c, don't I, as it's in a different source > > > directory? > > > > You can use: ../common/mySleep.c in your foo_SOURCES list. > > > > H > > >
Re: substitution vs expansion in Makefile.am
Erik, I believe I understand Harlan's method. My understanding is that make actually prefixes all targets not found relative to the current directory with each path (relative or absolute) specified in VPATH, until it finds the file (or not). To use my original example, here's my directory structure: project common mySleep.c server registrar.c dbg-build common server Makefile <-- The dbg-build directory is one I created from which to build a debug version of my code. The indicated Makefile contains: VPATH=../../server registrarTest_SOURCES = registrar.c ../common/mySleep.c Of course, make is able to find registrar.c in project/server because of the VPATH. It didn't find it in the current directory, so it looked (effectively) in $(VPATH)/registrar.c. Obviously VPATH is more than just a variable, but I'm using it in this manner here for the sake of illustration, because it contains only one component. But what about mySleep.c? Well it works the same way. It doesn't find ../common/mySleep.c relative to the current directory, so it looks in $(VPATH)/../common/mySleep.c, which resolves to ../../server/../common/mySleep.c, which finally resolves to ../../common/mySleep.c. hth John Harlan Stenn wrote: > > You can use: ../common/mySleep.c in your foo_SOURCES list. If the sources are in /home/user/src and you go to /home/usr/build and do "../src/configure" the above will be completely wrong. The correct way to do it is to use "$(top_srcdir)/common/mySleep.c" which will work under all circumstances. Erik On Tue, Mar 4, 2008 at 4:29 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote: > John, > > > > Bob, server/Makefile's VPATH only contains the expansion of > > @top_srcdir@/server, which in this case is ../../server. This means > > that make won't be able to find any sources listed that exist in > > directories other than ../../server. So I think I HAVE to use > > $(top_srcdir)/common/mySleep.c, don't I, as it's in a different source > > directory? > > You can use: ../common/mySleep.c in your foo_SOURCES list. > > H >
Re: substitution vs expansion in Makefile.am
Erik wrote: > Harlan Stenn wrote: > > > You can use: ../common/mySleep.c in your foo_SOURCES list. > > If the sources are in /home/user/src and you go to /home/usr/build > and do "../src/configure" the above will be completely wrong. > > The correct way to do it is to use "$(top_srcdir)/common/mySleep.c" > which will work under all circumstances. I have years of experience and many examples that agree with me and not with you. The VPATH includes the SRCDIR, and as long as ../common/mySleep.c is correct from the source tree, it will work in a build tree. In my experience. H
Re: substitution vs expansion in Makefile.am
Harlan Stenn wrote: > You can use: ../common/mySleep.c in your foo_SOURCES list. If the sources are in /home/user/src and you go to /home/usr/build and do "../src/configure" the above will be completely wrong. The correct way to do it is to use "$(top_srcdir)/common/mySleep.c" which will work under all circumstances. Erik -- - Erik de Castro Lopo - "The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code." -- Paul Graham
Re: substitution vs expansion in Makefile.am
John, > Bob, server/Makefile's VPATH only contains the expansion of > @top_srcdir@/server, which in this case is ../../server. This means > that make won't be able to find any sources listed that exist in > directories other than ../../server. So I think I HAVE to use > $(top_srcdir)/common/mySleep.c, don't I, as it's in a different source > directory? You can use: ../common/mySleep.c in your foo_SOURCES list. H
Re: substitution vs expansion in Makefile.am
NOTE: I routinely build in non-source directories because I can keep separate sets of configure options. Bob, server/Makefile's VPATH only contains the expansion of @top_srcdir@/server, which in this case is ../../server. This means that make won't be able to find any sources listed that exist in directories other than ../../server. So I think I HAVE to use $(top_srcdir)/common/mySleep.c, don't I, as it's in a different source directory? Note that I'm not using a path on registrar.c - it's found in the server directory. Also note that this is a unit test build, so I'm grabbing files from the common directory to add to my unit test. Perhaps I should be using the common convenience library rather than the common source files directly, but sometimes I need different compiler options for the test objects. Ralf, I should think that using @top_srcdir@ in a SOURCES list would be better than $(top_srcdir) because it will be replaced by hard path info in the final Makefile. On the other hand, since automake converts Makefile.am to Makefile.in before autoconf gets around to replacing the variable with path info... > > registrarTest_SOURCES = registrar.c\ > > @top_srcdir@/common/mySleep.c > You should always use the Makefile form in Makefiles. You should > always use relative paths in the source tree (from the Makefile > location) to refer to source files from your package (i.e. don't use > @top_srcdir@). If your package is built in some other directory, > VPATH will be used to tell make where to look for the source files.
Re: substitution vs expansion in Makefile.am
On Tue, 4 Mar 2008, John Calcote wrote: Thanks Bob and Ralf. Here's one that's just a little more complex (the last one, I promise). I have this in my Makefile.am: registrarTest_SOURCES = registrar.c\ @top_srcdir@/common/mySleep.c registrarTest_CPPFLAGS = -DREGISTRAR_TEST\ -I$(top_srcdir)/common This question is somewhat related to the last one I asked. Where should I use @top_srcdir@, and where should I use $(top_srcdir)? You should always use the Makefile form in Makefiles. You should always use relative paths in the source tree (from the Makefile location) to refer to source files from your package (i.e. don't use @top_srcdir@). If your package is built in some other directory, VPATH will be used to tell make where to look for the source files. I see that Ralph just posted email. Perhaps he will say something entirely different. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: substitution vs expansion in Makefile.am
On Tue, 2008-03-04 at 15:34 -0700, John Calcote wrote: > This question is somewhat related to the last one I asked. Where > should I use @top_srcdir@, and where should I use $(top_srcdir)? The answer is, you should ALWAYS use the make variable, and NEVER use the automake variable. There may be very obscure exceptions but I can't think of any; certainly none in a straightforward automake file. My $0.02. -- - Paul D. Smith <[EMAIL PROTECTED]> http://make.mad-scientist.us "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
Re: substitution vs expansion in Makefile.am
* John Calcote wrote on Tue, Mar 04, 2008 at 11:34:54PM CET: > >registrarTest_SOURCES = registrar.c\ > @top_srcdir@/common/mySleep.c Hmm, putting variables in *_SOURCES is problematic as the dependency tracking code in m4/depout.m4 is really dumb and may do the wrong thing. $(top_srcdir) is certainly better than @top_srcdir@ here, but it may even be that for correct functionality you need to just spell it out with runs of "../". >registrarTest_CPPFLAGS = -DREGISTRAR_TEST\ > -I$(top_srcdir)/common This is fine. Cheers, Ralf
Re: substitution vs expansion in Makefile.am
Thanks Bob and Ralf. Here's one that's just a little more complex (the last one, I promise). I have this in my Makefile.am: registrarTest_SOURCES = registrar.c\ @top_srcdir@/common/mySleep.c registrarTest_CPPFLAGS = -DREGISTRAR_TEST\ -I$(top_srcdir)/common This question is somewhat related to the last one I asked. Where should I use @top_srcdir@, and where should I use $(top_srcdir)? registrarTest_SOURCES will be used in a make dependency list, and that registrarTest_CPPFLAGS will be used on a compiler command line. Does this make a difference? I don't think make cares whether there are make variables in either targets or dependency lists, but... I'll tell you what. I'm looking over some code that I wrote a long time ago, and now I know a lot more about what I'm doing with Autotools than I used to. I probably copied this stuff from someone else's project without understanding it. Now I understand what it's doing, and it just opens up more questions. :) Regards, John
Re: substitution vs expansion in Makefile.am
Hi John, * John Calcote wrote on Tue, Mar 04, 2008 at 10:38:50PM CET: > Newbie question here: Is it better to do this in a Makefile.am: > >install-exec-hook: >$(mkdir_p) $(DESTDIR)@syslogdir@ > > or this: > >install-exec-hook: > $(mkdir_p) $(DESTDIR)$(syslogdir) > > assuming, of course, that I called AC_SUBST(syslogdir) in configure.ac? > > The first will expand to $(prefix)/..., so you'd have the option of > changing the resulting directory by passing prefix= on the make > command line. The second will allow you to change the resulting > directory with either prefix= or syslogdir= on the make command line. > I guess you'd get a bit more flexibility by using the second option > because you could change the syslogdir without changing the prefix. > But, is there a conventional, or more correct approach? Nice question. You already deliver the answer, including full rationale and all: the second form is preferable because it allows more override. In general, there is one other bit of difference between @foo@ and $(foo) in that automake may not be able to look into the former. But for this case that makes little difference. Cheers, Ralf
substitution vs expansion in Makefile.am
hi list, Newbie question here: Is it better to do this in a Makefile.am: install-exec-hook: $(mkdir_p) $(DESTDIR)@syslogdir@ or this: install-exec-hook: $(mkdir_p) $(DESTDIR)$(syslogdir) assuming, of course, that I called AC_SUBST(syslogdir) in configure.ac? The first will expand to $(prefix)/..., so you'd have the option of changing the resulting directory by passing prefix= on the make command line. The second will allow you to change the resulting directory with either prefix= or syslogdir= on the make command line. I guess you'd get a bit more flexibility by using the second option because you could change the syslogdir without changing the prefix. But, is there a conventional, or more correct approach? If you have an opinion on it, then what's your rationale? Thanks in advance, John
