Re: [CMake] Conditional install() rules based on CPack generator

2019-06-05 Thread Eric Noulard 
Le mer. 5 juin 2019 à 12:00, Mathieu Malaterre 
a écrit :

> Hi there,
>
> I am trying to use NuGet generator for GDCM project. Typically my
> install rules are as follow:
>
> add_library(foo SHARED foo.c)
> install(TARGETS foo
>   EXPORT ${MY_TARGETS_NAME}
>   RUNTIME DESTINATION ${MY_INSTALL_BIN_DIR} COMPONENT Applications
>   LIBRARY DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT Libraries
>   INCLUDES DESTINATION ${MY_INSTALL_INCLUDE_DIR}
>   ARCHIVE DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT DebugDevel
> )
>
> where:
>
> MY_INSTALL_BIN_DIR='bin'
> MY_INSTALL_LIB_DIR='lib'
> MY_INSTALL_INCLUDE_DIR='include'
>
> this works quite nicely for basic 'make install', as well as binary
> zip or NSIS installer.
> However this directory layout does not seems to be compatible with
> Windows RIDs[*]. For example my native *.dll files would need to be
> moved from the 'bin' directory to something like 'lib/win7-x64'.
>
> How can I handle conditional install() rules based on CPack generator
> (NuGet in my case) ?
>

I'm not sure you can.
install() rules are processed when CMake runs and generate all
cmake_install.cmake files.
then when CPack runs it triggers the install using the files generated at
CMake time.

So while you can achieve some conditional actions when CPack runs using
CPack project config file
https://cmake.org/cmake/help/v3.14/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE

AFAIK you cannot (re)write install rule because they have already been
processed.

What you could do (as a workaround) in your CMakeLists.txt is to define
both WinXX specific CPack components
and your "generic" CPack components that can be used as a default.
install(TARGETS foo
  EXPORT ${MY_TARGETS_NAME}
  RUNTIME DESTINATION ${MY_INSTALL_BIN_DIR} COMPONENT Applications
  LIBRARY DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT Libraries
  INCLUDES DESTINATION ${MY_INSTALL_INCLUDE_DIR}
  ARCHIVE DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT DebugDevel
)
install(TARGETS foo
  EXPORT ${MY_TARGETS_NAME}
  RUNTIME DESTINATION ${MY_WINXX_INSTALL_BIN_DIR} COMPONENT
Applications-Winxx
  LIBRARY DESTINATION ${MY_WINXX_INSTALL_LIB_DIR} COMPONENT Libraries-Winxx
  INCLUDES DESTINATION ${MY_WINXX_INSTALL_INCLUDE_DIR}
  ARCHIVE DESTINATION ${MY_WINXX_INSTALL_LIB_DIR} COMPONENT DebugDevel-Winxx
)

i.e. install the same thing twice in two places.
and then at CPack time (when CPack runs) code some logic in your CPack
Config file in order
to set  CPACK_COMPONENTS_ALL to appropriate value depending on the value of
https://cmake.org/cmake/help/v3.14/module/CPack.html#variable:CPACK_GENERATOR

something like
if ("${CPACK_GENERATOR}" STREQUAL "NuGet")
   set(CPACK_COMPONENTS_ALL
"Applications-Winxx;Libraries-Winxx;DebugDevel-Winxx")
else()
set(CPACK_COMPONENTS_ALL "Applications;Libraries;DebugDevel")
endif()

that way CPack depending on the generator will ship either "WinXX"
component or "generic" ones.

I think (not tested) it should work but this is clearly a workaround.


Eric



> Thanks,
>
> [*] https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
>
> --
> Mathieu
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored

2019-06-05 Thread Bryan Christ 
Tom,

That was a really helpful tip.  At least as far as building goes, I've
ported my app.  Now on to debugging the system nuances.

Ty!

On Wed, Jun 5, 2019 at 12:13 PM Tom Finegan  wrote:

