octave-maintainers
[Top][All Lists]
Advanced

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

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


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

On Wed, Feb 22, 2017 at 11:06:27AM +0100, Olaf Till wrote:
> 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'.)

It worked with setting CMAKE_LIBRARY_ARCHITECTURE:

...$ cmake --find-package -DNAME=GDCM -DCOMPILER_ID=GNU -DLANGUAGE=CXX 
-DMODE=COMPILE
GDCM not found.
CMake Error: Problem processing arguments. Aborting.

...$ cmake --find-package -DNAME=GDCM -DCOMPILER_ID=GNU -DLANGUAGE=CXX 
-DMODE=COMPILE -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu
-I/usr/include/gdcm-2.4

So this should be a feasible strategy:

1. determine architecture with AC_CANONICAL_TARGET,

2. if necessary, remove 2nd component from found target to get a
   triplett <target> (as x86_64-linux-gnu above),

3. don't use the m4 macro, but manually call cmake --find-package by
   specifying -DCMAKE_LIBRARY_ARCHITECTURE=<target>.

Olaf

-- 
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]