Re: [CMake] Visual Studio Cross Compile

[J Decker]

for windows platform using cmake, you just need mingw (mingw64 is
probably better)

On Mon, Nov 2, 2015 at 9:36 AM, Michael Jäntsch
 wrote:
> Hi,
>
> thanks for your replies. So it seems that Visual Studio is generally not
> a great idea for cross-compiling...
> So eclipse and some make system it's gonna be then. Any suggestions what
> works best? Coming from the Linux world, I obviously use Unix make, but
> there is also Ninja, nmake, ...?
>
> Michael
>
>
> On 02.11.2015 15:51, Parag Chandra wrote:
>> Hi Michael,
>>
>> Meant to reply sooner. As Nils pointed out, Visual Studio isn’t quite as 
>> flexible with cross-compilation as some other build systems. Having said 
>> that, it is indeed possible to cross-compile with Visual Studio, but there 
>> has to be a cross toolchain compatible with the IDE. Some examples of this 
>> include:
>>
>> Google’s Native Client - I have successfully targeted this environment with 
>> Visual Studio 2010 and Cmake;
>>
>> Windows Phone 8.1/10 - Have targeted this as well. While you may be thinking 
>> “that’s just another flavor of Windows”, it is nevertheless cross-compiling 
>> for ARM;
>>
>> Several options for Android development:
>> Nvidia Tegra Studio;
>> Visual Studio 2015 - Microsoft now offers first-party support within VS 2015;
>> VS-Android;
>>
>> Commercial/paid add-ons that seem to support arbitrary GCC toolchains:
>> Visual GDB - This one may be your best bet for what you are trying to 
>> accomplish. Supports Linux, Android, Raspberry Pi, etc. out of the box, and 
>> they claim to have an extensibility model to add your own platforms;
>> WinGDB - similarly seems to support the GNU toolchain directly.
>>
>> Anyway, hopefully you get the idea. It is possible, but out of the box, 
>> you’re only going to be able to target Windows Phone and Android.
>>
>>
>> Parag Chandra
>> Senior Software Engineer, Mobile Team
>> Mobile: +1.919.824.1410
>>
>>  
>>
>> Ionic Security Inc.
>> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 10/29/15, 10:21 AM, "CMake on behalf of Michael Jaentsch" 
>>  wrote:
>>
>>> Hi all,
>>>
>>> I have a question concerning Cross Compiling with CMake on Windows. I
>>> would like to use Visual Studio but this is not a must. What I do is, I
>>> setup a project for Cross Compiling on Linux and it works fine. Now I
>>> want to transfer to Windows, so I set up a toolchain file which sets the
>>> following variables:
>>> CMAKE_SYSTEM_NAME
>>> CMAKE_SYSTEM_PROCESSOR
>>> CMAKE_FIND_ROOT_PATH
>>> CMAKE_C_COMPILER
>>> CMAKE_CXX_COMPILER
>>>
>>> and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2)
>>> on Windows and tell it to generate a project for Visual Studio 10 and to
>>> use the toolchain file. However, the output shows that it is trying to
>>> use the Visual Studio compiler and then subsequently the build fails
>>> because of some unkown compiler flags.
>>>
>>> So my question is: Is it even possible to do what I'm trying to do? Can
>>> I cross compile with Visual Studio or do I have to use a different
>>> generator? All I found in the documentation is that it is possible to
>>> cross compile with a toolchain file...
>>>
>>> Cheers
>>> Michael
>>>
>>>
>>> --
>>> Technische Universität München
>>> Michael Jäntsch
>>> Fakultät für Informatik
>>> Robotics and Embedded Systems
>>> Parkring 13
>>> 85748 Garching bei München
>>> michael.jaent...@in.tum.de
>>> www6.in.tum.de
>>> --
>>>
>>> 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:
>>> http://public.kitware.com/mailman/listinfo/cmake
>
> --
> Technische Universität München
> Michael Jäntsch
> Fakultät für Informatik
> Robotics and Embedded Systems
> Boltzmannstr. 3
> 85748 Garching bei München
> michael.jaent...@in.tum.de
> www6.in.tum.de
>
> --
>
> 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:
> http://public.kitware.com/m

[CMake] FOSDEM Desktops DevRoom 2016: Call for Participation

[Pau Garcia i Quiles]

FOSDEM Desktops DevRoom 2016 Call for Participation

FOSDEM is one of the largest gatherings of Free Software contributors in
the world and happens each February in Brussels (Belgium, Europe). One of
the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop
DevRoom”), which will host Desktop-related talks.

We are now inviting proposals for talks about Free/Libre/Open-source
Software on the topics of Desktop development, Desktop applications and
interoperability amongst Desktop Environments. This is a unique opportunity
to show novel ideas and developments to a wide technical audience.

Topics accepted include, but are not limited to:

   - Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE,
   Cinnamon, ReactOS, etc

   - Closed desktops: Windows, Mac OS X, CDE, MorphOS, etc (when talking
   about a FLOSS topic)

   - Software development for the desktop

   - Development tools

   - Applications that enhance desktops

   - General desktop matters

   - Cross-platform software development

   - Web