>
> On Wed, Jun 5, 2019 at 9:29 AM Bryan Christ 
> wrote:
>
>> Tom,
>>
>> I'll give that a try.  Can that variable be changed after project() is
>> called?
>>
>
> Yes, you should be able to change it at any point in your CMake script(s).
>
> Remember that CMAKE__LINKER_FLAGS will effect all targets.
> Restricting your settings changes to the targets for which they are
> intended is usually better than touching variables like
> CMAKE_SHARED_LINKER_FLAGS.  You may have better results using
> target_link_libraries() to set your flags.
>
>
>>
>> On Tue, Jun 4, 2019 at 5:24 PM Tom Finegan  wrote:
>>
>>> I think you want CMAKE_SHARED_LINKER_FLAGS:
>>>
>>>
>>> https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LINKER_FLAGS.html
>>>
>>> You can also use target_link_libraries to pass linker flags:
>>>
>>> https://cmake.org/cmake/help/latest/command/target_link_libraries.html
>>>
>>> On Tue, Jun 4, 2019 at 1:12 PM Bryan Christ 
>>> wrote:
>>>
 For building my project on Linux with gcc I set the following.

 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
 -Wl,--no-as-needed")

 Later, if, the system appears to be OSX, I change it:

 if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")

 set(CMAKE_EXE_LINKER_FLAGS "-Wl,-undefined -Wl,dynamic_lookup")
 set(CMAKE_PREFIX_PATH /usr/local/opt/ncurses)

 endif()

 However, when creating the shared object, linking fails.  The flags are
 not being passed to clang as expected.  When I dive into
 CMakeFile/vterm-shared.dir/link.txt I confirm that the wrong flags are
 there.

 What am I doing wrong?

 --
 Bryan
 <><
 --

 Powered by www.kitware.com

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Kitware offers various services to support the CMake community. For
 more information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Follow this link to subscribe/unsubscribe:
 https://cmake.org/mailman/listinfo/cmake

>>>
>>
>> --
>> Bryan
>> <><
>>
>

-- 
Bryan
<><
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored

2019-06-05 Thread Tom Finegan via CMake 
On Wed, Jun 5, 2019 at 9:29 AM Bryan Christ  wrote:

> Tom,
>
> I'll give that a try.  Can that variable be changed after project() is
> called?
>

Yes, you should be able to change it at any point in your CMake script(s).

Remember that CMAKE__LINKER_FLAGS will effect all targets.
Restricting your settings changes to the targets for which they are
intended is usually better than touching variables like
CMAKE_SHARED_LINKER_FLAGS.  You may have better results using
target_link_libraries() to set your flags.


>
> On Tue, Jun 4, 2019 at 5:24 PM Tom Finegan  wrote:
>
>> I think you want CMAKE_SHARED_LINKER_FLAGS:
>>
>>
>> https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LINKER_FLAGS.html
>>
>> You can also use target_link_libraries to pass linker flags:
>>
>> https://cmake.org/cmake/help/latest/command/target_link_libraries.html
>>
>> On Tue, Jun 4, 2019 at 1:12 PM Bryan Christ 
>> wrote:
>>
>>> For building my project on Linux with gcc I set the following.
>>>
>>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
>>> -Wl,--no-as-needed")
>>>
>>> Later, if, the system appears to be OSX, I change it:
>>>
>>> if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
>>>
>>> set(CMAKE_EXE_LINKER_FLAGS "-Wl,-undefined -Wl,dynamic_lookup")
>>> set(CMAKE_PREFIX_PATH /usr/local/opt/ncurses)
>>>
>>> endif()
>>>
>>> However, when creating the shared object, linking fails.  The flags are
>>> not being passed to clang as expected.  When I dive into
>>> CMakeFile/vterm-shared.dir/link.txt I confirm that the wrong flags are
>>> there.
>>>
>>> What am I doing wrong?
>>>
>>> --
>>> Bryan
>>> <><
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>
>
> --
> Bryan
> <><
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored

2019-06-05 Thread Bryan Christ 
Tom,

I'll give that a try.  Can that variable be changed after project() is
called?

On Tue, Jun 4, 2019 at 5:24 PM Tom Finegan  wrote:

