octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0


From: Olaf Till
Subject: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)
Date: Wed, 22 Feb 2017 11:06:27 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Feb 21, 2017 at 08:46:25PM +0000, lostbard wrote:
> Is the real fix the ability to find the settings no matter the OS,
> or the ability to provide a way to get the package to compile ie:
> being able to provide additional parameters if needed to get it to
> compile?

The latter... but by reliably determining the architecture for which
the compilation is intended.

Ideally, cmake should have the architecture compiled in and include
the correct /usr/lib/<target> path in its search for gdcm
configuration information. (But as we know now, cmake doesn't do this
correctly.)

So we have to manually get the intended architecture:

- Asking the compiler suite would probably make us dependent on a
  specific compiler, so not good.

- Fortunately we can ask Octave: 'octave-config -p
  CANONICAL_HOST_TYPE'. This may return a quadruplett instead of a
  triplett -- in this case the second component must be removed to get
  <target> above.

We can try to use this information in one of the following ways:

1. Provide the information to 'cmake --find-package' to make it find
   the gdcm configuration information. If this is possible, it seems
   the correct way to me, better than 2. . (We don't need an m4 makro
   to call 'cmake --find-package'.)

2. Search for gdcm includes and libs independently from cmake. But
   what if gdcm decides to take on an unforeseen directory name or
   uses an additional directory (say
   /usr/include/gdcm-extra-<version>/, or something like that).

Olaf

> Playing around a little, I see there is a bug with cmake.m4 in the
> repo, so that if you provide your own GDCM_CXXFLAGS and GDCM_LIBS,
> it stilll sets them via cmake - I will push a change up for that
> 
> For autoconf, it would somehow have to check all include paths for
> all versions of gcdm.
> 
> You are right though, more discusion should go on the maintainers list.




> ** [package-releases:#296] dimcom-0.2.0**
> <https://sourceforge.net/p/octave/package-releases/296/>


-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]