automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vpath builds and nobase_include_HEADERS


From: Ralf Wildenhues
Subject: Re: vpath builds and nobase_include_HEADERS
Date: Thu, 4 Jun 2009 07:47:50 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello John,

* address@hidden wrote on Thu, Jun 04, 2009 at 12:24:29AM CEST:
> I'm having troubles with out of tree (vpath) builds, using  
> nobase_include_HEADERS, and *.in files processed by configure.

I think you're making things more complicated than they need to be.

> I have a collection of components in a component library.

> I want to do out of tree (vpath) builds, and maintain the directory  
> structure of the components for the headers on install.

OK.

> First, in order to preserve the directory structure for the headers on  
> install, I added rules such as these to the Makefile.am's
>
> from lib1/Makefile.am
>
> nobase_include_HEADERS = \
> $(header_file_list)

The above is ok, the below is not.

> lib1/header1.hh : lib1
> for file in $(header_file_list) ; do \
> nobase_file="`echo $$file | sed -e 's?lib1/??'`" ; \

(no need for the double quotes in this line BTW)

> $(LN_S) -f @HOST_ACDIR@/src/lib1/$$nobase_file lib1/. ; \
> done
>
> lib1 :
> mkdir lib1;

(directory dependencies don't work like this; they are satisfied by
directories found by VPATH, too)

> where $(header_file_list) has the directory name in the file name and  
> @HOST_ACDIR@ points to the location of configure.

Don't do this.  Just accept that you have parts of the headers in the
build tree (namely those that are generated by or after configure) and
parts in the source tree.  All you need for that to work seamlessly is
to have -I. -I$(srcdir) in your cpp flags (most likely AM_CPPFLAGS).

The install rules generated by automake will ensure to pick up all
needed files from the build or the source tree.

> This of course makes a directory lib1 in my current lib1 build dir and  
> makes soft links to the header files in the source tree. Then on a make  
> install it puts the headers in the place I want, ie, 
> $prefix/include/lib1.
> I have such a snippet for all of my components.

Just remove it.

> One additional aspect of this is that my source tree has a types.hh.in  
> which is processed by configure and placed in the build directory. I have 
> an additional rule that links the processed file into my lib1 
> subdirectory for install.

configure should just create it in the correct relative location in the
first place, namely in lib1/types.hh IIUC.

> Now, the problem is that in lib2 headers/sources I want to have includes  
> such as
> #include <lib1/header1.hh>
> #include <lib1/types.hh>
>
> And of course I want my -I include path to point to the build location of 
> these headers since some of them have been processed by configure, ie,  
> types.hh.in -> types.hh

Sure.

> The trouble is that as part of my effort to get the 
> nobase_include_HEADERS feature for installing headers in subdirectories, 
> is that those headers now live in lib1/lib1 due to the targets in my 
> Makefile.am and the code won't compile with -I$(top_builddir)/lib1.

Well, you need -I$(top_builddir).  Most likely that path is already
added for you by automake, too.

> This all seems very complicated and it most definitely seems like this  
> combination of vpath/nobase_include_HEADERS/types.hh.in is a pretty usual 
> combination that I shouldn't have to stand on my head for to make it 
> work.

Yep, you're doing too much.  :-)

If that still doesn't help, it is useful to post a small example
package.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]