Talks can be very specific, such as the advantages/disadvantages of
development with Qt on Wayland over X11/Mir; or as general as predictions
for the fusion of Desktop and web in 5 years time. Topics that are of
interest to the users and developers of all desktop environments are
especially welcome. The FOSDEM 2015 schedule[1] might give you some
inspiration.


Submissions

Please include the following information when submitting a proposal:

   - Your name

   - The title of your talk (please be descriptive, as titles will be
   listed with around 400 from other projects)

   - Short abstract of one or two paragraphs

   - Short bio (with photo)

   - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes.
   Longer duration requests must be properly justified. You may be assigned
   LESS time than you request.


How to submit

All submissions are made in the Pentabarf event planning tool:

https://penta.fosdem.org/submission/FOSDEM16

When submitting your talk, make sure to select the "Desktops" devroom as
the "Track". Otherwise your talk will not be even considered for any
devroom.

If you already have a Pentabarf account from a previous year, even if your
talk was not accepted, please reuse it. Create an account if, and only if,
you don’t have one from a previous year. If you have any issues with
Pentabarf, please contact pgquiles at elpauer dot org.


Deadline

The deadline for submissions is December 6th 2015.

FOSDEM will be held on the weekend of January 30th and 31st 2015 and the
Desktops DevRoom will take place on Sunday, January 31st 2015.

We will contact every submitter with a "yes" or "no" before December 18th
2015.


Recording permission

The talks in the Desktops devroom will be audio and video recorded, and
possibly streamed live too.

By submitting a proposal you consent to be recorded and agree to license
the content of your talk under a Creative Commons (CC-BY) license.

If you want us to stop the recording in the Q & A part (should you have
one), please tell us. We can do that but only for the Q & A part.


More information

The official communication channel for the Desktops DevRoom is its mailing
list desktops-devr...@lists.fosdem.org.

Use this page to manage your subscription:

https://lists.fosdem.org/listinfo/desktops-devroom


Organization

The Desktops DevRoom 2016 is managed by a team representing the most
notable open desktops:


   - Pau Garcia i Quiles, KDE

   - Christophe Fergeau, Gnome

   - Michael Zanetti, Unity

   - Philippe Caseiro, Enlightenment

   - Jérome Leclanche, Razor


If you want to join the team, please contact pgquiles at elpauer dot org


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CMake on OpenVMS - Bootstrap CMake complaining that “pid_t doesn’t exist on this platform?”

[Custin, Jay (CSC Sw Middleware)]

Please disregard my query regarding pid_t.  Apparently something “lingered” 
around in my code environment.  When I wiped out the code tree leaving nothing 
except my VMS-related modifications and rebuilt CMake it built without the 
pid_t error.  Go figure.  Back to trying to determine where the bootstrapped 
CMake of the CMake code (to generate the final “image”) fails).


JayC
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual Studio Cross Compile

[Michael Jäntsch]

Hi,

thanks for your replies. So it seems that Visual Studio is generally not
a great idea for cross-compiling...
So eclipse and some make system it's gonna be then. Any suggestions what
works best? Coming from the Linux world, I obviously use Unix make, but
there is also Ninja, nmake, ...?

Michael


On 02.11.2015 15:51, Parag Chandra wrote:
> Hi Michael,
>
> Meant to reply sooner. As Nils pointed out, Visual Studio isn’t quite as 
> flexible with cross-compilation as some other build systems. Having said 
> that, it is indeed possible to cross-compile with Visual Studio, but there 
> has to be a cross toolchain compatible with the IDE. Some examples of this 
> include:
>
> Google’s Native Client - I have successfully targeted this environment with 
> Visual Studio 2010 and Cmake;
>
> Windows Phone 8.1/10 - Have targeted this as well. While you may be thinking 
> “that’s just another flavor of Windows”, it is nevertheless cross-compiling 
> for ARM;
>
> Several options for Android development:
> Nvidia Tegra Studio;
> Visual Studio 2015 - Microsoft now offers first-party support within VS 2015;
> VS-Android;
>
> Commercial/paid add-ons that seem to support arbitrary GCC toolchains:
> Visual GDB - This one may be your best bet for what you are trying to 
> accomplish. Supports Linux, Android, Raspberry Pi, etc. out of the box, and 
> they claim to have an extensibility model to add your own platforms;
> WinGDB - similarly seems to support the GNU toolchain directly.
>
> Anyway, hopefully you get the idea. It is possible, but out of the box, 
> you’re only going to be able to target Windows Phone and Android.
>
>
> Parag Chandra
> Senior Software Engineer, Mobile Team
> Mobile: +1.919.824.1410
>
>   
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 10/29/15, 10:21 AM, "CMake on behalf of Michael Jaentsch" 
>  wrote:
>
>> Hi all,
>>
>> I have a question concerning Cross Compiling with CMake on Windows. I 
>> would like to use Visual Studio but this is not a must. What I do is, I 
>> setup a project for Cross Compiling on Linux and it works fine. Now I 
>> want to transfer to Windows, so I set up a toolchain file which sets the 
>> following variables:
>> CMAKE_SYSTEM_NAME
>> CMAKE_SYSTEM_PROCESSOR
>> CMAKE_FIND_ROOT_PATH
>> CMAKE_C_COMPILER
>> CMAKE_CXX_COMPILER
>>
>> and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) 
>> on Windows and tell it to generate a project for Visual Studio 10 and to 
>> use the toolchain file. However, the output shows that it is trying to 
>> use the Visual Studio compiler and then subsequently the build fails 
>> because of some unkown compiler flags.
>>
>> So my question is: Is it even possible to do what I'm trying to do? Can 
>> I cross compile with Visual Studio or do I have to use a different 
>> generator? All I found in the documentation is that it is possible to 
>> cross compile with a toolchain file...
>>
>> Cheers
>> Michael
>>
>>
>> -- 
>> Technische Universität München
>> Michael Jäntsch
>> Fakultät für Informatik
>> Robotics and Embedded Systems
>> Parkring 13
>> 85748 Garching bei München
>> michael.jaent...@in.tum.de
>> www6.in.tum.de
>> -- 
>>
>> 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:
>> http://public.kitware.com/mailman/listinfo/cmake