> I think you want CMAKE_SHARED_LINKER_FLAGS:
>
> https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LINKER_FLAGS.html
>
> You can also use target_link_libraries to pass linker flags:
>
> https://cmake.org/cmake/help/latest/command/target_link_libraries.html
>
> On Tue, Jun 4, 2019 at 1:12 PM Bryan Christ 
> wrote:
>
>> For building my project on Linux with gcc I set the following.
>>
>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--no-as-needed")
>>
>> Later, if, the system appears to be OSX, I change it:
>>
>> if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
>>
>> set(CMAKE_EXE_LINKER_FLAGS "-Wl,-undefined -Wl,dynamic_lookup")
>> set(CMAKE_PREFIX_PATH /usr/local/opt/ncurses)
>>
>> endif()
>>
>> However, when creating the shared object, linking fails.  The flags are
>> not being passed to clang as expected.  When I dive into
>> CMakeFile/vterm-shared.dir/link.txt I confirm that the wrong flags are
>> there.
>>
>> What am I doing wrong?
>>
>> --
>> Bryan
>> <><
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>

-- 
Bryan
<><
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking on OSX

2019-06-05 Thread Bryan Christ 
Yes.  Unfortunately the version of curses which is supplied by XCode
doesn't include the wide character support so I have to point elsewhere.

On Tue, Jun 4, 2019 at 5:57 PM Juan E. Sanchez 
wrote:

> Hello,
>
> It looks like you are making progress.  Note that to use the gcc-8 and
> g++-8 compilers from brew, you need to have include files in
> /usr/include.  Otherwise you get strange errors about missing _stdio.h,
> etc.  I believe in another thread, someone suggests how to make sure the
> headers get put in the right place.
>
> I looked and found curses.h (not ncurses.h) here.
> /usr/include/curses.h.
>
> Regards,
>
> Juan
>
>
> On 6/4/19 12:56 PM, Bryan Christ wrote:
> > Juan,
> >
> > Thanks for your suggestions.  I went through that thread pretty
> > thoroughly trying all of the recommended tips and, unfortunately,
> > nothing seemed to work.  I also tried running that open command you
> > cited, but there are still no includes for ncurses in /usr/include or
> > /usr/local/include.  In fact /usr/include doesn't even exist on this
> > system (mojave).
> >
> > On Mon, Jun 3, 2019 at 5:27 PM Juan E. Sanchez  > > wrote:
> >
> > Hello,
> >
> > According to this:
> > https://github.com/neovim/neovim/issues/9050
> >
> > It looks like macOS made it so you have to do something like this:
> > open
> >
>  
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
> >
> > for libraries and includes to be put into /usr.
> >
> > Regards,
> >
> > Juan
> >
> >
> > On 6/3/19 5:16 PM, Bryan Christ wrote:
> >  > New to this mailing list so I hope I'm asking this in the right
> > venue...
> >  >
> >  > I'm trying to port my application (a program and a shared
> > library) to
> >  > OSX.  It was rather easy to modify my CMake script to go from
> > Linux and
> >  > add in FreeBSD.  OSX is giving me a lot of problems though.
> >  >
> >  > First of all find_package() doesn't seem to find the ncurses.dylib
> >  > installed by XCode as it test for wsyncup().  For whatever
> > reason, that
> >  > test fails.  The default location for the library is pretty sane
> >  > (/usr/lib/) but the include file for ncurses is about 9
> > directories deep
> >  > inside of XCode's install directory.  Lots of problems here so I
> > decided
> >  > to look at the symbol linkage for htop and see what it does.  It
> > links
> >  > to a different version that got pulled down via homebrew in
> >  > /usr/local/opt/ncurses/lib (and include respectively)
> >  >
> >  > Is there a way to force CMake to link to the library found there
> > instead
> >  > of in /usr/lib/ ?
> >  >
> >  > --
> >  > Bryan
> >  > <><
> >  >
> >
> > --
> >
> > Powered by www.kitware.com 
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For
> > more information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake
> >
> >
> >
> > --
> > Bryan
> > <><
>
>

-- 
Bryan
<><
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ADD_CUSTOM_TARGET USES_TERMINAL not printing out stuff

2019-06-05 Thread Gonzalo Garramuño 




El 05/06/19 a las 11:51, Brad King escribió:

