portability issue: AC_PREREQ, missing -lgd, dist_doc_DATA needs docdir defined

[GoogleCodeExporter]

What steps will reproduce the problem?
1. autoreconf -vfi   (or the provided script autogen.sh)
2. ./configure
3. make

What is the expected output? What do you see instead?
Expected a configure, build

What version of the product are you using? On what operating system?
SVN rev 89 on CentOS-5.3 (linux-2.6.18, glibc-2.5, gcc-4.1.2)

Please provide any additional information below, including sample input
file:

The following patch resolves the issues: I found that autoconf-2.59 is 
sufficient if C99-specific 
semantics are not required.  I found that a simple SEARCH_LIBS had the effect 
of adding it to the 
link line (or not if it's unnecessary), and swapping dist_doc_DATA to 
dist_data_DATA works to fix 
the automake error.

Patch is attached as "svn diff"'; please consider.

Original issue reported on code.google.com by chickena...@gmail.com on 20 Aug 2009 at 1:19

Attachments:

• mscgen-r59-build.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi

The dist_doc_DATA -> dist_data_DATA change and it ends up installing the docs in
/usr/share rather than /usr/share/doc/mscgen/, so additional code would be 
required
to work around it. Also  dist_doc_DATA appears to be supported in 2.59 mode[1], 
so I
do not understand the reason for this change.

It compiles and runs the tests just fine without being in C99 mode (on my 
machine).
However this means that -std=gnu99 is not passed and neither is -D_GNU_SOURCE, 
so gnu
extensions and gnu specific optimisations may not be enabled.

AC_SEARCH_LIBS call finds my "gd" library on my machine, though the patch lacks 
an
if-statement handling the "--without-png" case (where it still searches after 
libgd).
I am unsure if it is appropriate to use both pkg-config and search path.

~Niels

[1] Though I have autoconf 2.64, so it might be that it does not restrict 
itself.

NB: I had to withdraw my previous comment to append my test findings on the 
doc->data
change in 2.59.

Original comment by NThykier@gmail.com on 20 Aug 2009 at 2:59

[GoogleCodeExporter]

Hi Neils; I know *why* you're installing to docdir, but maybe it's only defined 
in autoconf-2.63?

running: automake --add-missing --copy --force-missing
src/Makefile.am: installing `../../compile'
Makefile.am:8: `dist_doc_DATA' is used but `docdir' is undefined
autoreconf: automake failed with exit status: 1

In my case, I am now just redundantly defining docdir in Makefile.am and 
examples/Makefile.am -- it makes 
the patch for examples/Makefile.am submitted in the other bugrep cleaner 
(really a suggestion, not a bugrep)

Original comment by chickena...@gmail.com on 20 Aug 2009 at 3:01

[GoogleCodeExporter]

AC_SEARCH_LIBS is only needed because the package didn't define where the 
ysmbol comes from -- it give no 
"-lgd" in the link line.

The reason I prefer SEARCH_LIBS over CHECK_LIB is because if the lib isn't 
needed, it isn't added.

Maybe it should be shuffled up to the if/else/endif logic for --without-png, 
that sounds like a testcase I didn't 
check, and it would result in a smaller dependency list as the user would 
expect.

Original comment by chickena...@gmail.com on 20 Aug 2009 at 3:03

[GoogleCodeExporter]

I've removed some C99-isms and the configure line to be safe.

Like Neils I'm not keen on dist_data_DATA since that would break some distro
packaging conventions.  Still, I'd like it to work on CentOS since that's a 
nice distro.

Regarding finding the gd libs, the PKG_CHECK_MODULES macro should be doing that 
most
efficiently, and also puts some options into the configure help for cases where 
it fails:

$ ./configure --help
  ...
  PKG_CONFIG  path to pkg-config utility
  GDLIB_CFLAGS
              C compiler flags for GDLIB, overriding pkg-config
  GDLIB_LIBS  linker flags for GDLIB, overriding pkg-config
  ...

I might pull down a CentOS 5.3 liveCD and try it with VirtualBox to see if I 
can make
it build nicely on that OS.

Original comment by Michael....@gmail.com on 24 Aug 2009 at 9:06

[GoogleCodeExporter]

Hi Michael;

PKG_CONFIG nearly works -- emphasis on "nearly".  If it was 100%, I wouldn't 
need to add the 
AC_SEARCH_LIBS.  Note, again, that SEARCH_LIBS finds cases where additional 
libraries *not*already*found* 
are needed.  The key part of the logic I would emphasize is that if the 
libraries are found already, they aren't 
needed additionally, so there is no duplication.

The AC_SEARCH_LIBS is basically saying "look, check again that you got 
everything, but if you don't already 
have it, check these other libs".  this takes the situation where the 
PKG_CONFIG has to be perfectly setup (like 
a qmake or Imake environment) and adds an additional check (like an automake 
environment).

It hurts nothing, and helps.

If you're following automake/autoconf rules, dist_data_DATA is directed:

http://www.google.com/search?q=dist_data_DATA+%2Bsite%3Agnu.org

The first hit:
http://www.gnu.org/software/hello/manual/automake/Fine_002dgrained-Distribution-
Control.html

shows:

     dist_data_DATA = distribute-this
     bin_PROGRAMS = foo
     nodist_foo_SOURCES = do-not-distribute.c

Seems it has automake/autoconf's blessing.

based in the trend of RPM (recently added %make_install "to do things the right 
way") I would encourage 
sticking with the automake/autoconf recommendation.  Hey, your choice; my 
argument is "that's what 
automake suggests", while eroding "RPM forces us to do it that way".  Besides, 
it works in RPM, I test-built.  
You can grab the RPM from my site.  In summary "automake suggests" and "rpm 
doesn't refuse".  I cannot 
speak for Debian, I don't know them anymore.

This one also hurts nothing (except maybe Debian, that's unknown) and helps.

I think I can get your packaging/manual/linux.sh down to 10 lines as well, 
reduce complexity, and it'll be 
closer to conventional RPM while still building your static and dynamic 
packages smoothly.  It has the side-
effect of reducing more of the places you have to keep information matching -- 
in this case, between 
configure.in and the spec file.

Original comment by chickena...@gmail.com on 24 Aug 2009 at 9:46

[GoogleCodeExporter]

Hey, BTW I might have come off a little harsh in my last comment; I don't mean 
to seem like a raving looney.

The suggestions I made are zero-risk, and beneficial, but every project has its 
degree of uniqueness, either from 
what didn't work when it started, or just arbitrary choices.  Meh.  Your 
codebase, your choice, right?

Original comment by chickena...@gmail.com on 24 Aug 2009 at 11:08

[GoogleCodeExporter]

Hi Chicken,

I've pulled a Centos5.3 live CD so will look into autoconf on that plaform at 
some
point (hey - it's a bank holiday this weekend!).

Regarding linux.sh - that's just to build the various packages I intend to 
release on
my website for 0.17.  An RPM in just one way of distributing, but can be built 
just
from the spec file and dist bundle - it doesn't include anything odd or 
non-standard
(check 
http://code.google.com/p/mscgen/source/browse/trunk/packaging/rpm/mscgen.spec).

> The suggestions I made are zero-risk, and beneficial, but every project has 
its
> degree of uniqueness, either from what didn't work when it started, or just
> arbitrary choices.  

I am considering your changes, just this one's a bit more involved and I don't 
want
to break anything which is already established.

> Meh.  Your codebase, your choice, right?

It's GPL, anyone can fork.  Of course, I'd prefer to collect all the good 
changes
here, but sometimes that takes me a bit of time to work out what is a good 
change and
what isn't.

Getting it building on CentOS 5.3 is something I hadn't previously considered, 
but I
can see that being useful.  If we get there through your suggestion or some 
slightly
different way I don't mind.  But thank you for pointing this out and coming up 
with
suggestions.

Original comment by Michael....@gmail.com on 26 Aug 2009 at 7:51

[GoogleCodeExporter]

Hi

Revisiting this: Personally I think the only change *strictly* required for a 
build
on CentOS-5.3 would be the removal C99 headers (which was done in revision 93)
assuming that 0.17 ships with a pre-generated set of configure and 
"Makefile.in"s
(however see below).

A missing (or broken) pkg-config setup can be avoiding by running configure 
with some
environmental variables set[1]. Admitted, it would be nice if we could make it 
fall
back to a normal lib search in case pkg-config cannot help; but it is not a 
strict
requirement.

Last but not least: The error seen with automake[2] suggests that you cannot
regenerate the Makefile.in from the Makefile.am. However if it was 
pre-generated, it
would not be a problem - which will be the case if the tar.gz was generated by 
"make
dist"/"make distcheck". Once the "Makefile.in"s and configure has been created,
neither autoconf nor automake is required - unless you need to regenerate them 
e.g.
because you had to modify the original files.

Nevertheless, there are times where regenerating these files could be 
useful[3]. As
far as I can tell we already have to "code" required to replace dist_doc_DATA 
with
dist_data_DATA, which was phased out by the patch in issue 27. This *might* also
solved by (conditionally?) setting and substituting docdir in configure.ac - 
since
automake only complains that is it not defined (not that it does not know how to
handle it).

~Niels

"Bank holidays" - For situations where "boring" doesn't cover it!

[1] I need to do this to build it on Debian - the following does the trick
./configure PKG_CONFIG=/bin/true GDLIB_LIBS=-lgd GDLIB_CFLAGS=  <other options>

NB: This is only true if libgd and its headers are in the "standard search 
path" for
your compiler and your linker.
[2] Makefile.am:8: `dist_doc_DATA' is used but `docdir' is undefined
[3] Like allowing people to build directly from svn.

Original comment by NThykier@gmail.com on 28 Aug 2009 at 11:20

[GoogleCodeExporter]

If you're not doing anything unusual, building directly from SVN is possible 
using "autoreconf --vfi"; updates 
(ie svn update) are picked up through most of the dependency-tracking, I 
haven't seen any problem with it yet 
-- but it confuses things like clearcase.

(I've expanded some thoughts in 
http://tech.chickenandporn.com/2009/08/23/dont-use-autogen-sh/ )

Building the Makefile.in from Makefile.am is often required when developing.  
Some changes tend to cascade.

I've found that it's hard to support things where you have to ask a lot of 
questions such as "did you run it with 
"--enable-kooky-thing=blue" ?  I bet people see a configure, and they type 
"./configure" on whatever 
platform they're on.

It's easier to leverage what the user is most likely to do.  It seems Debian 
can *also* profit from detection of 
libgd... (and I'd also set the "not found" for pkg-config to "true") -- or keep 
telling people the custom 
workaround for the rare platforms like Debian.  As a test, try doing the 
redundant detection on a Debian box, 
and see how well it works -- killing two birds with one stone, with no 
detriment to the other platforms, seems 
like it gives you more time to develop.

These workarounds get challenging to remember, but then my memory is probably 
worse than others.  You 
seem to be pretty good at remembering that stuff.

Original comment by chickena...@gmail.com on 29 Aug 2009 at 2:11

[GoogleCodeExporter]

> If you're not doing anything unusual, building directly from SVN is possible 
using
> "autoreconf --vfi"; updates (ie svn update) are picked up through most of the 
> dependency-tracking, I haven't seen any problem with it yet -- but it confuses
> things like clearcase.

I expressed myself unclearly. I did not mean building from svn in general, but 
in the
sense that it would allow people to build directly from svn; even if they had an
older version of autoconf/automake that does not handle dist_doc_DATA. 

> I've found that it's hard to support things where you have to ask a lot of
> questions such as "did you run it with "--enable-kooky-thing=blue" ?  I bet
> people see a configure, and they type "./configure" on whatever platform 
> they're on.

I agree with you here on the "they type ./configure" part. Whether it gives 
trouble
to support, I would not know - I have not released any project having special
configure switches.

> It's easier to leverage what the user is most likely to do.  It seems Debian 
can
> *also* profit from detection of libgd... (and I'd also set the "not found" for
< pkg-config to "true") -- or keep telling people the custom workaround for the
> rare platforms like Debian.  As a test, try doing the redundant detection on a
> Debian box, and see how well it works -- killing two birds with one stone, 
> with no detriment to the other platforms, seems like it gives you more time to
> develop.

Ah, in regards to Debian, you could ask them to contact me, since I am the 
maintainer
of the mscgen Debian package. Either I would know how to build the package or I 
could
use the input their provide. Also I can tell that you will need the 
libgd2-xpm-dev,
if you want UTF-8 support (see issue 7), since libgd2-noxpm is not compiled with
fontconfig support.

Though I admit it would probably give self-compiling users an easier time.

> These workarounds get challenging to remember, but then my memory is probably 
> worse than others.  You seem to be pretty good at remembering that stuff.

The truth is that I already created the logic for creating a deb package out of 
the
coming 0.17; so I can just look up my workarounds in a Makefile[1].

~Niels

[1]
http://svn.debian.org/viewsvn/collab-maint/ext-maint/mscgen/trunk/debian/rules?v
iew=markup

Original comment by NThykier@gmail.com on 29 Aug 2009 at 9:05

[GoogleCodeExporter]

Chicken,

Could you retry config and build on your CentOS 5.3 system at r95?

I've made the suggested changes and it builds on my installation here (although 
the
RPM does not build, though I'm not so concerned about that).

Mike

Original comment by Michael....@gmail.com on 30 Aug 2009 at 9:17

• Changed state: Accepted

[GoogleCodeExporter]

Hey, clean compile -- if a user just assumes either:

./autogen.sh && ./configure && make

or

autoreconf -vfi && ./configure && make

both work fine from a clean checkout.  All good over here :)

Original comment by chickena...@gmail.com on 31 Aug 2009 at 7:08

[GoogleCodeExporter]

Cool - thanks for checking!

I like the autoreconf -vfi - having read your blog, I've changed autogen.sh to 
now
call autoreconf -vfi, so the two are now equivalent.  I think this is the best
compromise in portability (incase the autotools change and want to do something
different), and familiarity for developers used to autogen.sh scripts.  It's 
under r98.

Thanks Again,

Mike

Original comment by Michael....@gmail.com on 31 Aug 2009 at 7:33

• Changed state: Fixed

[GoogleCodeExporter]

Thanks -- I appreciate the Changelog mention, but chickenandporn became 
chickenandpom.  :)

I'm entirely flattered that you read my rants!

Original comment by chickena...@gmail.com on 31 Aug 2009 at 9:29