-- 
Technische Universität München
Michael Jäntsch
Fakultät für Informatik
Robotics and Embedded Systems
Boltzmannstr. 3
85748 Garching bei München
michael.jaent...@in.tum.de
www6.in.tum.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] getting the rpath right on osx

[Andreas Pakulat]

Hi,

On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson 
wrote:

> On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote:
> > Hi,
> >
> > On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt 
> wrote:
> > > On Mon, 2 Nov 2015, Andreas Pakulat wrote:
> > >
> > > I think the idea of using @rpath as install name of the Qt libraries is
> > >
> > >> geared towards the usecase
> > >> of shipping Qt within the application bundle of the application. In
> that
> > >> case all you need is set
> > >> the rpath @executable_path/../Frameworks or so in the executable and
> thus
> > >> the app-bundle is
> > >> relocatable. In order to get that with CMake you'll likely need to use
> > >> the BundleUtilities, though
> > >> its been so long since I used those I don't know if they can handle
> this
> > >> scenario out of the box.
> > >
> > > Yes, that's what I'm trying to do -- well, I'm trying to do two
> > > things. One is setup a build environment where kde apps like
> desktoptojson
> > > can run, the other is creating a bundle, preferably using the same
> > > Qt. I got quite far by manually fixing up the applications built as
> part
> > > of kcoreaddons
> >
> > That would be fixed in kcoreaddons by extending the linker flags to
> include
> > the mentioned -Wl,-rpath,. There's no provisioning for this
> > inside CMake afaik since its hard for it to guess what the intention is.
>
> CMake does automatically handle this.  If a library being linked has @rpath
> for its install ID, then CMake will insert the linker flag.  This takes
> care of
> the build time rpath.  And works for any library in target_link_libraries()
> where CMake knows its full path.  A -L/-l approach does not work, but that
> is
> usually done for system libraries, in which case we normally don't care
> about
> rpaths.
>
> This kind of thing isn't handled automatically at install time, and
> requires
> the INSTALL_RPATH property to be set.


Thanks for correcting me - didn't see your first mail until now either. It
seems I'm really out of touch with CMake these days :)

So I guess KDE frameworks that generate development-tools lack the
INSTALL_RPATH - at least that would explain the necessity to manually patch
them. A relative path like you mentioned should work as long as Qt is
installed in the same prefix as those tools - which is likely the common
case.

An end-user application then can either decide to be installed in the same
way or it wants an app-bundle, then it could use an INSTALL_RPATH like
@executable/../Frameworks and bunlde the Qt frameworks inside that
subdirectory.

Andreas
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] getting the rpath right on osx

[clinton]

- On Nov 2, 2015, at 2:26 AM, Boudewijn Rempt b...@valdyas.org wrote:

> I checked the manual and the blog post about rpath on osx, but I'm still
> confused, and still not getting it right...
> 
> I build and installed Qt 5.6 alpha like this:
> 
> ./configure -prefix /Users/boudewijnrempt/kf5/i
> 
> Then I made a small test project, consisting of nothing but a main that links 
> to
> QtCore.
> 
> If I build that with qmake, with this .pro file:
> 
> QT   += core
> QT   -= gui
> TARGET = rpathqmake
> CONFIG   += console
> CONFIG   -= app_bundle
> TEMPLATE = app
> SOURCES += main.cpp
> 
> The r-path is set:
> 
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
> current
> version 5.6.0)
> 
> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
> (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
> version 1.0.0, current version 275.0.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1213.0.0)
> 
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
> current
> version 5.6.0

Keep in mind, "otool -L" doesn't show rpaths.
@rpath/QtCore.framework/Versions/5/QtCore is not an rpath.
@rpath is a place holder where an rpath can be substituted.
Anytime you see "@rpath" what it means is that the dependent library wants to 
be found using rpaths.
Use "otool -l" | grep -A2 LC_RPATH to see the rpaths.

