 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Folks,
we could use a bit of help to iron out a kink in the Unix build process:
Currently, our approach at identifying the version of the installed
OpenEXR library is based on the `pkg-config` tool, which does not seem
to be available on all systems (example: Mac OS X darwin 15.6.0).
My guess is that this approach was originally used because older
versions of OpenEXR were pretty taciturn when it came to disclosing
their version number.
However, modern versions of OpenEXR are much more cooperative in this
respect, so getting the version information of those should be well
possible even without `pkg-config`.
So it would be neat if someone with some rudimentary knowledge of
Automake and a bit of Unix know-how could review the current mechanism,
and amend it so that the OpenEXR version information is obtained in a
more portable fashion when possible, and the `pkg-config`-based approach
is only used as a fallback solution.
Any takers?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/18/2017 02:25 PM, clipka wrote:
> Folks,
>
> we could use a bit of help to iron out a kink in the Unix build process:
>
> Currently, our approach at identifying the version of the installed
> OpenEXR library is based on the `pkg-config` tool, which does not seem
> to be available on all systems (example: Mac OS X darwin 15.6.0).
>
> My guess is that this approach was originally used because older
> versions of OpenEXR were pretty taciturn when it came to disclosing
> their version number.
>
> However, modern versions of OpenEXR are much more cooperative in this
> respect, so getting the version information of those should be well
> possible even without `pkg-config`.
>
> So it would be neat if someone with some rudimentary knowledge of
> Automake and a bit of Unix know-how could review the current mechanism,
> and amend it so that the OpenEXR version information is obtained in a
> more portable fashion when possible, and the `pkg-config`-based approach
> is only used as a fallback solution.
>
> Any takers?
>
I'll take a run at the update later today.
If successful, I'll assume you want the pull req against release/v3.7.1
unless I hear otherwise.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/18/2017 02:25 PM, clipka wrote:
>
> My guess is that this approach was originally used because older
> versions of OpenEXR were pretty taciturn when it came to disclosing
> their version number.
>
> However, modern versions of OpenEXR are much more cooperative in this
> respect, so getting the version information of those should be well
> possible even without `pkg-config`.
>
>
Still looking, but it might take a while to work around pkg-config.
The real reason for the usage isn't the version determination but rather
updating the compile include and link libraries via updating the
environment variables CPPFLAGS and LIBS, respectively.
The commands:
pkg-config --cflags OpenEXR
and
pkg-config --libs OpenEXR
are used to get what those respective updates should be.
The Simple DirectMedia Layer needs this sort of update too. As part of
its package a built in command called "sdl-config" is provided which
works as a stand in for pkg-config. I've found no similar mechanism for
openexr.
I'm trying now to figure out where pkg-config gets its information with
the idea maybe we could duplicate the function it performs.
Interesting too - I'm not sure the usual configure include / library
overrides will work with openexr. The mechanism is certainly different
than the jpeg set up if it does.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/19/2017 10:21 AM, William F Pokorny wrote:
> On 05/18/2017 02:25 PM, clipka wrote:
>
> Still looking, but it might take a while to work around pkg-config.
>
> The real reason for the usage isn't the version determination but rather
> updating the compile include and link libraries via updating the
> environment variables CPPFLAGS and LIBS, respectively.
>
> The commands:
>
> pkg-config --cflags OpenEXR
>
> and
>
> pkg-config --libs OpenEXR
>
> are used to get what those respective updates should be.
>
> The Simple DirectMedia Layer needs this sort of update too. As part of
> its package a built in command called "sdl-config" is provided which
> works as a stand in for pkg-config. I've found no similar mechanism for
> openexr.
>
> I'm trying now to figure out where pkg-config gets its information with
> the idea maybe we could duplicate the function it performs.
>
> Interesting too - I'm not sure the usual configure include / library
> overrides will work with openexr. The mechanism is certainly different
> than the jpeg set up if it does.
>
> Bill P.
Got back to this a while ago. The more I dig the more I think if the
pkg-config command and its infrastructure exists, it should be used first.
In fact for best reliability, the pkg-config mechanism should perhaps be
used first for all our packages when available. The necessary .pc files
exists for the Simple DirectMedia Layer library too it turns out.
Have to stop for now, but my plan for tomorrow is to hard code the
compiler and linker flags to use for openexr when pkg-config is not
found after some checking for headers, library version and a test compile.
This hard coded method will be exposed to breakage on changes the whole
pkg-config system was and is aimed at solving, but it should mostly work
and not be too bad to patch over time based upon openexr version should
the need arise.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.05.2017 um 21:35 schrieb William F Pokorny:
> Got back to this a while ago. The more I dig the more I think if the
> pkg-config command and its infrastructure exists, it should be used first.
>
> In fact for best reliability, the pkg-config mechanism should perhaps be
> used first for all our packages when available. The necessary .pc files
> exists for the Simple DirectMedia Layer library too it turns out.
Are you sure about this?
To my knowledge, the pkg-config mechanism tells you what packages are
installed via a Linux distribution's package management, such as apt.
However, if the user chooses to install a different version of a library
locally, using environment variables or parameters to `./configure` to
point the compiler there, then my guess is that relying on pkg-config
would seriously screw up things.
Unless pkg-config reliably addresses that issue, in my opinion our first
attempt should be to try and pry the relevant information from the very
files that will be accessed during compilation, i.e. the header files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.05.2017 um 20:25 schrieb clipka:
> Currently, our approach at identifying the version of the installed
> OpenEXR library is based on the `pkg-config` tool, which does not seem
> to be available on all systems (example: Mac OS X darwin 15.6.0).
I have to correct myselfg on this one: pkg-config apparently /is/
available on Mac OS X darwin 15.6.0; but for some reason it fails to
work properly with the OpenEXR library package available for that system.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/20/2017 04:05 AM, clipka wrote:
> Am 18.05.2017 um 20:25 schrieb clipka:
>
>> Currently, our approach at identifying the version of the installed
>> OpenEXR library is based on the `pkg-config` tool, which does not seem
>> to be available on all systems (example: Mac OS X darwin 15.6.0).
>
> I have to correct myselfg on this one: pkg-config apparently /is/
> available on Mac OS X darwin 15.6.0; but for some reason it fails to
> work properly with the OpenEXR library package available for that system.
>
In my digging it seemed like occasionally folks had to update an
environment variable PKG_CONFIG_PATH to point to the location of a
packages particular *.pc files. They can be in different locations and
the ones getting picked up on linux for gnu compiles seem mostly located
in :
/usr/lib/x86_64-linux-gnu/pkgconfig
with:
/usr/lib/x86_64-linux-gnu/pkgconfig/OpenEXR.pc
and
/usr/lib/x86_64-linux-gnu/pkgconfig/IlmBase.pc
being the two used for openexr. I suppose on other systems, compilers
where the *.pc files get picked up might change. If you find a different
location is needed for Mac OS X darwin 15.6.0 etc, perhaps the easiest
fix is our setting PKG_CONFIG_PATH to point to it?
You can check the current defaulted library paths being used to find
*.pc files with the command:
pkg-config --variable pc_path pkg-config
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.
Aside: There is a perl script (cpan pm package) called, if I remember,
ppkg-config that some use as an alternative to pkg-config though it was
all that clear to me why. I've not looked at it, but if you really want
to avoid pkg-config starting there with the idea we'd ship such a script
ourselves is perhaps a place to start.
Aside2: A while back I tried to do a static compile with --enable-static
and it failed to link a library other than openexr. I wonder now if I
could find the link flags needed to get this going with "pkg-config
--static".
Where do you want to go with this?
I'll hold off making any further updates pending your answer.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/20/2017 03:42 AM, clipka wrote:
> Am 19.05.2017 um 21:35 schrieb William F Pokorny:
>
>> Got back to this a while ago. The more I dig the more I think if the
>> pkg-config command and its infrastructure exists, it should be used first.
>>
>> In fact for best reliability, the pkg-config mechanism should perhaps be
>> used first for all our packages when available. The necessary .pc files
>> exists for the Simple DirectMedia Layer library too it turns out.
>
> Are you sure about this?
>
> To my knowledge, the pkg-config mechanism tells you what packages are
> installed via a Linux distribution's package management, such as apt.
>
> However, if the user chooses to install a different version of a library
> locally, using environment variables or parameters to `./configure` to
> point the compiler there, then my guess is that relying on pkg-config
> would seriously screw up things.
>
>
> Unless pkg-config reliably addresses that issue, in my opinion our first
> attempt should be to try and pry the relevant information from the very
> files that will be accessed during compilation, i.e. the header files.
>
I'm unsure at the moment how the other version mechanism works but would
be a little surprised if pkg-config doesn't have a mechanism to handle
it. I'll do a little more digging on this and see what I can turn up.
We can certainly hard code flags to what works now if you want to do this.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/20/2017 09:34 AM, William F Pokorny wrote:
> On 05/20/2017 03:42 AM, clipka wrote:
>> Am 19.05.2017 um 21:35 schrieb William F Pokorny:
>>
>>> Got back to this a while ago. The more I dig the more I think if the
>>> pkg-config command and its infrastructure exists, it should be used
>>> first.
>>>
>>> In fact for best reliability, the pkg-config mechanism should perhaps be
>>> used first for all our packages when available. The necessary .pc files
>>> exists for the Simple DirectMedia Layer library too it turns out.
>>
>> Are you sure about this?
>>
>> To my knowledge, the pkg-config mechanism tells you what packages are
>> installed via a Linux distribution's package management, such as apt.
>>
>> However, if the user chooses to install a different version of a library
>> locally, using environment variables or parameters to `./configure` to
>> point the compiler there, then my guess is that relying on pkg-config
>> would seriously screw up things.
>>
>>
>> Unless pkg-config reliably addresses that issue, in my opinion our first
>> attempt should be to try and pry the relevant information from the very
>> files that will be accessed during compilation, i.e. the header files.
>>
>
> I'm unsure at the moment how the other version mechanism works but would
> be a little surprised if pkg-config doesn't have a mechanism to handle
> it. I'll do a little more digging on this and see what I can turn up.
>
> We can certainly hard code flags to what works now if you want to do this.
>
> Bill P.
It looks like where multiple libraries can exist in system space the
library names must be unique and the *.pc prefixes must be unique and
where you want other than the system default you must refer to the
version by name when using pkg-config to get the compiler and linker
flags to use.
When the libraries are installed in non-standard locations - say a user
space often it seems the already mentioned PKG_CONFIG_PATH environment
variable is used to put the users versions ahead of the any system ones.
I suppose in our current set users would need to know to do this.
It looks like it is expected folks use the environment variable
PKG_CONFIG_LIBDIR to be when no system package *.pc information is to be
used. Something you might do if say compiling on Ubuntu for another
target system.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
