[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
signature.asc
Description: Digital signature
- dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0),
Olaf Till <=
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), Olaf Till, 2017/02/22
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), Olaf Till, 2017/02/22
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), Olaf Till, 2017/02/22
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), Olaf Till, 2017/02/22
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), John Donoghue, 2017/02/22
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), Olaf Till, 2017/02/22
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), John Donoghue, 2017/02/22
- Message not available
- Message not available
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), Olaf Till, 2017/02/22
- Message not available
- RE: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), JohnD, 2017/02/22
- Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0), John Donoghue, 2017/02/22