> 
> If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and 
> without
> all those RPATH related lines,
> they don't seem to make a difference. I'm using cmake 3.3.2.
> 
> cmake_minimum_required(VERSION 2.8.12)
> cmake_policy(SET CMP0042 NEW)
> set(CMAKE_MACOSX_RPATH ON)
> SET(CMAKE_SKIP_BUILD_RPATH TRUE)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> set(REQUIRED_QT_VERSION 5.3.0)
> find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
> add_executable(rpathcmake main.cpp)
> target_link_libraries(rpathcmake Qt5::Core)
> install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)

If you remove 
 set(CMAKE_MACOSX_RPATH ON)
 SET(CMAKE_SKIP_BUILD_RPATH TRUE)
 SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
 SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
then, it would probably be a minimal example.

> 
> Only adding something like this makes it work:
> 
> set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
> "/Users/boudewijnrempt/kf5/i/lib")
> 
> Which I'm pretty sure is something I don't want.

To fix the errors below, you actually to do something like this.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
 "/Users/boudewijnrempt/kf5/i/lib")

What you probably want is to use a variable instead of an absolute path.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
 "@loader_path/../lib")

That property along with MACOSX_RPATH, or the global property 
CMAKE_MACOSX_RPATH are the 2 first variables you would set.
MACOSX_RPATH property on a target indicates that its install 'ID' contains 
@rpath, and it wants to be found using rpaths.  INSTALL_RPATH property is a 
list of rpaths to help find dependencies which want to be found using rpaths.

> 
> Boudewijns-Mac-mini:test boudewijnrempt$ make install
> [100%] Built target rpathcmake
> Install the project...
> -- Install configuration: ""
> -- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
> current
> version 5.6.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake
> dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore
>   Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
>   Reason: image not found
> Trace/BPT trap: 5
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
> current
> version 5.6.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> 
> What should I do?

Set the INSTALL_RPATH target property.

Clint

-- 

Powered by www.kitware.com

Pleas

Re: [CMake] getting the rpath right on osx

[Andreas Pakulat]

Hi,

On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt  wrote:

> On Mon, 2 Nov 2015, Andreas Pakulat wrote:
>
> I think the idea of using @rpath as install name of the Qt libraries is
>> geared towards the usecase
>> of shipping Qt within the application bundle of the application. In that
>> case all you need is set
>> the rpath @executable_path/../Frameworks or so in the executable and thus
>> the app-bundle is
>> relocatable. In order to get that with CMake you'll likely need to use
>> the BundleUtilities, though
>> its been so long since I used those I don't know if they can handle this
>> scenario out of the box.
>>
>>
> Yes, that's what I'm trying to do -- well, I'm trying to do two
> things. One is setup a build environment where kde apps like desktoptojson
> can run, the other is creating a bundle, preferably using the same
> Qt. I got quite far by manually fixing up the applications built as part
> of kcoreaddons


That would be fixed in kcoreaddons by extending the linker flags to include
the mentioned -Wl,-rpath,. There's no provisioning for this
inside CMake afaik since its hard for it to guess what the intention is. My
understanding (not a OSX expert yet here) is also that having the install
name of a framework on OSX be something like @rpath is quite unusual. Thats
usually something that users are 'patching' when they bundle their
application via install_name_tool. And thats what CMake supports doing via
the BundleUtilities module.


> and then manually patching up the executable inside the
> bundle to have the @executable_path/../Frameworks rpath added. But I'm
> still not sure why with a really simple example things don't work out
> of the box: I guess I had better build Qt with -norpath.


See above, I think the way the Qt frameworks are setup when using -rpath is
simply not expected/anticipated so far by CMake (or the people maintaining
the qt5 cmake modules inside Qt).

However I never tried to use BundleUtilities with such a framework, maybe
they do manage to 'fixup' things for that as well. For a Qt4-based project
I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle
from BundleUtilities, so may be worth a try to avoid the manual steps.

Even a Qt built with -norpath would require doing some 'manual' things to
get a all-in-one app bundle for the application (or use of
BundleUtilities), to copy things around and adjust the install and link
names in all the frameworks and executables to be related and thus make the
application relocatable.

Andreas
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake on OpenVMS - Bootstrap CMake complaining that “pid_t doesn’t exist on this platform?”

[Bill Hoffman]

On 11/1/2015 4:19 PM, Custin, Jay (CSC Sw Middleware) wrote:

Anyone have any ideas?


Look in the CMakeError.log file and find out why it is not finding pid_t.

-Bill


--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] getting the rpath right on osx

[Clinton Stimpson]

