* Peter Johansson wrote on Mon, Jun 08, 2009 at 06:52:18PM CEST:
> Ralf Wildenhues wrote:
>> Oh.  It seems your first message in this thread didn't make it to the
>> list then.  Dunno whether it was eaten by the spam filter, but it is
>> not sitting in the moderation queue.  You might consider resending
>> (or bouncing) it.
>>
>>   
> I tried a second time on Friday, but seems like it did not get through  
> either. Hope for better luck this time.

Well, it reached me at least, but to get through to the list you'd
probably have to delete generated files from it, as the size of 400K
is a bit over the limit of this list.

Anyway, I think the whole misunderstanding that John had, AFAICS, is
around this:

If you write this in sub/Makefile.am:
  nobase_foobar_HEADERS = sub1/foo.h sub2/bar.h

then that means that in the source or the build tree, there exist files
  sub/sub1/foo.h sub/sub2/bar.h

and upon 'make install', they will be installed in
  $(foobardir)/sub1/foo.h
  $(foobardir)/sub2/bar.h

Thus it is wrong to specify
  nobase_include_HEADERS = \
        comp1/comp1.hh \
        comp1/processed.hh

in lib/comp1/Makefile.am, because that will then look for files named
lib/comp1/comp1/comp1.hh in the source or the build tree, for
installation into $(includedir).

You can easily fix that either by

- listing the files one level up (in lib/Makefile.am) and possibly not
  needing a Makefile.am in the lib/comp1 directory at all, or by

- just not using nobase_, and fixing up the installation directory,
  in lib/comp1/Makefile.am:
    comp1includedir = $(includedir)/comp1
    comp1include_HEADERS = comp1.hh processed.hh

Hope that helps.

Cheers,
Ralf


Reply via email to