[Icecast-dev] libshout includedir change

[Thomas Vander Stichele]

> 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