On 05/20/2017 09:38 AM, clipka wrote:
> Am 20.05.2017 um 15:24 schrieb William F Pokorny:
> 
>> One of the reasons I now find myself unwilling to duplicate the
>> pkg_config function is that it is not all that simple in total. I think
>> I'm going to bail on this work if you insist on a pkg-config like
>> solution we own.
> 
> What would be the point in duplicating pkg-config in the first place?
> 
> We're not using pkg-config (or anything similar) for the other
> libraries, so I see no point why we should rely on it for OpenEXR.
> 

The reason to use pkg-config is to reliably get library compiler and 
linker flags for the system and libraries where the compile is happening.

We hard code flags today except with openexr and sdl where they are 
determined on the fly. If you want to hard code flags for openexr, make 
that call and I'll attempt to update the .m4 file using the flags I see 
being used today vie pkg-config.

My recommendation continues to be to fall back to such hard coding only 
when pkg-config doesn't exist or doesn't work.

Searching for the *.pc files in the many directories where they exist, 
reliably parsing them to figure out flags and the *.pc dependencies so 
we can reliably have flags current with the libraries is not a trivial 
task. I'm not myself going to do that work mostly because it looks to me 
to duplicate a significant function of pkg-config.

Bill P.

Post a reply to this message

I think what we should do, in a nutshell, is the following:

- Inform the users that they may need the pkg-config package (if they
want to use OpenEXR).

- In the absence of pkg-config, or if pkg-config fails to come up with
any useful information, make a reasonable attempt to determine the
OpenEXR version in another manner, and make a reasonable guess at the
additional compiler and linker flags required (if any).

- Make sure our configure script contains a test to verify that the
OpenEXR library can be linked using the chosen compiler and linker flags.


I also wonder whether we should make our handling of libraries more
consistent, and make use of pkg-config for other libraries as well where
possible.

As a side note, I noticed that the automake tools apparently provide
dedicated macros to make use of pkg-config; those might be worth a
closer look, even if in the end we decide against them (their use seems
to be controversial due to some known issues, so if we decide to use
them nonetheless, we should clearly document those issues).

Post a reply to this message

Am 2017-05-21 16:54, also sprach clipka:

> As a side note, I noticed that the automake tools apparently provide
> dedicated macros to make use of pkg-config;

I was surprised there was no m4 macro for openexr.
https://www.gnu.org/software/autoconf-archive/The-Macros.html

I wondered if maybe modifying ax_pkg_mico might be a starting point.
https://www.gnu.org/software/autoconf-archive/ax_pkg_mico.html


-- 
dik

Post a reply to this message

On 05/21/2017 04:54 PM, clipka wrote:
> I think what we should do, in a nutshell, is the following:
> 
> - Inform the users that they may need the pkg-config package (if they
> want to use OpenEXR).
> 
> - In the absence of pkg-config, or if pkg-config fails to come up with
> any useful information, make a reasonable attempt to determine the
> OpenEXR version in another manner, and make a reasonable guess at the
> additional compiler and linker flags required (if any).
> 
> - Make sure our configure script contains a test to verify that the
> OpenEXR library can be linked using the chosen compiler and linker flags.
> 
> 
> I also wonder whether we should make our handling of libraries more
> consistent, and make use of pkg-config for other libraries as well where
> possible.
> 
> As a side note, I noticed that the automake tools apparently provide
> dedicated macros to make use of pkg-config; those might be worth a
> closer look, even if in the end we decide against them (their use seems
> to be controversial due to some known issues, so if we decide to use
> them nonetheless, we should clearly document those issues).
> 

Thanks for the guidance. I'll work this direction.

I think we should look to use pkg-config only where the library itself 
seems to support it with the necessary *.pc information. Though, hacking 
our own *.pc files where they are missing or inaccurate would be a 
possible path too I guess...

Yes, a test compile and test link with whatever flags we determine to 
use makes good sense.

FYI. It turns out pkg-config does provide the flags necessary to fix the 
--enable-static link issue with libtiff I mentioned somewhere in this 
thread. We are always using just

-ltiff

which "pkg-config --libs libtiff-4" returns too. If we ask for the 
static flags with: "pkg-config --libs --static libtiff-4" we get:

-ltiff -llzma -ljbig -ljpeg -lz -lm

where -llzma and -ljbig are unique to what we end up with today in the 
Makefiles and necessary for the static link to work. So, we have already 
one issue that using pkg-config should fix for many *nix based users.

I also got my hands on an old book on autoconf & automake yesterday, 
which I'll continue to look through today. I know a smidgen now about M4 
to the envy of millions. ;-)

Bill P.

Post a reply to this message

On 05/21/2017 05:39 PM, dick balaska wrote:
> Am 2017-05-21 16:54, also sprach clipka:
> 
>> As a side note, I noticed that the automake tools apparently provide
>> dedicated macros to make use of pkg-config;
> 
> I was surprised there was no m4 macro for openexr.
> https://www.gnu.org/software/autoconf-archive/The-Macros.html
> 
> I wondered if maybe modifying ax_pkg_mico might be a starting point.
> https://www.gnu.org/software/autoconf-archive/ax_pkg_mico.html
> 
> 
Thanks for the pointers. I'd found the general archive link yesterday, 
but the site seemed to be having an issues and I could not get to it.

Just now your links OK & I'll take a look at the package you suggest first.

Bill P.

Post a reply to this message