On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote:
> Hi,
> 
> On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt  wrote:
> > On Mon, 2 Nov 2015, Andreas Pakulat wrote:
> > 
> > I think the idea of using @rpath as install name of the Qt libraries is
> > 
> >> geared towards the usecase
> >> of shipping Qt within the application bundle of the application. In that
> >> case all you need is set
> >> the rpath @executable_path/../Frameworks or so in the executable and thus
> >> the app-bundle is
> >> relocatable. In order to get that with CMake you'll likely need to use
> >> the BundleUtilities, though
> >> its been so long since I used those I don't know if they can handle this
> >> scenario out of the box.
> > 
> > Yes, that's what I'm trying to do -- well, I'm trying to do two
> > things. One is setup a build environment where kde apps like desktoptojson
> > can run, the other is creating a bundle, preferably using the same
> > Qt. I got quite far by manually fixing up the applications built as part
> > of kcoreaddons
> 
> That would be fixed in kcoreaddons by extending the linker flags to include
> the mentioned -Wl,-rpath,. There's no provisioning for this
> inside CMake afaik since its hard for it to guess what the intention is.

CMake does automatically handle this.  If a library being linked has @rpath 
for its install ID, then CMake will insert the linker flag.  This takes care of 
the build time rpath.  And works for any library in target_link_libraries() 
where CMake knows its full path.  A -L/-l approach does not work, but that is 
usually done for system libraries, in which case we normally don't care about 
rpaths.

This kind of thing isn't handled automatically at install time, and requires 
the INSTALL_RPATH property to be set.

> My
> understanding (not a OSX expert yet here) is also that having the install
> name of a framework on OSX be something like @rpath is quite unusual. Thats
> usually something that users are 'patching' when they bundle their
> application via install_name_tool. And thats what CMake supports doing via
> the BundleUtilities module.

If install rpaths are set correctly, and all copied 3rd party libraries use 
@rpath, there is no need for patching with install_name_tool.


> 
> > and then manually patching up the executable inside the
> > bundle to have the @executable_path/../Frameworks rpath added. But I'm
> > still not sure why with a really simple example things don't work out
> > of the box: I guess I had better build Qt with -norpath.
> 
> See above, I think the way the Qt frameworks are setup when using -rpath is
> simply not expected/anticipated so far by CMake (or the people maintaining
> the qt5 cmake modules inside Qt).

It is handled fine by CMake.  If not, it would be a bug.

> 
> However I never tried to use BundleUtilities with such a framework, maybe
> they do manage to 'fixup' things for that as well. For a Qt4-based project
> I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle
> from BundleUtilities, so may be worth a try to avoid the manual steps.
> 
> Even a Qt built with -norpath would require doing some 'manual' things to
> get a all-in-one app bundle for the application (or use of
> BundleUtilities), to copy things around and adjust the install and link
> names in all the frameworks and executables to be related and thus make the
> application relocatable.

Yes, a Qt built with -norpath will require extra patching steps with 
install_name_tool.

Clint

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual Studio Cross Compile

[Parag Chandra]

Hi Michael,

Meant to reply sooner. As Nils pointed out, Visual Studio isn’t quite as 
flexible with cross-compilation as some other build systems. Having said that, 
it is indeed possible to cross-compile with Visual Studio, but there has to be 
a cross toolchain compatible with the IDE. Some examples of this include:

Google’s Native Client - I have successfully targeted this environment with 
Visual Studio 2010 and Cmake;

Windows Phone 8.1/10 - Have targeted this as well. While you may be thinking 
“that’s just another flavor of Windows”, it is nevertheless cross-compiling for 
ARM;

Several options for Android development:
Nvidia Tegra Studio;
Visual Studio 2015 - Microsoft now offers first-party support within VS 2015;
VS-Android;

Commercial/paid add-ons that seem to support arbitrary GCC toolchains:
Visual GDB - This one may be your best bet for what you are trying to 
accomplish. Supports Linux, Android, Raspberry Pi, etc. out of the box, and 
they claim to have an extensibility model to add your own platforms;
WinGDB - similarly seems to support the GNU toolchain directly.

Anyway, hopefully you get the idea. It is possible, but out of the box, you’re 
only going to be able to target Windows Phone and Android.


Parag Chandra
Senior Software Engineer, Mobile Team
Mobile: +1.919.824.1410

  

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309













On 10/29/15, 10:21 AM, "CMake on behalf of Michael Jaentsch" 
 wrote:

>Hi all,
>
>I have a question concerning Cross Compiling with CMake on Windows. I 
>would like to use Visual Studio but this is not a must. What I do is, I 
>setup a project for Cross Compiling on Linux and it works fine. Now I 
>want to transfer to Windows, so I set up a toolchain file which sets the 
>following variables:
>CMAKE_SYSTEM_NAME
>CMAKE_SYSTEM_PROCESSOR
>CMAKE_FIND_ROOT_PATH
>CMAKE_C_COMPILER
>CMAKE_CXX_COMPILER
>
>and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) 
>on Windows and tell it to generate a project for Visual Studio 10 and to 
>use the toolchain file. However, the output shows that it is trying to 
>use the Visual Studio compiler and then subsequently the build fails 
>because of some unkown compiler flags.
>
>So my question is: Is it even possible to do what I'm trying to do? Can 
>I cross compile with Visual Studio or do I have to use a different 
>generator? All I found in the documentation is that it is possible to 
>cross compile with a toolchain file...
>
>Cheers
>Michael
>
>
>-- 
>Technische Universität München
>Michael Jäntsch
>Fakultät für Informatik
>Robotics and Embedded Systems
>Parkring 13
>85748 Garching bei München
>michael.jaent...@in.tum.de
>www6.in.tum.de
>-- 
>
>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:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] FIND_LIBRARY & TARGET_LINK_LIBRARIES

