> Karl just pointed out to me that libshout is now installing its header > in $prefix/include/shout.h instead of $prefix/include/shout/shout.h.(Sorry for not replying directly, I'm not on the list and I can't figure out if gmane allows me to reply to a mail.) It's probably best to try and contact the committer first - It's possible few other people understand or care enough about the build. That would be very surprising, I think this isn't true. Could you show me a make install log that installs in that dir, and not a subdir like it's intending to ? % svn diff -r 10991:10992 Index: include/shout/Makefile.am ==================================================================--- include/shout/Makefile.am (revision 10991) +++ include/shout/Makefile.am (revision 10992) <at> <at> -2,5 +2,5 <at> <at> AUTOMAKE_OPTIONS = foreign -includedir = $(prefix)/include/shout +pkgincludedir = $(includedir)/shout nodist_include_HEADERS = shout.h> Can anyone explain what this change is meant to accomplish? If not, > I'm just going to revert it.The original line, includedir = $(prefix)/include/shout is wrong. "includedir" is an autotools variable that you're not meant to override from inside the build - it's meant to be overridden as an argument to configure or make. This is important, because overriding includedir is exactly what package build systems do. The end result is then that all package builds that override includedir in a correct way for integration with their system, end up installing shout.h exactly in the includedir they gave, and not in a subdirectory of its own. There are other reasons why someone would want to override the standard variables like includedir, but this is an important one. For a long time, because of this mistake, a lot of the xiph stack had their headers installed in includedir directly and not in subdirs, while it was different for installs from source, and thus ended up confusing end users and distributors alike. I fixed this bug everywhere I know it existed in the xiph stack. Why is the change more correct ? Precisely because it does not try to set a standard autotools variable. Instead, it creates a new one that uses the standard one, to guarantee it will get installed in a subdir. If any of this is unclear, let me know. If there is an actual install problem, I would like to see it so I can fix it. But I'd recommend not reverting the patch, because the original behaviour is wrong and in a lot of cases has exactly the bug you mentioned. Thanks, Thomas
On Wednesday, 17 May 2006 at 09:34, Thomas Vander Stichele wrote:> > Karl just pointed out to me that libshout is now installing its header > > in $prefix/include/shout.h instead of $prefix/include/shout/shout.h. > > (Sorry for not replying directly, I'm not on the list and I can't figure out if > gmane allows me to reply to a mail.) > > It's probably best to try and contact the committer first - It's possible few > other people understand or care enough about the build.The original email had thomasvs@xiph.org on the To: list. You should probably arrange to pick up mail from that address.> That would be very surprising, I think this isn't true. Could you show me a > make install log that installs in that dir, and not a subdir like it's intending > to ?% sudo make install Making install in include Making install in shout make[3]: Nothing to be done for `install-exec-am'. test -z "/usr/local/include" || /Users/brendan/dev/libshout/install-sh -d "/usr/local/include" /usr/bin/install -c -m 644 'shout.h' '/usr/local/include/shout.h' ... this is with automake 1.9.6 on OS X. I get the same results on Ubuntu 5.10. I don't actually have access to a system where make install works properly.> The original line, includedir = $(prefix)/include/shout is wrong. "includedir" > is an autotools variable that you're not meant to override from inside the build > - it's meant to be overridden as an argument to configure or make. This is > important, because overriding includedir is exactly what package build systems > do. The end result is then that all package builds that override includedir in > a correct way for integration with their system, end up installing shout.h > exactly in the includedir they gave, and not in a subdirectory of its own. > There are other reasons why someone would want to override the standard > variables like includedir, but this is an important one.Typically they set DESTDIR or prefix. Overriding includedir seems odd. Unless this is gentoo we're discussing, where anything goes. Can you point to the documentation about which variables should not be overridden in Makefile.ams? Assuming you're correct, I believe you also need to do this: % svn diff Index: Makefile.am ==================================================================--- Makefile.am (revision 11409) +++ Makefile.am (working copy) @@ -3,4 +3,4 @@ AUTOMAKE_OPTIONS = foreign pkgincludedir = $(includedir)/shout -nodist_include_HEADERS = shout.h +nodist_pkginclude_HEADERS = shout.h I'm a bit surprised that you've gotten correct header installation without this (and without overriding includedir).> If any of this is unclear, let me know. If there is an actual install problem, > I would like to see it so I can fix it. But I'd recommend not reverting the > patch, because the original behaviour is wrong and in a lot of cases has exactly > the bug you mentioned.I'll commit the above fix.
Maybe Matching Threads
- [PATCH] build: fix includedir in uninstalled libguestfs.pc
- Sudo #includedir function ignored CentOS 6
- Connections to Samba fail when "includedir" is set in krb5.conf (e. g. after RHEL 7.2 to 7.3 update)
- ices-2.0.0 compile problems
- Don't hate yourself anymore, brendan