[gdal-dev] json-c configure.in seems too complicated

[Even Rouault]

Le dimanche 01 novembre 2015 17:53:22, Greg Troxel a écrit :
> I am building on a machine where most dependencies are built with
> --prefix=/usr/pkg; a few are in the base system with --prefix=/usr.  I
> have json-c installed in /usr/pkg.
> 
> With svn trunk, configure found -ljson-c (because I had passed LDFLAGS
> and CPPFLAGS to configure), and found many other things (geos, jpeg,
> etc.).   But, it didn't find the json-c header file, apparently because
> it was looking in specific pathnames instead of trying to compile a
> program that includes the header.  I don't understand why explicitly
> finding the header is necessary; I would just expect to have code that
> needs it do #include and then if it wasn't found to add the internal
> implementation to CPPFLAGS.
> 
> (Actually, I don't understand why there is an internal implementation,
> but that may be about windows.)

Yes, at the origin, there was only the internal implementation. The 
possibility to link to external libjson-c was later added.

> 
> I worked around this with --with-libjson-c=/usr/pkg, but it would be
> nice if this weren't necessary.
> 
> I'm not sure a "this seems too complicated" is fair for a ticket, and
> there's probably some intent here I'm unaware of, so maybe just a
> comment is in order.

You're welcome to improve the test to try in standard locations too. It 
appears I wrote this detection test and I'm definitely not good at configure 
stuff. I guess one issue must be that the code does stuff #include "json-c.h" 
instead of #include "json-c/json-c.h" which might make it impractical to rely 
on standard include locations?

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com