[Ette, Anthony (CDS)]

Background info:
On version 3.3.20150618. RedHawk Linux 5.1.1 (real-time variant of RHEL5).

Description:
I am not understanding the behavior of these two commands or am getting 
inconsistent results. Sometimes when the results of a found static library from 
FIND_LIBRARY are passed to TARGET_LINK_LIBRARIES, it generates "/path/to/lib" 
linker syntax BUT other times it produces a "-Wl,-Bstatic -llib -Wl,-Bdynamic" 
syntax. I've confirmed that both lib vars as returned from FIND_LIBRARY are 
full paths to .a static archive files so how can the different handling at the 
linker CLI be explained?

Steps to reproduce:
Unknown. Some libs are handled one way and others are handled another. The only 
potential lead may be that they come from different paths on the file system 
(say one from /usr/lib and another from LIB_DIR=/sim/lib/v67/ihawk).

Example:
PROJECT(ec_interface)

# static arhive #1 from /sim/lib/v67/ihawk
FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D)
FIND_LIBRARY(libshm NAMES shm PATHS ${LIB_D} NO_DEFAULT_PATH)
MESSAGE("libshm: " ${libshm})

# static archive #2 from /usr/lib
FILE(TO_CMAKE_PATH /usr/lib USR_LIB)
FIND_LIBRARY(libccur_fbsched NAMES libccur_fbsched.a PATHS ${USR_LIB} 
NO_DEFAULT_PATH)
MESSAGE("libccur_fbsched: " ${libccur_fbsched})

SET(SOURCES ec_interface.cpp)
ADD_EXECUTABLE(ec_interface ${SOURCES})
TARGET_LINK_LIBRARIES(ec_interface ${libshm} ${libccur_fbsched})

Notice in the resulting linker command below how libshm and libccur_fbsched are 
handled very differently, why is this?:

/usr/bin/g++ -O3 -DNDEBUG CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o 
../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a -Wl,-Bstatic 
-lccur_fbsched -Wl,-Bdynamic

If I remove libccur_fbsched from the TARGET_LINK_LIBRARIES, the resulting 
linker command is:

/usr/bin/g++   -O3 -DNDEBUG   CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o 
../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a

I guess it's also important to note that in LIB_D, only .a files exist (i.e. 
there is only a libshm.a and no libshm.so file). However, in /usr/lib, there 
are multiple files by the same name with different suffixes (e.g. 
libccur_fbsched.a, libccur_fbsched.so, etc.). That is why I am specifying the 
".a" explicitly in the FIND_LIBRARY command for libccur_fbsched in an attempt 
to force it to pick up the static archive and not the dynamic ones. The message 
I'm printing seems to indicate it is using the static, so I still don't 
understand the resulting link command. How fine tuned of control do I have over 
the resulting link command? I.e. can I force libccur_fbsched to show up as 
"/usr/lib/libccur_fbsched.a" and not as "-Wl,-Bstatic -lccur_fbsched 
-Wl,-Bdynamic"?

Lastly, I've found that if I instead ADD_LIBRARY as shown below, I can force 
the generated link command to use simply "/usr/lib/libccur_fbsched.a" as 
desired although I don't believe this is the recommended way of doing things. I 
thought FIND_LIBRARY was supposed to be used here (whereas ADD_LIBRARY is 
intended to be used when the library is created within the scope of current 
CMake project)?  Can anyone explain how/why CMake is generating different 
linker output for different static archives that are found using the same 
method (i.e. using FIND_LIBRARY then passing result to TARGET_LINK_LIBRARIES) 
where the extension is specified in one case but not the other?

ADD_LIBRARY(libccur_fbsched STATIC IMPORTED)
SET_PROPERTY(TARGET libccur_fbsched PROPERTY IMPORTED_LOCATION 
${USR_LIB}/libccur_fbsched${LIBEXT})
TARGET_LINK_LIBRARIES(ec_interface ${libshm} libccur_fbsched)

/usr/bin/g++   -O3 -DNDEBUG CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o 
../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a 
/usr/lib/libccur_fbsched.a


Thanks,
Anthony Ette
Technical Specialist, Software & Modeling

Rolls-Royce Controls and Data Services
7661 N Perimeter Rd
Indianapolis, IN 46241
tel: +1 (317) 230-6943
mob: +1 (317) 864-7975
email: anthony.r.e...@controlsdata.com

This e-mail (including attachments) contains contents owned by Rolls-Royce plc 
and its subsidiaries, affiliated companies or customers and covered by the laws 
of England and Wales, Brazil, US, or Canada (federal, state or provincial). The 
information contained in this email is intended to be confidential, may be 
legally privileged and subject to export controls which may restrict the access 
to and transfer of the information. If you are not the intended recipient, you 
are hereby notified that any retention, dissemination, distribution, 
interception or copying of this communication is strictly prohibited and may 
subject you to further legal action. Reply to the sender if you received this 
email by accident, and then delete the email and any attachments.
-- 

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 sup

Re: [CMake] getting the rpath right on osx

[Boudewijn Rempt]

On Mon, 2 Nov 2015, Andreas Pakulat wrote:


I think the idea of using @rpath as install name of the Qt libraries is geared 
towards the usecase
of shipping Qt within the application bundle of the application. In that case 
all you need is set
the rpath @executable_path/../Frameworks or so in the executable and thus the 
app-bundle is
relocatable. In order to get that with CMake you'll likely need to use the 
BundleUtilities, though
its been so long since I used those I don't know if they can handle this 
scenario out of the box.



Yes, that's what I'm trying to do -- well, I'm trying to do two
things. One is setup a build environment where kde apps like desktoptojson
can run, the other is creating a bundle, preferably using the same
Qt. I got quite far by manually fixing up the applications built as part
of kcoreaddons and then manually patching up the executable inside the
bundle to have the @executable_path/../Frameworks rpath added. But I'm
still not sure why with a really simple example things don't work out
of the box: I guess I had better build Qt with -norpath.

Boudewijn
--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] getting the rpath right on osx

[Andreas Pakulat]

Hi,

On Mon, Nov 2, 2015 at 10:26 AM, Boudewijn Rempt  wrote:

> I checked the manual and the blog post about rpath on osx, but I'm still
> confused, and still not getting it right...
>
> I build and installed Qt 5.6 alpha like this:
>
> ./configure -prefix /Users/boudewijnrempt/kf5/i
>
> Then I made a small test project, consisting of nothing but a main that
> links to QtCore.
>
> If I build that with qmake, with this .pro file:
>
> QT   += core
> QT   -= gui
> TARGET = rpathqmake
> CONFIG   += console
> CONFIG   -= app_bundle
> TEMPLATE = app
> SOURCES += main.cpp
>
> The r-path is set:
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version
> 5.6.0, current version 5.6.0)
>
> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
> (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
> (compatibility version 1.0.0, current version 275.0.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1213.0.0)
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i
> rpath
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version
> 5.6.0, current version 5.6.0
>

Thats not the rpath in your executable, thats just the install name of the
QtCore library. And the install name indicates that you need to set an
rpath in your executable that points to the installation directory of Qt.
In order to see the rpath entries of your executable you'll need to check
for the LC_RPATH command in the output of this:

otool -l rpathqmake

It will show the absolute path to the Qt installation on your system.


> If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and
> without all those RPATH related lines,
> they don't seem to make a difference. I'm using cmake 3.3.2.
>
> cmake_minimum_required(VERSION 2.8.12)
> cmake_policy(SET CMP0042 NEW)
> set(CMAKE_MACOSX_RPATH ON)
> SET(CMAKE_SKIP_BUILD_RPATH TRUE)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> set(REQUIRED_QT_VERSION 5.3.0)
> find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
> add_executable(rpathcmake main.cpp)
> target_link_libraries(rpathcmake Qt5::Core)
> install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)
>
> Only adding something like this makes it work:
>
> set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
> "/Users/boudewijnrempt/kf5/i/lib")
>

I guess thats where your Qt is installed to? Then yes, that is exactly what
you want since thats where Qt is and the Qt libraries require an rpath to
be set to be found since 5.5 on OSX. You just don't want to hardcode this,
but rather calculate it off of the path of the QtCore library. Or even
better would be if the Qt5 cmake modules would provide some provision to
add the necessary linker commandline argument to inject the rpath during
linking into the executable. Thats how qmake makes things 'work out of the
box', it knows Qt has been built with the rpath-flag (default since 5.5)
and then adds something like -Wl,-rpath, to the linker
commandline of the generated Makefile.

I think the idea of using @rpath as install name of the Qt libraries is
geared towards the usecase of shipping Qt within the application bundle of
the application. In that case all you need is set the rpath
@executable_path/../Frameworks or so in the executable and thus the
app-bundle is relocatable. In order to get that with CMake you'll likely
need to use the BundleUtilities, though its been so long since I used those
I don't know if they can handle this scenario out of the box.

Andreas
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual Studio Cross Compile

[Nils Gladitz]

On 11/02/2015 12:41 PM, Michael Jäntsch wrote:

Hi again,

Is there nobody who can help me? I thought it would be a common thing 
to use cmake to cross compile!? Has nobody ever used visual studio to 
do so?


Visual Studio itself does not have compiler selection in the same sense 
as is available with e.g. Makefiles or Ninja.
It can not be directly told to use specific compiler paths (you will not 
find any compiler paths in the generated solutions/projects).


It does support "Platform Toolset"s which in manually created projects 
can be set/seen in the "General" project settings and in CMake generated 
projects can be set via the -T option [1].


I'd stick to Ninja or Makefiles for cross-compiles unless you are 
targeting something with pre-existing toolset support.
I think e.g. Android is supported via CMAKE_SYSTEM_NAME "Android" and 
NVIDIA Nsight Tegra integration [2].


Nils

[1] https://cmake.org/cmake/help/v3.3/variable/CMAKE_GENERATOR_TOOLSET.html
[2] https://cmake.org/cmake/help/v3.3/release/3.1.html#nvidia-nsight-tegra
--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual Studio Cross Compile

[Michael Jäntsch]

Hi again, 

Is there nobody who can help me? I thought it would be a common thing to use 
cmake to cross compile!? Has nobody ever used visual studio to do so? 

Cheers
Michael 


Am 29. Oktober 2015 15:21:41 MEZ, schrieb Michael Jaentsch 
:
>Hi all,
>
>I have a question concerning Cross Compiling with CMake on Windows. I 
>would like to use Visual Studio but this is not a must. What I do is, I
>
>setup a project for Cross Compiling on Linux and it works fine. Now I 
>want to transfer to Windows, so I set up a toolchain file which sets
>the 
>following variables:
>CMAKE_SYSTEM_NAME
>CMAKE_SYSTEM_PROCESSOR
>CMAKE_FIND_ROOT_PATH
>CMAKE_C_COMPILER
>CMAKE_CXX_COMPILER
>
>and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) 
>on Windows and tell it to generate a project for Visual Studio 10 and
>to 
>use the toolchain file. However, the output shows that it is trying to 
>use the Visual Studio compiler and then subsequently the build fails 
>because of some unkown compiler flags.
>
>So my question is: Is it even possible to do what I'm trying to do? Can
>
>I cross compile with Visual Studio or do I have to use a different 
>generator? All I found in the documentation is that it is possible to 
>cross compile with a toolchain file...
>
>Cheers
>Michael
>
>
>-- 
>Technische Universität München
>Michael Jäntsch
>Fakultät für Informatik
>Robotics and Embedded Systems
>Parkring 13
>85748 Garching bei München
>michael.jaent...@in.tum.de
>www6.in.tum.de
>-- 
>
>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:
>http://public.kitware.com/mailman/listinfo/cmake

--
Sent from my mobile-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Greediness of kwsys regex

[Gregor Jasny via CMake]

Hello,

Today I stumbled across funny behavior of string(REGEX REPLACE:

This one would lead to an empty match:

string(REGEX REPLACE "(.*)" "\\1Proxy.cpp" _out "IConnectionCallback")


This one would match whole "IConnectionCallback"

string(REGEX REPLACE "(.+)" "\\1Proxy.cpp" _out "IConnectionCallback")


Principle of least surprise makes me expect that both variants (* vs. +) 
either contain the full string or the minimal set: empty for *, first 
character for +.


Could someone please explain what's going on here?

Thanks,
Gregor
--

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] getting the rpath right on osx

[Boudewijn Rempt]

I checked the manual and the blog post about rpath on osx, but I'm still
confused, and still not getting it right...

I build and installed Qt 5.6 alpha like this:

./configure -prefix /Users/boudewijnrempt/kf5/i

Then I made a small test project, consisting of nothing but a main that links 
to QtCore.

If I build that with qmake, with this .pro file:

QT   += core
QT   -= gui
TARGET = rpathqmake
CONFIG   += console
CONFIG   -= app_bundle
TEMPLATE = app
SOURCES += main.cpp

The r-path is set:

Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
rpathqmake:
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
current version 5.6.0)

/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility 
version 1.0.0, current version 275.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1213.0.0)

Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath
rpathqmake:
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
current version 5.6.0

If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and 
without all those RPATH related lines,
they don't seem to make a difference. I'm using cmake 3.3.2.

cmake_minimum_required(VERSION 2.8.12)
cmake_policy(SET CMP0042 NEW)
set(CMAKE_MACOSX_RPATH ON)
SET(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(REQUIRED_QT_VERSION 5.3.0)
find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
add_executable(rpathcmake main.cpp)
target_link_libraries(rpathcmake Qt5::Core)
install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)

Only adding something like this makes it work:

set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH 
"/Users/boudewijnrempt/kf5/i/lib")

Which I'm pretty sure is something I don't want.

Boudewijns-Mac-mini:test boudewijnrempt$ make install
[100%] Built target rpathcmake
Install the project...
-- Install configuration: ""
-- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
Boudewijns-Mac-mini:test boudewijnrempt$ otool -L /Users/boudewijnrempt/kf5/i/bin/rpathcmake 
/Users/boudewijnrempt/kf5/i/bin/rpathcmake:

@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
current version 5.6.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1197.1.1)
Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake 
dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore

  Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
  Reason: image not found
Trace/BPT trap: 5
Boudewijns-Mac-mini:test boudewijnrempt$ otool -L /Users/boudewijnrempt/kf5/i/bin/rpathcmake 
/Users/boudewijnrempt/kf5/i/bin/rpathcmake:

@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
current version 5.6.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1197.1.1)

What should I do?

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
--

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:
http://public.kitware.com/mailman/listinfo/cmake