On 6/5/19 8:27 AM, Gonzalo Garramuño wrote:

This used to print out all that cpack was doing while it was doing it.
Now with v3.15.0-rc1 it just sits there and outputs all the text at the
end when it finishes, which sucks as it looks like it has hung.

Thanks for trying the release candidate!

However, I cannot reproduce this in a simple example:

Thanks Brad, for trying it out.  The problem seems to be related to 
cpack.  I posted a more complete example with a bash wrapup script. You 
will still need to fill in the bin directory of the build with something 
big, so cpack will take a while compressing it.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ADD_CUSTOM_TARGET USES_TERMINAL not printing out stuff

2019-06-05 Thread Brad King via CMake 
On 6/5/19 8:27 AM, Gonzalo Garramuño wrote:
> This used to print out all that cpack was doing while it was doing it.  
> Now with v3.15.0-rc1 it just sits there and outputs all the text at the 
> end when it finishes, which sucks as it looks like it has hung.

Thanks for trying the release candidate!

However, I cannot reproduce this in a simple example:


```
$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(UsesTerminal NONE)
add_custom_target(UseTerminal ALL
  COMMAND sh "${CMAKE_CURRENT_SOURCE_DIR}/custom.sh"
  USES_TERMINAL
  )

$ cat ../custom.sh
echo first
sleep 1
echo second
sleep 1
echo third

$ cmake --version
cmake version 3.15.0-rc1
...

$ cmake .. -GNinja

$ ninja UseTerminal
...
first
second
third
```

While ninja is running I can see one line print at a time separated
by one second each.

Please try to provide a more complete standalone example.  Also please
open an issue for this at https://gitlab.kitware.com/cmake/cmake/issues

Does `pool = console` appear in the `build.ninja` rule for your custom target?

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] ADD_CUSTOM_TARGET USES_TERMINAL not printing out stuff

2019-06-05 Thread Gonzalo Garramuño 

I run cpack with the trick of using a custom configuration.

ADD_CUSTOM_TARGET( bundle
               COMMAND "${CMAKE_CPACK_COMMAND}"
               "-C" "$"
               "--config" "${CMAKE_BINARY_DIR}/BundleConfig.cmake"
               COMMENT "Running CPack. Please wait..."
               USES_TERMINAL
               DEPENDS translations )

This used to print out all that cpack was doing while it was doing it.  
Now with v3.15.0-rc1 it just sits there and outputs all the text at the 
end when it finishes, which sucks as it looks like it has hung.


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Project warning since 3.15.0-rc1

2019-06-05 Thread Volker Enderlein 

Hi,


I encapsulate the literal **project** call in a **macro** that is adding 
some general settings required for every project setup.


This worked flawlessly and without warnings in the last CMake versions 
since 3.4.


Beginning with CMake Version 3.15.0-rc1 the following warning pops up:

No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

    project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.


Is that a regression or is the required behavior more strictly enforced now?


Cheers, Volker


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Conditional install() rules based on CPack generator

2019-06-05 Thread Mathieu Malaterre 
Hi there,

I am trying to use NuGet generator for GDCM project. Typically my
install rules are as follow:

add_library(foo SHARED foo.c)
install(TARGETS foo
  EXPORT ${MY_TARGETS_NAME}
  RUNTIME DESTINATION ${MY_INSTALL_BIN_DIR} COMPONENT Applications
  LIBRARY DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT Libraries
  INCLUDES DESTINATION ${MY_INSTALL_INCLUDE_DIR}
  ARCHIVE DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT DebugDevel
)

where:

MY_INSTALL_BIN_DIR='bin'
MY_INSTALL_LIB_DIR='lib'
MY_INSTALL_INCLUDE_DIR='include'

this works quite nicely for basic 'make install', as well as binary
zip or NSIS installer.
However this directory layout does not seems to be compatible with
Windows RIDs[*]. For example my native *.dll files would need to be
moved from the 'bin' directory to something like 'lib/win7-x64'.

How can I handle conditional install() rules based on CPack generator
(NuGet in my case) ?

Thanks,

[*] https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

-- 
Mathieu
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake