From nico.schloemer at gmail.com  Wed Oct  1 03:11:20 2014
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Wed, 1 Oct 2014 09:11:20 +0200
Subject: [CMake] CMake 3.0.1 missing CMakeLists.txt error
In-Reply-To: <D04EF1F4.2605A%gahanse@sandia.gov>
References: <D04EF1F4.2605A%gahanse@sandia.gov>
Message-ID: <CAK6Z60eG2ERqntL+eAu8u5ouZKUCPbreh=r4ZRGQ24gbhF5+fQ@mail.gmail.com>

You could manually check for a file by the name of `CMakeLists.txt` to
exist, e.g.,
```
IF (IS_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/subdir/
    AND EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/subdir/CMakeLists.txt)
  ADD_SUBDIRECTORY(subdir)
ENDIF()
```

Cheers,
Nico

On Mon, Sep 29, 2014 at 7:24 PM, Hansen, Glen A <gahanse at sandia.gov> wrote:
>
> Dear List:
>
> I recently upgraded to CMake 3.0.1, and I am now getting the error:
>
> <snip>
>
> CMake Error at packages/stratimikos/CMakeLists.txt:15 (ADD_SUBDIRECTORY):
>   The source directory
>
>     /lore/ghansen/nightly/repos/publicTrilinos/packages/stratimikos/doc
>
>   does not contain a CMakeLists.txt file.
>
> <snip>
>
> This used to be a warning in earlier versions of CMake. Does anyone know of
> a way to turn it back to a warning instead of an error?
>
> Thanks,
>
> Glen Hansen
>
> --
>
> 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

From k0n3ru at gmail.com  Wed Oct  1 04:09:59 2014
From: k0n3ru at gmail.com (Dattu koneru)
Date: Wed, 1 Oct 2014 13:39:59 +0530
Subject: [CMake] Fwd: How to get the list of files that will be installed
 when installing a CMake component
In-Reply-To: <CABW78_R3e7xcDpOTNCRqFQ0r+rCwXyd1-U94QuYpEatt0TBVqw@mail.gmail.com>
References: <CABW78_R3e7xcDpOTNCRqFQ0r+rCwXyd1-U94QuYpEatt0TBVqw@mail.gmail.com>
Message-ID: <CABW78_SD6gbRiADe8t7ceZoJNFrVS3rbDztXzHHy6=sO45iyJg@mail.gmail.com>

Hi ,

Is there any way to know programmatically ( in cmake ) what files will be
installed if a COMPONENT is installed ( something like a get_property of
component)?

Currently I am installing a COMPONENT to a temporary location for packaging
( not using CPack for packaging ) and then packaging using custom commands.
Invoking the following command during packaing in Cmake.

cmake -DCOMPONENT=my_test_component
-DCMAKE_INSTALL_PREFIX=${TMP_PACKAGING_ROOT}
-P ${CMAKE_BINARY_DIR}/cmake_install.cmake

I wanted to know if it is possible to get the list of files so that I can
only include those files explicitly in the package ? or possibly add them
as outputs to the custom command ?


( I tried asking in StackOverflow but no success )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141001/610ea932/attachment.html>

From nilsgladitz at gmail.com  Wed Oct  1 05:13:57 2014
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Wed, 01 Oct 2014 11:13:57 +0200
Subject: [CMake] GNUInstallDir for CMake export files
In-Reply-To: <CAK6Z60dARF7Bbf_EfjXDi-fGfdz3dj15Z8J-ztBL65Tjp6cqEg@mail.gmail.com>
References: <CAK6Z60dARF7Bbf_EfjXDi-fGfdz3dj15Z8J-ztBL65Tjp6cqEg@mail.gmail.com>
Message-ID: <542BC5D5.9080203@gmail.com>

On 01.10.2014 00:26, Nico Schl?mer wrote:
> into which of the directories listed in [1] are the CMake export files
> (*Config.cmake, *Target.cmake,...) supposed to go?

On [2] scroll down to "CMake constructs a set of possible installation 
prefixes for the package.".

Any of the listed (W) or (U) conventions will work.

My Qt5 installation (Ubuntu) for example seems to follow the first of 
the listed unix (U) conventions:
     <prefix>/(lib/<arch>|lib|share)/cmake/<name>*/

Resulting in e.g.:
     /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake

That corresponds to "${CMAKE_INSTALL_LIBDIR}/cmake/Qt5" which for the 
default install prefix (/usr/local) expands to:
     "lib/cmake/Qt5"

For CMAKE_INSTALL_PREFIX "/usr" it expands to:
     "lib/x86_64-linux-gnu/cmake/Qt5"

Nils

[1] http://www.cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html
[2] http://www.cmake.org/cmake/help/v3.0/command/find_package.html


From nico.schloemer at gmail.com  Wed Oct  1 05:31:12 2014
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Wed, 1 Oct 2014 11:31:12 +0200
Subject: [CMake] GNUInstallDir for CMake export files
In-Reply-To: <542BC5D5.9080203@gmail.com>
References: <CAK6Z60dARF7Bbf_EfjXDi-fGfdz3dj15Z8J-ztBL65Tjp6cqEg@mail.gmail.com>
 <542BC5D5.9080203@gmail.com>
Message-ID: <CAK6Z60ey+7reUXYxALEbgWpTu8h2fnrn++LFrEUOGsur8VZaRw@mail.gmail.com>

Alright, thanks!

On Wed, Oct 1, 2014 at 11:13 AM, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> On 01.10.2014 00:26, Nico Schl?mer wrote:
>>
>> into which of the directories listed in [1] are the CMake export files
>> (*Config.cmake, *Target.cmake,...) supposed to go?
>
>
> On [2] scroll down to "CMake constructs a set of possible installation
> prefixes for the package.".
>
> Any of the listed (W) or (U) conventions will work.
>
> My Qt5 installation (Ubuntu) for example seems to follow the first of the
> listed unix (U) conventions:
>     <prefix>/(lib/<arch>|lib|share)/cmake/<name>*/
>
> Resulting in e.g.:
>     /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
>
> That corresponds to "${CMAKE_INSTALL_LIBDIR}/cmake/Qt5" which for the
> default install prefix (/usr/local) expands to:
>     "lib/cmake/Qt5"
>
> For CMAKE_INSTALL_PREFIX "/usr" it expands to:
>     "lib/x86_64-linux-gnu/cmake/Qt5"
>
> Nils
>
> [1] http://www.cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html
> [2] http://www.cmake.org/cmake/help/v3.0/command/find_package.html
>

From fenjuan at bios.au.dk  Wed Oct  1 05:47:16 2014
From: fenjuan at bios.au.dk (Fenjuan Hu)
Date: Wed, 1 Oct 2014 09:47:16 +0000
Subject: [CMake] Cmake 3.0.2 generated projects for  VS2010+ifort12.1,
 encountering problem with VS environment variable $(Configuration)
In-Reply-To: <C37C66A7DE7CA64C932B32E440A2F79F842E849F@SRVUNIMBX08.uni.au.dk>
References: <C37C66A7DE7CA64C932B32E440A2F79F842E841B@SRVUNIMBX08.uni.au.dk>,
 <C37C66A7DE7CA64C932B32E440A2F79F842E849F@SRVUNIMBX08.uni.au.dk>
Message-ID: <C37C66A7DE7CA64C932B32E440A2F79F842E9CB8@SRVUNIMBX08.uni.au.dk>

Hi all
    I am using Cmake3.0.2, and want to generate project for Visual Studio 2010, and I have ifort 12 installed on my computer. After generated the project, when I build them, I got error:

  Error 1  fatal error LNK1181: cannot open input file 'C:\MODELS\build\fabm\0d\models\bb\bb.dir\\filter_feeder.obj' LINK

   Somehow, Visual Studio or Fortran compiler couldn't find the filter_feeder.obj file. While in path above,  between bb.dir and filter_feeder.obj is "\\", and between two slash, it should be "\Debug\" or "\Release\".
  Then I tried to find this object file(filter_feeder.obj), And I can see that its directory is  ('C:\MODELS\build\fabm\0d\models\bb\bb.dir\($Configuration)\filter_feeder.obj).
    So, somehow VS2010 or my fortran compiler can't recognize ($Configuration) when it tried to locate the object file.
    I did some research on Internet, and it was similar problem other people found, see:  https://github.com/TooTallNate/node-gyp/issues/35.
     But no solid solution to this question posted. Most of it is discussion of system information and versions of compilers and Visual Studio, how no solution to solve the problem of different versions.

     Afterwards, I looked up in the  project file (.vfproj), and viewed it with text editor, and in the file wherever the project file try to located the object files, the path was always"  **\**\($Configuration)\***.obj"(** represents any strings of my file directory, where it contains obj. files)

   It is said it's due to the Visual Studio has  changed environment variable ($ConfigurationName) to  ($Configuration)  from VS2008 to VS2010. Then I  replaced all ($Configuration) by ($ConfigurationName) in the vfproj file,  the build worked.

   And by the way, we have several people work on the same project, and two of other people using VS2010 and ifort worked perfectly with this CMake generating system. Their settings on their computer are:


    VS2010, version 10.0.40219.1 SP1Rel
     Intel Visual Fortran Composer XE 2013 Update 1, version 13.0.1.119

And

   VS2010, version 10.0.40219.1 SP1Rel
    Intel Visual Fortran Composer XE 2013 Update 1, version 13.0.1.119

And mine is :


    VS2010, version 10.0.40219.1 SP1Rel
    Intel Visual Fortran Composer XE 2013 Update 1, version 12.1.3534


So the only difference was the versions of ifort compiler. My version is a little old.

So when CMake generated the project files for VS2010 and ifort 12, did we take this problem into consideration?


Best regards

Fen







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141001/79e151e2/attachment.html>

From dschepler at scalable-networks.com  Wed Oct  1 12:08:37 2014
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Wed, 1 Oct 2014 16:08:37 +0000
Subject: [CMake] Fwd: How to get the list of files that will be
 installed when installing a CMake component
In-Reply-To: <CABW78_SD6gbRiADe8t7ceZoJNFrVS3rbDztXzHHy6=sO45iyJg@mail.gmail.com>
References: <CABW78_R3e7xcDpOTNCRqFQ0r+rCwXyd1-U94QuYpEatt0TBVqw@mail.gmail.com>
 <CABW78_SD6gbRiADe8t7ceZoJNFrVS3rbDztXzHHy6=sO45iyJg@mail.gmail.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C94380C4CF7@SNTMAIL01.snt.loc>

What about checking install_manifest.txt after running the cmake command?

Or, if you have multiple components to package in this way, possibly you could use a different CMAKE_INSTALL_PREFIX for each component.  Then, either have the installer generator use those directories for packing the installer components, or use some scripting to combine the component installations into a final image directory for the installer generator to read from.
--
Daniel

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Dattu koneru
Sent: Wednesday, October 01, 2014 1:10 AM
To: cmake at cmake.org
Subject: [CMake] Fwd: How to get the list of files that will be installed when installing a CMake component


Hi ,

Is there any way to know programmatically ( in cmake ) what files will be installed if a COMPONENT is installed ( something like a get_property of component)?

Currently I am installing a COMPONENT to a temporary location for packaging ( not using CPack for packaging ) and then packaging using custom commands. Invoking the following command during packaing in Cmake.

cmake -DCOMPONENT=my_test_component

-DCMAKE_INSTALL_PREFIX=${TMP_PACKAGING_ROOT}

-P ${CMAKE_BINARY_DIR}/cmake_install.cmake

I wanted to know if it is possible to get the list of files so that I can only include those files explicitly in the package ? or possibly add them as outputs to the custom command ?



( I tried asking in StackOverflow but no success )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141001/615f1c28/attachment-0001.html>

From gerhard.olsson at volvo.com  Wed Oct  1 13:45:55 2014
From: gerhard.olsson at volvo.com (Olsson Gerhard)
Date: Wed, 1 Oct 2014 17:45:55 +0000
Subject: [CMake] Ninja: CMD /C, quoting added for PRE_LINK/POST_BUILD
Message-ID: <289541F89243ED47BC4BAE6C83560E9E471AD753@SEGOTNC5181-N1.vcn.ds.volvo.net>

The commands for PRE_LINK/POST_BUILD is not correctly quoted for Ninja in Windows. 'CMD /C "<command>"' is added to the command, just as Ninja itself does.
(this was maybe different in earlier Ninja versions, but has been around for a couple of years)
(The quoting in the working command is strange, but works.)

A workaround that is not so bad, is to patch build.ninja
Is there a better way?

Note: The lines  LINK_FLAGS ,POST_BUILD ,  PRE_LINK , TARGET_PDB are duplicated in build.ninja. Does not make a difference.

ARM DS-5 compiler (armcc compiler 5.04)
Platform: Windows (Linux used too, but with Unix Makefiles)
CMake 3.0.2
Ninja 1.5.1

/Gerhard


CmakeLists.txt excerpt:

ADD_CUSTOM_COMMAND(
    TARGET ECU
    PRE_LINK
    COMMAND "C:/Program Files/DS-5/bin/armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o ${CMAKE_CURRENT_BINARY_DIR}/osekasm.o c:/Os/osekasm.s VERBATIM
  )

  #Generate hex, copy to view
  add_custom_command(TARGET ECU POST_BUILD
    COMMAND "C:/Program Files/DS-5/bin/fromelf.exe" --m32combined --output=${CMAKE_CURRENT_BINARY_DIR}/ECU.hex ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf VERBATIM
    COMMAND "C:/cygwin/bin/objcopy" -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf ${CMAKE_CURRENT_BINARY_DIR}/parameter_section.hex VERBATIM
  )


Generated in build.ninja:

  LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o
  POST_BUILD = cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex"
  PRE_LINK = cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build"
  TARGET_PDB = ECU.elf.dbg


Console output:

[106/107] Linking C executable ECU.elf
FAILED: cmd.exe /C "cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build" && C:\PROGRA~1\DS-5\bin\armcc.exe    --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o --via=CMakeFiles/ECU.rsp  -o ECU.elf  && cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex""
'cmd.exe' is not recognized as an internal or external command,
operable program or batch file.
ninja: build stopped: subcommand failed.


Patched (in Makefile):

${CMAKE_MAKEFILE}: ${CMAKELISTS} ${CMAKE_TOOLCHAIN} | ${CMAKE_BUILD_DIR}
                             @#CMake Ninja uses cmd incorrectly
                             @perl -pi -e 's%^(\s*(POST_BUILD|PRE_LINK)\s*=\s*)cmd.exe\s(/C)?\s*"(.*)"%$$1$$4%i; ' $@



Rules patched OK:

  LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o
  POST_BUILD = cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex
  PRE_LINK = cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build
  TARGET_PDB = ECU.elf.dbg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141001/685987f9/attachment.html>

From olivier.pierard at cenaero.be  Thu Oct  2 04:26:21 2014
From: olivier.pierard at cenaero.be (Olivier Pierard)
Date: Thu, 02 Oct 2014 10:26:21 +0200
Subject: [CMake] ExternalProject - Guarantee use of same third party library
Message-ID: <542D0C2D.4060008@cenaero.be>

Dear all,

I'm trying to set up an ExternalProject.  Typically, the main project as 
well as the ExternalProject are depending/using a same third party 
library (e.g.: boost) and I would like to guarantee that the same 
version of it of used on both sides.

What's the best solution:
* Use two find_package (one in each project) using the same BOOST_ROOT 
(how to guarantee this ?)
* Retrieve the BOOST_INCLUDE_DIR/BOOST_LIBRARIES from the cache of the 
externalproject (how to do it ? Is this already known at configure step 
of main project ? )
* Something else...

Thank you for your help,

Olivier



From awl03 at doc.ic.ac.uk  Thu Oct  2 08:11:55 2014
From: awl03 at doc.ic.ac.uk (Alexander Lamaison)
Date: Thu, 02 Oct 2014 13:11:55 +0100
Subject: [CMake] Usage requirements for external project dependencies
References: <86fvg3lqs0.fsf@doc.ic.ac.uk>
 <49c32c9d-6d94-41e7-85ae-5d96265fb960@email.android.com>
Message-ID: <86d2aa7jsk.fsf@doc.ic.ac.uk>

Hendrik Sattler <post at hendrik-sattler.de>
writes:

> On 7. September 2014 11:32:31 MESZ, Alexander Lamaison
> <awl03 at doc.ic.ac.uk> wrote:
>>What I would like is to be able to do is:
>>
>>add_executable(my_exe ${SOURCES})
>>find_package(Foo)
>>target_link_libraries(my_exe Foo)
>>
>>and have it Just Work.  Is that possible?
>
> Yes, you just have to create an IMPORTED library target and manually
> set the INTERFACE_* properties for it. If you name the target with ::
> in it, then CMake knows that it's a target and not a library file base
> name.

That worked really well!!  I've had a lot of fun rejigging my projects
to work like this.  Thanks.

Alex

-- 
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)


From Lucas.Pettey at engilitycorp.com  Thu Oct  2 12:38:05 2014
From: Lucas.Pettey at engilitycorp.com (Lucas.Pettey at engilitycorp.com)
Date: Thu, 2 Oct 2014 16:38:05 +0000
Subject: [CMake] FindBLAS not always finding CBLAS
Message-ID: <45BF0169B950CD4A97DC5223BB2B44B30818B474@VACH-MX1.EGL.ENGILITYCORP.COM>

Hello everyone,

I am having a strange issue with CMake version 2.8.11.2 on my Mac running Mavericks.

I have two different projects, both of which use find_package(BLAS REQUIRED).

The project which finds CBLAS and adds the correct -framework Accelerate to the link step has this in the CMakeCache.txt:

//Path to a library.
BLAS_Accelerate_LIBRARY:FILEPATH=/System/Library/Frameworks/Accelerate.framework

//Path to a library.
BLAS_acml_LIBRARY:FILEPATH=BLAS_acml_LIBRARY-NOTFOUND

//Path to a library.
BLAS_cblas_LIBRARY:FILEPATH=/usr/lib/libcblas.dylib

//Path to a library.
BLAS_complib.sgimath_LIBRARY:FILEPATH=BLAS_complib.sgimath_LIBRARY-NOTFOUND

//Path to a library.
BLAS_cxml_LIBRARY:FILEPATH=BLAS_cxml_LIBRARY-NOTFOUND

//Path to a library.
BLAS_dxml_LIBRARY:FILEPATH=BLAS_dxml_LIBRARY-NOTFOUND

//Path to a library.
BLAS_essl_LIBRARY:FILEPATH=BLAS_essl_LIBRARY-NOTFOUND

//Path to a library.
BLAS_f77blas_LIBRARY:FILEPATH=BLAS_f77blas_LIBRARY-NOTFOUND

//Path to a library.
BLAS_scsl_LIBRARY:FILEPATH=BLAS_scsl_LIBRARY-NOTFOUND

//Path to a library.
BLAS_sgemm_LIBRARY:FILEPATH=BLAS_sgemm_LIBRARY-NOTFOUND

//Path to a library.
BLAS_sunperf_LIBRARY:FILEPATH=BLAS_sunperf_LIBRARY-NOTFOUND

The non working project that does not find CBLAS or add -framework Accelerate has this in the CMakeCache.txt:

//Path to a library.
BLAS_Accelerate_LIBRARY:FILEPATH=/System/Library/Frameworks/Accelerate.framework

//Path to a library.
BLAS_acml_LIBRARY:FILEPATH=BLAS_acml_LIBRARY-NOTFOUND

//Path to a library.
BLAS_acml_mp_LIBRARY:FILEPATH=BLAS_acml_mp_LIBRARY-NOTFOUND

//Path to a library.
BLAS_complib.sgimath_LIBRARY:FILEPATH=BLAS_complib.sgimath_LIBRARY-NOTFOUND

//Path to a library.
BLAS_cxml_LIBRARY:FILEPATH=BLAS_cxml_LIBRARY-NOTFOUND

//Path to a library.
BLAS_dxml_LIBRARY:FILEPATH=BLAS_dxml_LIBRARY-NOTFOUND

//Path to a library.
BLAS_essl_LIBRARY:FILEPATH=BLAS_essl_LIBRARY-NOTFOUND

//Path to a library.
BLAS_f77blas_LIBRARY:FILEPATH=BLAS_f77blas_LIBRARY-NOTFOUND

//Path to a library.
BLAS_goto2_LIBRARY:FILEPATH=BLAS_goto2_LIBRARY-NOTFOUND

//Path to a library.
BLAS_scsl_LIBRARY:FILEPATH=BLAS_scsl_LIBRARY-NOTFOUND

//Path to a library.
BLAS_sgemm_LIBRARY:FILEPATH=BLAS_sgemm_LIBRARY-NOTFOUND

//Path to a library.
BLAS_sunperf_LIBRARY:FILEPATH=BLAS_sunperf_LIBRARY-NOTFOUND


Any help is appreciated.

Thanks,

Lucas Pettey, PhD
HPCMP PETTT EQM CTA Lead
ERDC-DSRC OnSite
Vicksburg, MS
512-297-9833 Mobile (preferred)
601-634-2980 Office
lucas.pettey at engilitycorp.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141002/3f7845a4/attachment-0001.html>

From rcarter at esturion.net  Thu Oct  2 13:54:04 2014
From: rcarter at esturion.net (Russell L. Carter)
Date: Thu, 02 Oct 2014 10:54:04 -0700
Subject: [CMake] ninja generator and add_custom_target bug
Message-ID: <542D913C.6050607@acipenser.esturion.net>

Hi,

With this cmake code:

ADD_CUSTOM_TARGET(uninstall
  COMMAND echo "\nRemoving installed files:"
  COMMAND cat ${CMAKE_CURRENT_BINARY_DIR}/install_manifest.txt | xargs
rm -fv
  )

(sorry about the wrapping...)

the ninja generator fails with:

ninja: error: build.ninja:90: expected '=', got lexing error

which turns out to be (again, the wrapping makes this hard
to see):

build CMakeFiles/uninstall: CUSTOM_COMMAND
  COMMAND = cd /usr/home/rcarter/projects/nail/core/build/c++.Debug &&
echo
Removing\ installed\ files: && cat
/usr/home/rcarter/projects/nail/core/build/c++.Debug/install_manifest.txt
| xargs rm -fv

The problem seems to be that the echo'd text starting with
"Removing" begins after a newline.

The cmake code works fine with the gmake generator.

Best regards,
Russell

From w.h.greene at gmail.com  Thu Oct  2 15:38:07 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Thu, 2 Oct 2014 15:38:07 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
Message-ID: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>

Hi,

I'm trying to build a trivial project with cmake 3.0 and Visual Studio 2013.
The project has a top-level directory, a sub-directory with the main
program,
and a sub-directory that builds a static library that the main program
depends on.
It all builds fine the first time. Then I change a routine in the library
and rebuild.
The static library gets rebuilt but the main program does not get re-linked.

I have perused the cmake-built VS project for hours and it looks fine to
me; the
main program depends on the library as expected. I can't figure out why the
main
program is not being rebuilt.

More embarrassing, I can easily build a similar VS project by hand that
behaves as
expected but I can' find the significant difference between the two that is
causing the
problematic behavior.

If anyone has any insights on this I would be very appreciative.

Here are my three CMakeLists.txt files:

top level:
-----------
cmake_minimum_required (VERSION 2.8)
project(cmTest)
add_subdirectory (cmTestMain)
add_subdirectory (cmTestLib)

cmTestLib
--------------
FILE(GLOB SRC *.cpp)
FILE(GLOB H_FILES *.h)
add_library (cmTestLib STATIC ${SRC} ${H_FILES})

cmTestMain
----------------
include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
add_executable (cmTestMain cmTestMain.cpp)
target_link_libraries (cmTestMain cmTestLib)

Thanks.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141002/7b52b074/attachment.html>

From awl03 at doc.ic.ac.uk  Thu Oct  2 12:56:12 2014
From: awl03 at doc.ic.ac.uk (Alexander Lamaison)
Date: Thu, 02 Oct 2014 17:56:12 +0100
Subject: [CMake] Dependency paths in CMake package config files
Message-ID: <86tx3m4dhv.fsf@doc.ic.ac.uk>

How do you manage the paths to the libraries that your static library
package depends on in the XXXConfig.cmake that gets installed with
package XXX?

I'm exporting my static library package from both the build tree and
from the installation location like

  add_library(foo STATIC ...)
  target_link_libraries(foo PRIVATE ...)
  install(TARGETS foo EXPORT FooConfig ...)

  ## During package installation, install FooConfig.cmake
  install(EXPORT FooConfig NAMESPACE Foo:: DESTINATION lib)

  ## During build, register directly from build tree
  export(TARGETS foo NAMESPACE Foo:: FILE FooConfig.cmake)
  export(PACKAGE Foo)

This does a great job of generating a FooConfig.cmake that can be used
by other projects on the local machine.  But target foo is linked with
other dependencies, for example, OpenSSH so the installed config file
includes the following:

  set_property(TARGET Foo::foo APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
  set_target_properties(Foo::foo PROPERTIES
    IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
    IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG "C:/OpenSSL-Win64/lib/VC/ssleay32MDd.lib;C:/OpenSSL-Win64/lib/VC/libeay32MDd.lib;ws2_32"
    IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/lib/libfoo.lib")

So my question is, in general, how can I make installabled static
libraries with a package config file?  Or is the trying to redistribute
static libraries a bad idea in the first place?

Thanks,

Alex

--
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)


From mike.jackson at bluequartz.net  Thu Oct  2 17:57:58 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 2 Oct 2014 17:57:58 -0400
Subject: [CMake] Add_Custom_Target to copy a directory not working with
	Ninja on Windows
Message-ID: <CAEqXkzcebRhkDxQg=9mpOnQsVeWz5gRSKJy0vY=zi1eZODPxGg@mail.gmail.com>

Setup: Visual Studio 2013 Express, Ninja Version 1.5.1.git, Windows 7x64,
CMake 3.0.1

I am trying to build my project and when ninja gets to the point of copying
a directory it fails most of the time. Sometimes (I think on a clean build)
it works. Always fails when I am running the "ninja package'. Here is the
cmake code that I use.

#-------------------------------------------------------------------------------
#- This copies all the Prebuilt Pipeline files into the Build directory so
the help
#- works from the Build Tree
add_custom_target(PrebuiltPipelinesCopy ALL
            COMMAND ${CMAKE_COMMAND} -E copy_directory
${DREAM3D_SUPPORT_DIR}/PrebuiltPipelines

${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}/PrebuiltPipelines/
            COMMENT "Copying Prebuilt Pipelines into Binary Directory")
set_target_properties(PrebuiltPipelinesCopy PROPERTIES FOLDER ZZ_COPY_FILES)

# Make Sure this target as part of the DREAM3D Build
add_dependencies(DREAM3D PrebuiltPipelinesCopy)

#- This installs all the help files. Note that we assume a flat directory
structure
#- in the "Help" folder, ie, all html files, images, etc are all in the
"Help"
#- folder and NOT in any subfolders beyond that.
install(DIRECTORY ${DREAM3D_SUPPORT_DIR}/PrebuiltPipelines
        DESTINATION .
        COMPONENT Applications )

I can not figure out what is going wrong. Visual Studio will sometimes fail
also. Has anyone encountered this before?


Thanks
_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141002/4dc437b6/attachment.html>

From mike.jackson at bluequartz.net  Thu Oct  2 18:39:54 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 2 Oct 2014 18:39:54 -0400
Subject: [CMake] Fwd: Add_Custom_Target to copy a directory not working with
	Ninja on Windows
In-Reply-To: <CAEqXkzcebRhkDxQg=9mpOnQsVeWz5gRSKJy0vY=zi1eZODPxGg@mail.gmail.com>
References: <CAEqXkzcebRhkDxQg=9mpOnQsVeWz5gRSKJy0vY=zi1eZODPxGg@mail.gmail.com>
Message-ID: <CAEqXkzc08WbD3d9U4=MHjgU7yPKdt4ak2GFN0s1A3Zgn6PhrLQ@mail.gmail.com>

Tried a few different ideas:
 First, I pulled the latest Ninja sources and built those. No luck, Still
Failed.
Next, I removed the manually added dependencies of the copy target on the
application being built. Still Failed.
Ran ninja with only a single thread (ninja -j1) AND IT WORKED!

So I'll just assume that there is a threading issue between CMake and Ninja.

I ran the same command from the command line and that worked just fine so
it must be something in how ninja is trying to do the copy. Unfortunately
there does not seem to be any failure log anywhere to get a better idea of
_why_ it is failing.


---------- Forwarded message ----------
From: Michael Jackson <mike.jackson at bluequartz.net>
Date: Thu, Oct 2, 2014 at 5:57 PM
Subject: Add_Custom_Target to copy a directory not working with Ninja on
Windows
To: "cmake at cmake.org" <cmake at cmake.org>


Setup: Visual Studio 2013 Express, Ninja Version 1.5.1.git, Windows 7x64,
CMake 3.0.1

I am trying to build my project and when ninja gets to the point of copying
a directory it fails most of the time. Sometimes (I think on a clean build)
it works. Always fails when I am running the "ninja package'. Here is the
cmake code that I use.

#-------------------------------------------------------------------------------
#- This copies all the Prebuilt Pipeline files into the Build directory so
the help
#- works from the Build Tree
add_custom_target(PrebuiltPipelinesCopy ALL
            COMMAND ${CMAKE_COMMAND} -E copy_directory
${DREAM3D_SUPPORT_DIR}/PrebuiltPipelines

${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}/PrebuiltPipelines/
            COMMENT "Copying Prebuilt Pipelines into Binary Directory")
set_target_properties(PrebuiltPipelinesCopy PROPERTIES FOLDER ZZ_COPY_FILES)

# Make Sure this target as part of the DREAM3D Build
add_dependencies(DREAM3D PrebuiltPipelinesCopy)

#- This installs all the help files. Note that we assume a flat directory
structure
#- in the "Help" folder, ie, all html files, images, etc are all in the
"Help"
#- folder and NOT in any subfolders beyond that.
install(DIRECTORY ${DREAM3D_SUPPORT_DIR}/PrebuiltPipelines
        DESTINATION .
        COMPONENT Applications )

I can not figure out what is going wrong. Visual Studio will sometimes fail
also. Has anyone encountered this before?


Thanks
_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141002/87a6cbdf/attachment.html>

From mike.jackson at bluequartz.net  Thu Oct  2 18:55:42 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 2 Oct 2014 18:55:42 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>
References: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>
Message-ID: <CAEqXkzdtVDJ+upnWe_8cPCmZ5XvAXOqhzTAMaP=At=XHQhT=Jg@mail.gmail.com>

This probably is not completely your issue but I am sure it has something
to do with it. From the help for the "FILE" command:

GLOB will generate a list of all files that match the globbing
expressions and store it into the variable.  Globbing expressions are
similar to regular expressions, but much simpler.  If RELATIVE flag is
specified for an expression, the results will be returned as a
relative path to the given path.  (We do not recommend using GLOB to
collect a list of source files from your source tree.  If no
CMakeLists.txt file changes when a source is added or removed then the
generated build system cannot know when to ask CMake to regenerate.)

Take away: Do NOT use GLOB to find source files. List them out one by one
in the CMake file.

Try that and let us know if it works as you would expect it to.

Mike Jackson

_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio

On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <w.h.greene at gmail.com> wrote:

> Hi,
>
> I'm trying to build a trivial project with cmake 3.0 and Visual Studio
> 2013.
> The project has a top-level directory, a sub-directory with the main
> program,
> and a sub-directory that builds a static library that the main program
> depends on.
> It all builds fine the first time. Then I change a routine in the library
> and rebuild.
> The static library gets rebuilt but the main program does not get
> re-linked.
>
> I have perused the cmake-built VS project for hours and it looks fine to
> me; the
> main program depends on the library as expected. I can't figure out why
> the main
> program is not being rebuilt.
>
> More embarrassing, I can easily build a similar VS project by hand that
> behaves as
> expected but I can' find the significant difference between the two that
> is causing the
> problematic behavior.
>
> If anyone has any insights on this I would be very appreciative.
>
> Here are my three CMakeLists.txt files:
>
> top level:
> -----------
> cmake_minimum_required (VERSION 2.8)
> project(cmTest)
> add_subdirectory (cmTestMain)
> add_subdirectory (cmTestLib)
>
> cmTestLib
> --------------
> FILE(GLOB SRC *.cpp)
> FILE(GLOB H_FILES *.h)
> add_library (cmTestLib STATIC ${SRC} ${H_FILES})
>
> cmTestMain
> ----------------
> include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
> add_executable (cmTestMain cmTestMain.cpp)
> target_link_libraries (cmTestMain cmTestLib)
>
> Thanks.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141002/f754dfd5/attachment-0001.html>

From mike.jackson at bluequartz.net  Thu Oct  2 19:13:31 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Thu, 2 Oct 2014 19:13:31 -0400
Subject: [CMake] Add_Custom_Target to copy a directory not working with
	Ninja on Windows
In-Reply-To: <CAEqXkzc08WbD3d9U4=MHjgU7yPKdt4ak2GFN0s1A3Zgn6PhrLQ@mail.gmail.com>
References: <CAEqXkzcebRhkDxQg=9mpOnQsVeWz5gRSKJy0vY=zi1eZODPxGg@mail.gmail.com>
 <CAEqXkzc08WbD3d9U4=MHjgU7yPKdt4ak2GFN0s1A3Zgn6PhrLQ@mail.gmail.com>
Message-ID: <CAEqXkzciqEGHYjL1AG2BNtf+qEj9cr1O1_1rqoE6vBLNdosuTg@mail.gmail.com>

I dug through the ninja build files and found the exact command into a
command prompt. The first time it worked. The second time it did not. Here
is the output:

C:\Users\admin>cmd.exe /C "cd /D
C:\Users\admin\Workspace\DREAM3D_Rewrite\ninja\
Applications\DREAM3D && C:\DREAM3D_SDK\cmake-3.0.2-win32-x86\bin\cmake.exe
-E copy_directory C:/DREAM3D_SDK/DREAM3D_Data/Data
C:/Users/admin/Workspace/DREAM3D_Rewrite/ninja/Bin/./Data/"
Error copying directory from "C:/DREAM3D_SDK/DREAM3D_Data/Data" to
"C:/Users/adm
in/Workspace/DREAM3D_Rewrite/ninja/Bin/./Data/".

So this is maybe a CMake error?

The failure seems to be intermittent. Hmm. And just to sanity check. there
is plenty of room on the hard drive.

Thoughts?
Mike Jackson


_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio

On Thu, Oct 2, 2014 at 6:39 PM, Michael Jackson <mike.jackson at bluequartz.net
> wrote:

> Tried a few different ideas:
>  First, I pulled the latest Ninja sources and built those. No luck, Still
> Failed.
> Next, I removed the manually added dependencies of the copy target on the
> application being built. Still Failed.
> Ran ninja with only a single thread (ninja -j1) AND IT WORKED!
>
> So I'll just assume that there is a threading issue between CMake and
> Ninja.
>
> I ran the same command from the command line and that worked just fine so
> it must be something in how ninja is trying to do the copy. Unfortunately
> there does not seem to be any failure log anywhere to get a better idea of
> _why_ it is failing.
>
>
> ---------- Forwarded message ----------
> From: Michael Jackson <mike.jackson at bluequartz.net>
> Date: Thu, Oct 2, 2014 at 5:57 PM
> Subject: Add_Custom_Target to copy a directory not working with Ninja on
> Windows
> To: "cmake at cmake.org" <cmake at cmake.org>
>
>
> Setup: Visual Studio 2013 Express, Ninja Version 1.5.1.git, Windows 7x64,
> CMake 3.0.1
>
> I am trying to build my project and when ninja gets to the point of
> copying a directory it fails most of the time. Sometimes (I think on a
> clean build) it works. Always fails when I am running the "ninja package'.
> Here is the cmake code that I use.
>
>
> #-------------------------------------------------------------------------------
> #- This copies all the Prebuilt Pipeline files into the Build directory so
> the help
> #- works from the Build Tree
> add_custom_target(PrebuiltPipelinesCopy ALL
>             COMMAND ${CMAKE_COMMAND} -E copy_directory
> ${DREAM3D_SUPPORT_DIR}/PrebuiltPipelines
>
> ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}/PrebuiltPipelines/
>             COMMENT "Copying Prebuilt Pipelines into Binary Directory")
> set_target_properties(PrebuiltPipelinesCopy PROPERTIES FOLDER
> ZZ_COPY_FILES)
>
> # Make Sure this target as part of the DREAM3D Build
> add_dependencies(DREAM3D PrebuiltPipelinesCopy)
>
> #- This installs all the help files. Note that we assume a flat directory
> structure
> #- in the "Help" folder, ie, all html files, images, etc are all in the
> "Help"
> #- folder and NOT in any subfolders beyond that.
> install(DIRECTORY ${DREAM3D_SUPPORT_DIR}/PrebuiltPipelines
>         DESTINATION .
>         COMPONENT Applications )
>
> I can not figure out what is going wrong. Visual Studio will sometimes
> fail also. Has anyone encountered this before?
>
>
> Thanks
> _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
> BlueQuartz Software                    www.bluequartz.net
> Principal Software Engineer                  Dayton, Ohio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141002/2465e4d3/attachment.html>

From w.h.greene at gmail.com  Thu Oct  2 19:57:43 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Thu, 2 Oct 2014 19:57:43 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CAEqXkzdtVDJ+upnWe_8cPCmZ5XvAXOqhzTAMaP=At=XHQhT=Jg@mail.gmail.com>
References: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>
 <CAEqXkzdtVDJ+upnWe_8cPCmZ5XvAXOqhzTAMaP=At=XHQhT=Jg@mail.gmail.com>
Message-ID: <CABUrC_b1AfjQp05ttgziKBuo7GkBnwDH-3SU6yNc9ioDFwswEQ@mail.gmail.com>

I replaced the CMakeLists.txt for the library (cmTestLib) with simply this:

add_library (cmTestLib STATIC MySub.cpp MySub.h)

And I see exactly the same problem with the main program not getting
rebuilt.
So I believe the GLOB issue is irrelevant to this particular problem.

Bill

On Thu, Oct 2, 2014 at 6:55 PM, Michael Jackson <mike.jackson at bluequartz.net
> wrote:

> This probably is not completely your issue but I am sure it has something
> to do with it. From the help for the "FILE" command:
>
> GLOB will generate a list of all files that match the globbing
> expressions and store it into the variable.  Globbing expressions are
> similar to regular expressions, but much simpler.  If RELATIVE flag is
> specified for an expression, the results will be returned as a
> relative path to the given path.  (We do not recommend using GLOB to
> collect a list of source files from your source tree.  If no
> CMakeLists.txt file changes when a source is added or removed then the
> generated build system cannot know when to ask CMake to regenerate.)
>
> Take away: Do NOT use GLOB to find source files. List them out one by one
> in the CMake file.
>
> Try that and let us know if it works as you would expect it to.
>
> Mike Jackson
>
> _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
> BlueQuartz Software                    www.bluequartz.net
> Principal Software Engineer                  Dayton, Ohio
>
> On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <w.h.greene at gmail.com> wrote:
>
>> Hi,
>>
>> I'm trying to build a trivial project with cmake 3.0 and Visual Studio
>> 2013.
>> The project has a top-level directory, a sub-directory with the main
>> program,
>> and a sub-directory that builds a static library that the main program
>> depends on.
>> It all builds fine the first time. Then I change a routine in the library
>> and rebuild.
>> The static library gets rebuilt but the main program does not get
>> re-linked.
>>
>> I have perused the cmake-built VS project for hours and it looks fine to
>> me; the
>> main program depends on the library as expected. I can't figure out why
>> the main
>> program is not being rebuilt.
>>
>> More embarrassing, I can easily build a similar VS project by hand that
>> behaves as
>> expected but I can' find the significant difference between the two that
>> is causing the
>> problematic behavior.
>>
>> If anyone has any insights on this I would be very appreciative.
>>
>> Here are my three CMakeLists.txt files:
>>
>> top level:
>> -----------
>> cmake_minimum_required (VERSION 2.8)
>> project(cmTest)
>> add_subdirectory (cmTestMain)
>> add_subdirectory (cmTestLib)
>>
>> cmTestLib
>> --------------
>> FILE(GLOB SRC *.cpp)
>> FILE(GLOB H_FILES *.h)
>> add_library (cmTestLib STATIC ${SRC} ${H_FILES})
>>
>> cmTestMain
>> ----------------
>> include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
>> add_executable (cmTestMain cmTestMain.cpp)
>> target_link_libraries (cmTestMain cmTestLib)
>>
>> Thanks.
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141002/916bef2b/attachment.html>

From jzakrzewski at e2e.ch  Fri Oct  3 03:55:52 2014
From: jzakrzewski at e2e.ch (Jakub Zakrzewski)
Date: Fri, 3 Oct 2014 07:55:52 +0000
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_b1AfjQp05ttgziKBuo7GkBnwDH-3SU6yNc9ioDFwswEQ@mail.gmail.com>
References: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>
 <CAEqXkzdtVDJ+upnWe_8cPCmZ5XvAXOqhzTAMaP=At=XHQhT=Jg@mail.gmail.com>
 <CABUrC_b1AfjQp05ttgziKBuo7GkBnwDH-3SU6yNc9ioDFwswEQ@mail.gmail.com>
Message-ID: <fb458ab60be64f288bafeb123e41af01@DBXPR03MB478.eurprd03.prod.outlook.com>

Hi,

if I'm not mistaken, the build system only tracks source dependencies, so unless the changed code is shared by both library and main, it'll not rebuild the main.

One solution could be:

SET_SOURCE_FILES_PROPERTIES(
    cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
    ${CMAKE_CURRENT_BINARY_DIR}/cmTestLib/libcmTestLib.a
)

As described here: http://www.cmake.org/pipermail/cmake/2010-November/041049.html
(I might have used wrongpaths but you get the idea)


--
Gruesse,
Jakub



From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Greene
Sent: Freitag, 3. Oktober 2014 01:58
To: Michael Jackson
Cc: cmake at cmake.org
Subject: Re: [CMake] Main program not getting rebuilt when library changes.

I replaced the CMakeLists.txt for the library (cmTestLib) with simply this:

add_library (cmTestLib STATIC MySub.cpp MySub.h)

And I see exactly the same problem with the main program not getting rebuilt.
So I believe the GLOB issue is irrelevant to this particular problem.

Bill

On Thu, Oct 2, 2014 at 6:55 PM, Michael Jackson <mike.jackson at bluequartz.net<mailto:mike.jackson at bluequartz.net>> wrote:
This probably is not completely your issue but I am sure it has something to do with it. From the help for the "FILE" command:

GLOB will generate a list of all files that match the globbing
expressions and store it into the variable.  Globbing expressions are
similar to regular expressions, but much simpler.  If RELATIVE flag is
specified for an expression, the results will be returned as a
relative path to the given path.  (We do not recommend using GLOB to
collect a list of source files from your source tree.  If no
CMakeLists.txt file changes when a source is added or removed then the
generated build system cannot know when to ask CMake to regenerate.)

Take away: Do NOT use GLOB to find source files. List them out one by one in the CMake file.

Try that and let us know if it works as you would expect it to.

Mike Jackson

_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net<mailto:mike.jackson at bluequartz.net>
BlueQuartz Software                    www.bluequartz.net<http://www.bluequartz.net>
Principal Software Engineer                  Dayton, Ohio

On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <w.h.greene at gmail.com<mailto:w.h.greene at gmail.com>> wrote:
Hi,

I'm trying to build a trivial project with cmake 3.0 and Visual Studio 2013.
The project has a top-level directory, a sub-directory with the main program,
and a sub-directory that builds a static library that the main program depends on.
It all builds fine the first time. Then I change a routine in the library and rebuild.
The static library gets rebuilt but the main program does not get re-linked.

I have perused the cmake-built VS project for hours and it looks fine to me; the
main program depends on the library as expected. I can't figure out why the main
program is not being rebuilt.

More embarrassing, I can easily build a similar VS project by hand that behaves as
expected but I can' find the significant difference between the two that is causing the
problematic behavior.

If anyone has any insights on this I would be very appreciative.

Here are my three CMakeLists.txt files:

top level:
-----------
cmake_minimum_required (VERSION 2.8)
project(cmTest)
add_subdirectory (cmTestMain)
add_subdirectory (cmTestLib)

cmTestLib
--------------
FILE(GLOB SRC *.cpp)
FILE(GLOB H_FILES *.h)
add_library (cmTestLib STATIC ${SRC} ${H_FILES})

cmTestMain
----------------
include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
add_executable (cmTestMain cmTestMain.cpp)
target_link_libraries (cmTestMain cmTestLib)

Thanks.

Bill

--

Powered by www.kitware.com<http://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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141003/4d6ed8f2/attachment-0001.html>

From petr.kmoch at gmail.com  Fri Oct  3 05:27:55 2014
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Fri, 3 Oct 2014 11:27:55 +0200
Subject: [CMake] ninja generator and add_custom_target bug
In-Reply-To: <542D913C.6050607@acipenser.esturion.net>
References: <542D913C.6050607@acipenser.esturion.net>
Message-ID: <CAKohaZec6+x-09zaqnp911XtgthNSwx4Pg_WEW9b7cBsJ-Lsqg@mail.gmail.com>

Hi Russell,

you might want to add VERBATIM to the custom target, so that command-line
arguments are escaped properly:

ADD_CUSTOM_TARGET(uninstall
  COMMAND echo "\nRemoving installed files:"
  COMMAND cat ${CMAKE_CURRENT_BINARY_DIR}/install_manifest.txt | xargs rm
-fv
  VERBATIM
)

See the docs:
http://www.cmake.org/cmake/help/v3.0/command/add_custom_target.html

I don't know whether it helps, but it might.

Petr


On Thu, Oct 2, 2014 at 7:54 PM, Russell L. Carter <rcarter at esturion.net>
wrote:

> Hi,
>
> With this cmake code:
>
> ADD_CUSTOM_TARGET(uninstall
>   COMMAND echo "\nRemoving installed files:"
>   COMMAND cat ${CMAKE_CURRENT_BINARY_DIR}/install_manifest.txt | xargs
> rm -fv
>   )
>
> (sorry about the wrapping...)
>
> the ninja generator fails with:
>
> ninja: error: build.ninja:90: expected '=', got lexing error
>
> which turns out to be (again, the wrapping makes this hard
> to see):
>
> build CMakeFiles/uninstall: CUSTOM_COMMAND
>   COMMAND = cd /usr/home/rcarter/projects/nail/core/build/c++.Debug &&
> echo
> Removing\ installed\ files: && cat
> /usr/home/rcarter/projects/nail/core/build/c++.Debug/install_manifest.txt
> | xargs rm -fv
>
> The problem seems to be that the echo'd text starting with
> "Removing" begins after a newline.
>
> The cmake code works fine with the gmake generator.
>
> Best regards,
> Russell
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141003/29b7761d/attachment.html>

From DLRdave at aol.com  Fri Oct  3 05:54:54 2014
From: DLRdave at aol.com (David Cole)
Date: Fri, 3 Oct 2014 05:54:54 -0400
Subject: [CMake] ninja generator and add_custom_target bug
In-Reply-To: <CAKohaZec6+x-09zaqnp911XtgthNSwx4Pg_WEW9b7cBsJ-Lsqg@mail.gmail.com>
References: <542D913C.6050607@acipenser.esturion.net>
 <CAKohaZec6+x-09zaqnp911XtgthNSwx4Pg_WEW9b7cBsJ-Lsqg@mail.gmail.com>
Message-ID: <CAKME8fHTb8qkwLo6sguf2cDoMM-JkK_jJTxSV8joEg_7bhCP=A@mail.gmail.com>

Or, if echo is the thing that's supposed to see the "\n", escape the
backslash and use "\\n" in CMake so CMake puts the literal "\n" in the
generated file instead of a newline.

HTH,
D

On Fri, Oct 3, 2014 at 5:27 AM, Petr Kmoch <petr.kmoch at gmail.com> wrote:
> Hi Russell,
>
> you might want to add VERBATIM to the custom target, so that command-line
> arguments are escaped properly:
>
> ADD_CUSTOM_TARGET(uninstall
>   COMMAND echo "\nRemoving installed files:"
>   COMMAND cat ${CMAKE_CURRENT_BINARY_DIR}/install_manifest.txt | xargs rm
> -fv
>   VERBATIM
> )
>
> See the docs:
> http://www.cmake.org/cmake/help/v3.0/command/add_custom_target.html
>
> I don't know whether it helps, but it might.
>
> Petr
>
>
> On Thu, Oct 2, 2014 at 7:54 PM, Russell L. Carter <rcarter at esturion.net>
> wrote:
>>
>> Hi,
>>
>> With this cmake code:
>>
>> ADD_CUSTOM_TARGET(uninstall
>>   COMMAND echo "\nRemoving installed files:"
>>   COMMAND cat ${CMAKE_CURRENT_BINARY_DIR}/install_manifest.txt | xargs
>> rm -fv
>>   )
>>
>> (sorry about the wrapping...)
>>
>> the ninja generator fails with:
>>
>> ninja: error: build.ninja:90: expected '=', got lexing error
>>
>> which turns out to be (again, the wrapping makes this hard
>> to see):
>>
>> build CMakeFiles/uninstall: CUSTOM_COMMAND
>>   COMMAND = cd /usr/home/rcarter/projects/nail/core/build/c++.Debug &&
>> echo
>> Removing\ installed\ files: && cat
>> /usr/home/rcarter/projects/nail/core/build/c++.Debug/install_manifest.txt
>> | xargs rm -fv
>>
>> The problem seems to be that the echo'd text starting with
>> "Removing" begins after a newline.
>>
>> The cmake code works fine with the gmake generator.
>>
>> Best regards,
>> Russell
>> --
>>
>> 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

From DLRdave at aol.com  Fri Oct  3 06:09:38 2014
From: DLRdave at aol.com (David Cole)
Date: Fri, 3 Oct 2014 06:09:38 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <fb458ab60be64f288bafeb123e41af01@DBXPR03MB478.eurprd03.prod.outlook.com>
References: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>
 <CAEqXkzdtVDJ+upnWe_8cPCmZ5XvAXOqhzTAMaP=At=XHQhT=Jg@mail.gmail.com>
 <CABUrC_b1AfjQp05ttgziKBuo7GkBnwDH-3SU6yNc9ioDFwswEQ@mail.gmail.com>
 <fb458ab60be64f288bafeb123e41af01@DBXPR03MB478.eurprd03.prod.outlook.com>
Message-ID: <CAKME8fEipZxZ_xFstVRBB5+dHDs4Ru4oDcVNMGVtnD5nogCagg@mail.gmail.com>

Switch the order of your add_subdirectory calls.

If your main depends on your library, then your add_subdirectory for
the library should be first, and then the one for your main which
depends on the first one.

HTH,
David C.


On Fri, Oct 3, 2014 at 3:55 AM, Jakub Zakrzewski <jzakrzewski at e2e.ch> wrote:
> Hi,
>
>
>
> if I'm not mistaken, the build system only tracks source dependencies, so
> unless the changed code is shared by both library and main, it'll not
> rebuild the main.
>
>
>
> One solution could be:
>
>
>
> SET_SOURCE_FILES_PROPERTIES(
>
>     cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
>
>     ${CMAKE_CURRENT_BINARY_DIR}/cmTestLib/libcmTestLib.a
>
> )
>
>
>
> As described here:
> http://www.cmake.org/pipermail/cmake/2010-November/041049.html
>
> (I might have used wrongpaths but you get the idea)
>
>
>
>
>
> --
>
> Gruesse,
>
> Jakub
>
>
>
>
>
>
>
> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Greene
> Sent: Freitag, 3. Oktober 2014 01:58
> To: Michael Jackson
> Cc: cmake at cmake.org
> Subject: Re: [CMake] Main program not getting rebuilt when library changes.
>
>
>
> I replaced the CMakeLists.txt for the library (cmTestLib) with simply this:
>
>
>
> add_library (cmTestLib STATIC MySub.cpp MySub.h)
>
>
>
> And I see exactly the same problem with the main program not getting
> rebuilt.
>
> So I believe the GLOB issue is irrelevant to this particular problem.
>
>
>
> Bill
>
>
>
> On Thu, Oct 2, 2014 at 6:55 PM, Michael Jackson
> <mike.jackson at bluequartz.net> wrote:
>
> This probably is not completely your issue but I am sure it has something to
> do with it. From the help for the "FILE" command:
>
>
>
> GLOB will generate a list of all files that match the globbing
>
> expressions and store it into the variable.  Globbing expressions are
>
> similar to regular expressions, but much simpler.  If RELATIVE flag is
>
> specified for an expression, the results will be returned as a
>
> relative path to the given path.  (We do not recommend using GLOB to
>
> collect a list of source files from your source tree.  If no
>
> CMakeLists.txt file changes when a source is added or removed then the
>
> generated build system cannot know when to ask CMake to regenerate.)
>
>
>
> Take away: Do NOT use GLOB to find source files. List them out one by one in
> the CMake file.
>
>
>
> Try that and let us know if it works as you would expect it to.
>
>
>
> Mike Jackson
>
>
> _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
> BlueQuartz Software                    www.bluequartz.net
> Principal Software Engineer                  Dayton, Ohio
>
>
>
> On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <w.h.greene at gmail.com> wrote:
>
> Hi,
>
>
>
> I'm trying to build a trivial project with cmake 3.0 and Visual Studio 2013.
>
> The project has a top-level directory, a sub-directory with the main
> program,
>
> and a sub-directory that builds a static library that the main program
> depends on.
>
> It all builds fine the first time. Then I change a routine in the library
> and rebuild.
>
> The static library gets rebuilt but the main program does not get re-linked.
>
>
>
> I have perused the cmake-built VS project for hours and it looks fine to me;
> the
>
> main program depends on the library as expected. I can't figure out why the
> main
>
> program is not being rebuilt.
>
>
>
> More embarrassing, I can easily build a similar VS project by hand that
> behaves as
>
> expected but I can' find the significant difference between the two that is
> causing the
>
> problematic behavior.
>
>
>
> If anyone has any insights on this I would be very appreciative.
>
>
>
> Here are my three CMakeLists.txt files:
>
>
>
> top level:
>
> -----------
>
> cmake_minimum_required (VERSION 2.8)
>
> project(cmTest)
>
> add_subdirectory (cmTestMain)
>
> add_subdirectory (cmTestLib)
>
>
>
> cmTestLib
>
> --------------
>
> FILE(GLOB SRC *.cpp)
>
> FILE(GLOB H_FILES *.h)
>
> add_library (cmTestLib STATIC ${SRC} ${H_FILES})
>
>
>
> cmTestMain
>
> ----------------
>
> include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
>
> add_executable (cmTestMain cmTestMain.cpp)
>
> target_link_libraries (cmTestMain cmTestLib)
>
>
>
> Thanks.
>
>
>
> 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
>
>
>
>
>
>
> --
>
> 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

From awl03 at doc.ic.ac.uk  Fri Oct  3 06:22:57 2014
From: awl03 at doc.ic.ac.uk (Alexander Lamaison)
Date: Fri, 03 Oct 2014 11:22:57 +0100
Subject: [CMake] Install path for package files
References: <CAC9OkhHAe5VvU1dEviASN7ZPr_H4Q+p66frqFojV=vv0vyaRWQ@mail.gmail.com>
Message-ID: <86oatte9ku.fsf@doc.ic.ac.uk>

Noah Roberts <roberts.noah at gmail.com>
writes:

snip

> I gather I need to create a BlahModule.cmake file that implements the
> package finding stuff.  I want to install this wherever cmake will find
> it.  I don't want to put it in some place in the system and then expect
> dependent CMakeLists.txt files to set that path when using
> find_package.

snip

> So what is the variable I use in the install() function for the DESTINATION
> parameter to do this?  I assume there must be one...  I can't seem to find
> it in the documentation though.

Me neither.  This answer [1] lists the places that CMake looks for the
BlahConfig.cmake file so on Unix it's fairly simple.  Set the
DESTINATION to 'lib' which will install it to
/usr/local/lib/BlahConfig.cmake where, presumable, find_package will
locate it.  I don't understand how this is meant to work on Windows,
though.  How is CMake meant to know which root to start thee search
under?

[1] http://stackoverflow.com/a/11965673/67013

Alex

-- 
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)


From w.h.greene at gmail.com  Fri Oct  3 09:07:32 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Fri, 3 Oct 2014 09:07:32 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <fb458ab60be64f288bafeb123e41af01@DBXPR03MB478.eurprd03.prod.outlook.com>
References: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>
 <CAEqXkzdtVDJ+upnWe_8cPCmZ5XvAXOqhzTAMaP=At=XHQhT=Jg@mail.gmail.com>
 <CABUrC_b1AfjQp05ttgziKBuo7GkBnwDH-3SU6yNc9ioDFwswEQ@mail.gmail.com>
 <fb458ab60be64f288bafeb123e41af01@DBXPR03MB478.eurprd03.prod.outlook.com>
Message-ID: <CABUrC_YvjQWLcyO1XH+k7F=Ui0oy27PUQsokWaUtx6T9FLot+Q@mail.gmail.com>

Thanks for the link and the suggestions. I read through the posting several
times to try to understand the
issues.

I added these lines:

SET_SOURCE_FILES_PROPERTIES(
    cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
    ${CMAKE_BINARY_DIR}/cmTestLib/Debug/cmTestLib.lib
)

to the CMakeLists.txt for the main program. (I checked to make sure the
path to the library
is correct). Unfortunately, this didn't fix the build problem.

As I mentioned in my original post, it looks to me like the VS solution
generate by cmake *should*
be doing the right thing but there is some VS subtlety that is coming into
play here ;-(


On Fri, Oct 3, 2014 at 3:55 AM, Jakub Zakrzewski <jzakrzewski at e2e.ch> wrote:

>  Hi,
>
>
>
> if I'm not mistaken, the build system only tracks source dependencies, so
> unless the changed code is shared by both library and main, it'll not
> rebuild the main.
>
>
>
> One solution could be:
>
>
>
> SET_SOURCE_FILES_PROPERTIES(
>
>     cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
>
>     ${CMAKE_CURRENT_BINARY_DIR}/cmTestLib/libcmTestLib.a
>
> )
>
>
>
> As described here:
> http://www.cmake.org/pipermail/cmake/2010-November/041049.html
>
> (I might have used wrongpaths but you get the idea)
>
>
>
>
>
> --
>
> Gruesse,
>
> Jakub
>
>
>
>
>
>
>
> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Bill Greene
> *Sent:* Freitag, 3. Oktober 2014 01:58
> *To:* Michael Jackson
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Main program not getting rebuilt when library
> changes.
>
>
>
> I replaced the CMakeLists.txt for the library (cmTestLib) with simply this:
>
>
>
> add_library (cmTestLib STATIC MySub.cpp MySub.h)
>
>
>
> And I see exactly the same problem with the main program not getting
> rebuilt.
>
> So I believe the GLOB issue is irrelevant to this particular problem.
>
>
>
> Bill
>
>
>
> On Thu, Oct 2, 2014 at 6:55 PM, Michael Jackson <
> mike.jackson at bluequartz.net> wrote:
>
> This probably is not completely your issue but I am sure it has something
> to do with it. From the help for the "FILE" command:
>
>
>
> GLOB will generate a list of all files that match the globbing
>
> expressions and store it into the variable.  Globbing expressions are
>
> similar to regular expressions, but much simpler.  If RELATIVE flag is
>
> specified for an expression, the results will be returned as a
>
> relative path to the given path.  (We do not recommend using GLOB to
>
> collect a list of source files from your source tree.  If no
>
> CMakeLists.txt file changes when a source is added or removed then the
>
> generated build system cannot know when to ask CMake to regenerate.)
>
>
>
> Take away: Do NOT use GLOB to find source files. List them out one by one
> in the CMake file.
>
>
>
> Try that and let us know if it works as you would expect it to.
>
>
>
> Mike Jackson
>
>
>  _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
> BlueQuartz Software                    www.bluequartz.net
> Principal Software Engineer                  Dayton, Ohio
>
>
>
> On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <w.h.greene at gmail.com> wrote:
>
>   Hi,
>
>
>
> I'm trying to build a trivial project with cmake 3.0 and Visual Studio
> 2013.
>
> The project has a top-level directory, a sub-directory with the main
> program,
>
> and a sub-directory that builds a static library that the main program
> depends on.
>
> It all builds fine the first time. Then I change a routine in the library
> and rebuild.
>
> The static library gets rebuilt but the main program does not get
> re-linked.
>
>
>
> I have perused the cmake-built VS project for hours and it looks fine to
> me; the
>
> main program depends on the library as expected. I can't figure out why
> the main
>
> program is not being rebuilt.
>
>
>
> More embarrassing, I can easily build a similar VS project by hand that
> behaves as
>
> expected but I can' find the significant difference between the two that
> is causing the
>
> problematic behavior.
>
>
>
> If anyone has any insights on this I would be very appreciative.
>
>
>
> Here are my three CMakeLists.txt files:
>
>
>
> top level:
>
> -----------
>
> cmake_minimum_required (VERSION 2.8)
>
> project(cmTest)
>
> add_subdirectory (cmTestMain)
>
> add_subdirectory (cmTestLib)
>
>
>
> cmTestLib
>
> --------------
>
> FILE(GLOB SRC *.cpp)
>
> FILE(GLOB H_FILES *.h)
>
> add_library (cmTestLib STATIC ${SRC} ${H_FILES})
>
>
>
> cmTestMain
>
> ----------------
>
> include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
>
> add_executable (cmTestMain cmTestMain.cpp)
>
> target_link_libraries (cmTestMain cmTestLib)
>
>
>
> Thanks.
>
>
>
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141003/0e95fd33/attachment-0001.html>

From biddisco at cscs.ch  Sat Oct  4 03:18:34 2014
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Sat, 4 Oct 2014 07:18:34 +0000
Subject: [CMake] eclipse + debugging
Message-ID: <D0556BE8.69E52%biddisco@cscs.ch>

Using Mac OSX 10.9.5 and Eclipse Luna, I am unable to debug projects generated with cmake.

Although the debugger stops on int main, I can?t get manually set breakpoints to work (they used to work with a previous install ? possibly earlier eclipse). It always reports, ?No source file named ?."

Is there some combination of settings (or structure of source/build dirs) that is required to get the breakpoints working. I?ve tried every combination of source paths in the debugger settings, but to no avail.

Thanks for any clues

JB

From w.h.greene at gmail.com  Sat Oct  4 11:34:11 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Sat, 4 Oct 2014 11:34:11 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_YvjQWLcyO1XH+k7F=Ui0oy27PUQsokWaUtx6T9FLot+Q@mail.gmail.com>
References: <CABUrC_bjVQaVWYuDGh8rcGQOBCe_diYEOZmRVBopdA3vzo0eXQ@mail.gmail.com>
 <CAEqXkzdtVDJ+upnWe_8cPCmZ5XvAXOqhzTAMaP=At=XHQhT=Jg@mail.gmail.com>
 <CABUrC_b1AfjQp05ttgziKBuo7GkBnwDH-3SU6yNc9ioDFwswEQ@mail.gmail.com>
 <fb458ab60be64f288bafeb123e41af01@DBXPR03MB478.eurprd03.prod.outlook.com>
 <CABUrC_YvjQWLcyO1XH+k7F=Ui0oy27PUQsokWaUtx6T9FLot+Q@mail.gmail.com>
Message-ID: <CABUrC_b4LBGWa90X4-kFsnJxVUpsPDBYJPhW_qn2nnUCgavhcQ@mail.gmail.com>

I believe I may have stumbled on a work-around for this problem.

I simply added these two lines to the top-level CMakeLists.txt:

SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR})
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR})

They obviously tell cmake to generate a VS solution that puts the
exe files and libs in the same directory. This is what happens when
you manually create a solution in Visual Studio and (apparently)
changes the way VS deals with dependencies between exe projects and
the lib projects they depend on.

I haven't experimented with more complex projects but, at least, it
fixes this simple case.

Bill

On Fri, Oct 3, 2014 at 9:07 AM, Bill Greene <w.h.greene at gmail.com> wrote:

> Thanks for the link and the suggestions. I read through the posting
> several times to try to understand the
> issues.
>
> I added these lines:
>
> SET_SOURCE_FILES_PROPERTIES(
>     cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
>     ${CMAKE_BINARY_DIR}/cmTestLib/Debug/cmTestLib.lib
> )
>
> to the CMakeLists.txt for the main program. (I checked to make sure the
> path to the library
> is correct). Unfortunately, this didn't fix the build problem.
>
> As I mentioned in my original post, it looks to me like the VS solution
> generate by cmake *should*
> be doing the right thing but there is some VS subtlety that is coming into
> play here ;-(
>
>
> On Fri, Oct 3, 2014 at 3:55 AM, Jakub Zakrzewski <jzakrzewski at e2e.ch>
> wrote:
>
>>  Hi,
>>
>>
>>
>> if I'm not mistaken, the build system only tracks source dependencies, so
>> unless the changed code is shared by both library and main, it'll not
>> rebuild the main.
>>
>>
>>
>> One solution could be:
>>
>>
>>
>> SET_SOURCE_FILES_PROPERTIES(
>>
>>     cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
>>
>>     ${CMAKE_CURRENT_BINARY_DIR}/cmTestLib/libcmTestLib.a
>>
>> )
>>
>>
>>
>> As described here:
>> http://www.cmake.org/pipermail/cmake/2010-November/041049.html
>>
>> (I might have used wrongpaths but you get the idea)
>>
>>
>>
>>
>>
>> --
>>
>> Gruesse,
>>
>> Jakub
>>
>>
>>
>>
>>
>>
>>
>> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Bill Greene
>> *Sent:* Freitag, 3. Oktober 2014 01:58
>> *To:* Michael Jackson
>> *Cc:* cmake at cmake.org
>> *Subject:* Re: [CMake] Main program not getting rebuilt when library
>> changes.
>>
>>
>>
>> I replaced the CMakeLists.txt for the library (cmTestLib) with simply
>> this:
>>
>>
>>
>> add_library (cmTestLib STATIC MySub.cpp MySub.h)
>>
>>
>>
>> And I see exactly the same problem with the main program not getting
>> rebuilt.
>>
>> So I believe the GLOB issue is irrelevant to this particular problem.
>>
>>
>>
>> Bill
>>
>>
>>
>> On Thu, Oct 2, 2014 at 6:55 PM, Michael Jackson <
>> mike.jackson at bluequartz.net> wrote:
>>
>> This probably is not completely your issue but I am sure it has something
>> to do with it. From the help for the "FILE" command:
>>
>>
>>
>> GLOB will generate a list of all files that match the globbing
>>
>> expressions and store it into the variable.  Globbing expressions are
>>
>> similar to regular expressions, but much simpler.  If RELATIVE flag is
>>
>> specified for an expression, the results will be returned as a
>>
>> relative path to the given path.  (We do not recommend using GLOB to
>>
>> collect a list of source files from your source tree.  If no
>>
>> CMakeLists.txt file changes when a source is added or removed then the
>>
>> generated build system cannot know when to ask CMake to regenerate.)
>>
>>
>>
>> Take away: Do NOT use GLOB to find source files. List them out one by one
>> in the CMake file.
>>
>>
>>
>> Try that and let us know if it works as you would expect it to.
>>
>>
>>
>> Mike Jackson
>>
>>
>>  _________________________________________________________
>> Mike Jackson                  mike.jackson at bluequartz.net
>> BlueQuartz Software                    www.bluequartz.net
>> Principal Software Engineer                  Dayton, Ohio
>>
>>
>>
>> On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <w.h.greene at gmail.com> wrote:
>>
>>   Hi,
>>
>>
>>
>> I'm trying to build a trivial project with cmake 3.0 and Visual Studio
>> 2013.
>>
>> The project has a top-level directory, a sub-directory with the main
>> program,
>>
>> and a sub-directory that builds a static library that the main program
>> depends on.
>>
>> It all builds fine the first time. Then I change a routine in the library
>> and rebuild.
>>
>> The static library gets rebuilt but the main program does not get
>> re-linked.
>>
>>
>>
>> I have perused the cmake-built VS project for hours and it looks fine to
>> me; the
>>
>> main program depends on the library as expected. I can't figure out why
>> the main
>>
>> program is not being rebuilt.
>>
>>
>>
>> More embarrassing, I can easily build a similar VS project by hand that
>> behaves as
>>
>> expected but I can' find the significant difference between the two that
>> is causing the
>>
>> problematic behavior.
>>
>>
>>
>> If anyone has any insights on this I would be very appreciative.
>>
>>
>>
>> Here are my three CMakeLists.txt files:
>>
>>
>>
>> top level:
>>
>> -----------
>>
>> cmake_minimum_required (VERSION 2.8)
>>
>> project(cmTest)
>>
>> add_subdirectory (cmTestMain)
>>
>> add_subdirectory (cmTestLib)
>>
>>
>>
>> cmTestLib
>>
>> --------------
>>
>> FILE(GLOB SRC *.cpp)
>>
>> FILE(GLOB H_FILES *.h)
>>
>> add_library (cmTestLib STATIC ${SRC} ${H_FILES})
>>
>>
>>
>> cmTestMain
>>
>> ----------------
>>
>> include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
>>
>> add_executable (cmTestMain cmTestMain.cpp)
>>
>> target_link_libraries (cmTestMain cmTestLib)
>>
>>
>>
>> Thanks.
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141004/d4b4c839/attachment.html>

From rcarter at esturion.net  Sat Oct  4 18:22:48 2014
From: rcarter at esturion.net (Russell L. Carter)
Date: Sat, 04 Oct 2014 15:22:48 -0700
Subject: [CMake] ninja generator and add_custom_target bug
In-Reply-To: <CAKME8fHTb8qkwLo6sguf2cDoMM-JkK_jJTxSV8joEg_7bhCP=A@mail.gmail.com>
References: <542D913C.6050607@acipenser.esturion.net>	<CAKohaZec6+x-09zaqnp911XtgthNSwx4Pg_WEW9b7cBsJ-Lsqg@mail.gmail.com>
 <CAKME8fHTb8qkwLo6sguf2cDoMM-JkK_jJTxSV8joEg_7bhCP=A@mail.gmail.com>
Message-ID: <54307338.3060803@acipenser.esturion.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David and Petr,
A bit of experimenting and indeed it was that "\n" causing the
problem.  Escaping it ("\\n") produces an "n" prefix when building
with make, so after further experiments I decided I could lose the
"\n" entirely.  KISS principle.

Thanks!
Russell

On 10/03/14 02:54, David Cole wrote:
> Or, if echo is the thing that's supposed to see the "\n", escape 
> the backslash and use "\\n" in CMake so CMake puts the literal "\n"
> in the generated file instead of a newline.
> 
> HTH, D
> 
> On Fri, Oct 3, 2014 at 5:27 AM, Petr Kmoch <petr.kmoch at gmail.com> 
> wrote:
>> Hi Russell,
>> 
>> you might want to add VERBATIM to the custom target, so that 
>> command-line arguments are escaped properly:
>> 
>> ADD_CUSTOM_TARGET(uninstall COMMAND echo "\nRemoving installed 
>> files:" COMMAND cat 
>> ${CMAKE_CURRENT_BINARY_DIR}/install_manifest.txt | xargs rm -fv 
>> VERBATIM )
>> 
>> See the docs: 
>> http://www.cmake.org/cmake/help/v3.0/command/add_custom_target.html
>>
>>
>>
>>
>> 
I don't know whether it helps, but it might.
>> 
>> Petr
>> 
>> 
>> On Thu, Oct 2, 2014 at 7:54 PM, Russell L. Carter 
>> <rcarter at esturion.net> wrote:
>>> 
>>> Hi,
>>> 
>>> With this cmake code:
>>> 
>>> ADD_CUSTOM_TARGET(uninstall COMMAND echo "\nRemoving installed
>>>  files:" COMMAND cat 
>>> ${CMAKE_CURRENT_BINARY_DIR}/install_manifest.txt | xargs rm
>>> -fv )
>>> 
>>> (sorry about the wrapping...)
>>> 
>>> the ninja generator fails with:
>>> 
>>> ninja: error: build.ninja:90: expected '=', got lexing error
>>> 
>>> which turns out to be (again, the wrapping makes this hard to 
>>> see):
>>> 
>>> build CMakeFiles/uninstall: CUSTOM_COMMAND COMMAND = cd 
>>> /usr/home/rcarter/projects/nail/core/build/c++.Debug && echo 
>>> Removing\ installed\ files: && cat 
>>> /usr/home/rcarter/projects/nail/core/build/c++.Debug/install_manifest.txt
>>>
>>>
>>>
>>> 
| xargs rm -fv
>>> 
>>> The problem seems to be that the echo'd text starting with 
>>> "Removing" begins after a newline.
>>> 
>>> The cmake code works fine with the gmake generator.
>>> 
>>> Best regards, Russell --
>>> 
>>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUMHM4AAoJEHsx8WYuhXpLp1YP/iEotr4nVogUIMVfrbbwCAk3
nQWWydR7bxuD4vb/ai1JhsrndfXmdYo1Zfjrzns3MXwgalNRvhZR13U47Qohkgo5
QdtaXacMahoW0hEY7p/vcxBQsLK7bcqf1GA4W3JPiuB3aoqV/IOqkzwWhYOG54Ld
bXCCP0Th3qoz7hzDlr7V7jeYHQDA8a4lVumu0Oee8pNOiItggjwOERZU5a+UtqyX
+KKAyEvrw9pi64bXGq76g1S664JlN9BeIKVfqFhsf6J32a5ufgVKSXuHyIa8F9Eu
e/W7xqmtSv6Yq5NyFSrVqoTH9vX4P9JKHHnZ8uwByzbscZAq81jtWkFwPiTDoGaO
ybYeFvSOUMnbRrwRelwphNR7iaNzpYMJ+iRPGJYJjaWhmHUKPnMQWoZxiguecn6S
rlcO9iQCC7jy0f7aB7v027MWl4KeIjJ3A/0DFMWM8FDUMhh1BlEcNcIuK1VD1sND
YR6NbjeleItI6spTyPyMOEXQnnxs19RbwBCchTWhoKCvhmHH2npNrYkE3XSJ+tI4
xmjLdhedIOu2718ILkFb41GsKD1nhIThw8JbjJN0z2zQKKluQ0CsM13w/1E3X4Ur
77E7GlR22QoFNpbq9GWiZp5qYyGMOth4m4JkrTkqE9/zi09cwGs1ndNBIVjik0eU
c5FgWJDYH1oDb4feL/Vt
=/oL8
-----END PGP SIGNATURE-----

From j.e.butler at limitpoint.com  Sat Oct  4 20:12:45 2014
From: j.e.butler at limitpoint.com (Jim Butler)
Date: Sat, 04 Oct 2014 17:12:45 -0700
Subject: [CMake] Main program not getting rebuilt when library changes.
Message-ID: <54308CFD.4010206@limitpoint.com>

Bill Greene<w.h.greene at gmail.com>  wrote:

> add_library (cmTestLib STATIC MySub.cpp MySub.h)
You need not include the header files in an add_library call. They'll be 
found by the compiler, provided you have  included them in the cpp files.

If I understand your problem correctly, I fear you may be trying to use 
a sledgehammer to crack a peanut!

Try this:

         add_library (cmTestLib STATIC MySub.cpp)

         add_executable(cmTestMain cmTestMain.cpp)

         # Make sure the library is up to date
         add_dependencies(cmTestMain cmTestLib)

         # Add lib to the link line
         target_link_libraries(cmTestMain cmTestLib)

Cheers,
Jim

--
Jim Butler
Build Systems Engineer
Limit Point Systems, Inc.
http://cmake.limitpoint.com

From dushistov at gmail.com  Sun Oct  5 02:25:48 2014
From: dushistov at gmail.com (Evgeniy Dushistov)
Date: Sun, 5 Oct 2014 10:25:48 +0400
Subject: [CMake] generator-expressions + pch -> need new magic
Message-ID: <CAKBW4XiiWvNs6o6BUqUS50tqk1KJb2n3pVuyWG4LLsEvQvTN-w@mail.gmail.com>

Hi,
in my project I used such magic code for precompiled headers support
(gcc,clang only):

#take gcc_flags from
                              ${CMAKE_CXX_FLAGS}
${CMAKE_CXX_FLAGS_${_build_type}}
           get_target_property(... COMPILE_FLAGS)
                         get_directory_property(...
INCLUDE_DIRECTORIES)                               foreach(flag
${MY_INCLUDES})
    list(APPEND gcc_flags  "-I" "${pl_flag}")
                     endforeach()

get_directory_property(... COMPILE_DEFINITIONS)
foreach(flag ${MY_DEFS})
                              list(APPEND gcc_flags  "-D${pl_flag}")
                                              endforeach()

           get_directory_property(...
COMPILE_DEFINITIONS_${_build_type})       add_custom_command(...
${gcc_flags} ...)
All works fine, until cmake-3.0 with cmake-generator-expressions.
     With cmake-3.0 COMPILE_DEFINITIONS return something like this:
$<$<NOT:$<CONFIG:Debug>>:QT_NO_DEBUG>

This is empty string on compilation stage, not on not configuration
stage. So "gcc" is called like this: "gcc -D<empty>" and give error.
So question is it possible to evaluate "generator-expressions" within
CMakeLists.txt? Or may be in cmake 3.x there another is way to extract
compilation
flags without such magic as above?

From w.h.greene at gmail.com  Sun Oct  5 09:35:01 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Sun, 5 Oct 2014 09:35:01 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <54308CFD.4010206@limitpoint.com>
References: <54308CFD.4010206@limitpoint.com>
Message-ID: <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>

>You need not include the header files in an add_library call. They'll be
found by the compiler, provided you have  included them in the cpp files.
I want the cmake-generated VS solution to include a "Header Files"
folder in the project containing all .h files. Perhaps there are
other ways of accomplishing this but adding them to add_library() or
add_executable() works well enough.

># Make sure the library is up to date
>add_dependencies(cmTestMain cmTestLib)
I had tried this previously. It does not fix the problem and
appears to have no effect on the generated VS solution.
How did you expect that to change the generated VS project/solution?

>add_library (cmTestLib STATIC MySub.cpp)
That will solve the problem but I don't consider it an
acceptable solution in the general case. As I stated in my
original post, this one-executable, one-lib example is a trivial one
to reproduce the problem. In general, the complete project (VS
solution) would have several executables depending on the same
library. Surely you are not suggesting putting an add_library()
entry in all the CMakeLists.txt files associated with those
executables? That would destroy most of the advantages of having a
library in the first place-- basically a "sledgehammer" solution
to use your phrase.

>If I understand your problem correctly, I fear you may be trying to use a
sledgehammer to crack a peanut!
What do you consider the downsides of the approach I proposed?
Based on limited testing, I have not run into problems with having
all exe and lib files in a single directory. I don't like having to
add the two set() entries but they are only in the top-level
CMakeLists.txt file.

When I first posted my request for help with this problem, I assumed
it was a common enough issue that I would quickly get a response with
a simple solution. That I have not has left me somewhat astonished. I know
people are using cmake with large Visual Studio projects and I assume they
are using static libs. So I'm unclear on why there isn't more discussion of
this issue. If anyone has insights to share on this, I'd be very interested
in hearing them.

On Sat, Oct 4, 2014 at 8:12 PM, Jim Butler <j.e.butler at limitpoint.com>
wrote:

> Bill Greene<w.h.greene at gmail.com>  wrote:
>
>  add_library (cmTestLib STATIC MySub.cpp MySub.h)
>>
> You need not include the header files in an add_library call. They'll be
> found by the compiler, provided you have  included them in the cpp files.
>
> If I understand your problem correctly, I fear you may be trying to use a
> sledgehammer to crack a peanut!
>
> Try this:
>
>         add_library (cmTestLib STATIC MySub.cpp)
>
>         add_executable(cmTestMain cmTestMain.cpp)
>
>         # Make sure the library is up to date
>         add_dependencies(cmTestMain cmTestLib)
>
>         # Add lib to the link line
>         target_link_libraries(cmTestMain cmTestLib)
>
> Cheers,
> Jim
>
> --
> Jim Butler
> Build Systems Engineer
> Limit Point Systems, Inc.
> http://cmake.limitpoint.com
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141005/497eb7a2/attachment.html>

From dushistov at gmail.com  Sun Oct  5 11:38:23 2014
From: dushistov at gmail.com (Evgeniy Dushistov)
Date: Sun, 5 Oct 2014 19:38:23 +0400
Subject: [CMake] generator-expressions + pch -> need new magic
In-Reply-To: <CAKBW4XiiWvNs6o6BUqUS50tqk1KJb2n3pVuyWG4LLsEvQvTN-w@mail.gmail.com>
References: <CAKBW4XiiWvNs6o6BUqUS50tqk1KJb2n3pVuyWG4LLsEvQvTN-w@mail.gmail.com>
Message-ID: <CAKBW4XgAqrvVW=GbYO7aOx9UyXAQXNcgpDxgjvRFmEupcjs9vw@mail.gmail.com>

I found workaround for that problem,
I add to this loop:
foreach(flag ${MY_DEFS})
     list(APPEND gcc_flags  "-D${flag}")
endforeach()

such code:
  foreach(flag ${PL_COMP_DEFS})
    string(FIND ${flag} "$<" find_res)
    if (find_res EQUAL 0)
      list(APPEND gcc_flags "$<$<BOOL:${flag}>:-D$<JOIN:${flag}, -D>>")
    else ()
      list(APPEND gcc_flags  "-D${flag}")
    endif ()
  endforeach()

but may there is better solution?

On Sun, Oct 5, 2014 at 10:25 AM, Evgeniy Dushistov <dushistov at gmail.com> wrote:
> Hi,
> in my project I used such magic code for precompiled headers support
> (gcc,clang only):
>
> #take gcc_flags from
>                               ${CMAKE_CXX_FLAGS}
> ${CMAKE_CXX_FLAGS_${_build_type}}
>            get_target_property(... COMPILE_FLAGS)
>                          get_directory_property(...
> INCLUDE_DIRECTORIES)                               foreach(flag
> ${MY_INCLUDES})
>     list(APPEND gcc_flags  "-I" "${pl_flag}")
>                      endforeach()
>
> get_directory_property(... COMPILE_DEFINITIONS)
> foreach(flag ${MY_DEFS})
>                               list(APPEND gcc_flags  "-D${pl_flag}")
>                                               endforeach()
>
>            get_directory_property(...
> COMPILE_DEFINITIONS_${_build_type})       add_custom_command(...
> ${gcc_flags} ...)
> All works fine, until cmake-3.0 with cmake-generator-expressions.
>      With cmake-3.0 COMPILE_DEFINITIONS return something like this:
> $<$<NOT:$<CONFIG:Debug>>:QT_NO_DEBUG>
>
> This is empty string on compilation stage, not on not configuration
> stage. So "gcc" is called like this: "gcc -D<empty>" and give error.
> So question is it possible to evaluate "generator-expressions" within
> CMakeLists.txt? Or may be in cmake 3.x there another is way to extract
> compilation
> flags without such magic as above?

From ruslan_baratov at yahoo.com  Sun Oct  5 14:46:39 2014
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Sun, 05 Oct 2014 22:46:39 +0400
Subject: [CMake] Dependency paths in CMake package config files
In-Reply-To: <86tx3m4dhv.fsf@doc.ic.ac.uk>
References: <86tx3m4dhv.fsf@doc.ic.ac.uk>
Message-ID: <5431920F.9010405@yahoo.com>

On 02-Oct-14 20:56, Alexander Lamaison wrote:
> How do you manage the paths to the libraries that your static library
> package depends on in the XXXConfig.cmake that gets installed with
> package XXX?
>
> I'm exporting my static library package from both the build tree and
> from the installation location like
>
>    add_library(foo STATIC ...)
>    target_link_libraries(foo PRIVATE ...)
>    install(TARGETS foo EXPORT FooConfig ...)
>
>    ## During package installation, install FooConfig.cmake
>    install(EXPORT FooConfig NAMESPACE Foo:: DESTINATION lib)
>
>    ## During build, register directly from build tree
>    export(TARGETS foo NAMESPACE Foo:: FILE FooConfig.cmake)
>    export(PACKAGE Foo)
>
> This does a great job of generating a FooConfig.cmake that can be used
> by other projects on the local machine.  But target foo is linked with
> other dependencies, for example, OpenSSH so the installed config file
> includes the following:
>
>    set_property(TARGET Foo::foo APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
>    set_target_properties(Foo::foo PROPERTIES
>      IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
>      IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG "C:/OpenSSL-Win64/lib/VC/ssleay32MDd.lib;C:/OpenSSL-Win64/lib/VC/libeay32MDd.lib;ws2_32"
>      IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/lib/libfoo.lib")
You can run `find_package` from FooConfig.cmake:

# FooConfig.cmake.in
@PACKAGE_INIT@

find_package(OpenSSL REQUIRED)
target_link_libraries(Foo::foo ${OPENSSL_LIBRARIES})
target_include_directories(Foo::foo ${OPENSSL_INCLUDE_DIR})

>
> So my question is, in general, how can I make installabled static
> libraries with a package config file?  Or is the trying to redistribute
> static libraries a bad idea in the first place?
It's not related to static/shared, this is about absolute path. If you 
have an absolute path for dynamic library in FooConfig.cmake you'll have 
the same issue.

From steveire at gmail.com  Sun Oct  5 14:55:33 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 05 Oct 2014 20:55:33 +0200
Subject: [CMake] Dependency paths in CMake package config files
References: <86tx3m4dhv.fsf@doc.ic.ac.uk> <5431920F.9010405@yahoo.com>
Message-ID: <m0s476$vo6$1@ger.gmane.org>

Ruslan Baratov via CMake wrote:

>> So my question is, in general, how can I make installabled static
>> libraries with a package config file?  Or is the trying to redistribute
>> static libraries a bad idea in the first place?
> It's not related to static/shared, this is about absolute path. If you
> have an absolute path for dynamic library in FooConfig.cmake you'll have
> the same issue.

The solution is IMPORTED targets in the INTERFACE_LINK_LIBRARIES and a 
find_package to define the IMPORTED target on the consumer system.

I don't know if that works as well for static libraries, because you'd 
probably need to ensure that the exact same file is linked to by the 
consumer, which is not the case with shared libraries - as long as the API 
is the same, you could link to another version.

Thanks,

Steve.



From tim at klingt.org  Mon Oct  6 00:38:54 2014
From: tim at klingt.org (Tim Blechmann)
Date: Mon, 06 Oct 2014 12:38:54 +0800
Subject: [CMake] [msvc] building windows drivers with cmake
Message-ID: <m0t6d0$bve$1@ger.gmane.org>

hi,

i'm wondering, is it possible to generate msvc solutions for windows
kernel mode drivers?

afaict, the generated projects would have to use a specific platform
toolset:
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>

but also some other specific entries, like:
<ConfigurationType>Driver</ConfigurationType>
<DriverType>KMDF</DriverType>

maybe it be possible/easy/reasonable to add custom properties to
cmake-generated msvc project files? or would there be any other way to
achieve this in a better way?

thnx,
tim


From elfring at users.sourceforge.net  Mon Oct  6 03:00:19 2014
From: elfring at users.sourceforge.net (SF Markus Elfring)
Date: Mon, 06 Oct 2014 09:00:19 +0200
Subject: [CMake] Declaring relationships between components for software
	packages
Message-ID: <54323E03.5070003@users.sourceforge.net>

Hello,

Variables like "CPACK_DEBIAN_PACKAGE_DEPENDS" and "CPACK_RPM_PACKAGE_REQUIRES"
can be set.
Do you know any other package formats where similar settings are supported by
corresponding generators?
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators

Regards,
Markus

From johannes.zarl at jku.at  Mon Oct  6 05:55:54 2014
From: johannes.zarl at jku.at (Johannes Zarl)
Date: Mon, 6 Oct 2014 11:55:54 +0200
Subject: [CMake] Install path for package files
In-Reply-To: <86oatte9ku.fsf@doc.ic.ac.uk>
References: <CAC9OkhHAe5VvU1dEviASN7ZPr_H4Q+p66frqFojV=vv0vyaRWQ@mail.gmail.com>
 <86oatte9ku.fsf@doc.ic.ac.uk>
Message-ID: <201410061155.54757.johannes.zarl@jku.at>

As is also written in the stackoverflow answer, this information can be found 
in the cmake documentation for find_package[1]:

> <prefix>/                                               (W)
> <prefix>/(cmake|CMake)/                                 (W)
> <prefix>/<name>*/                                       (W)
> <prefix>/<name>*/(cmake|CMake)/                         (W)
> <prefix>/(lib/<arch>|lib|share)/cmake/<name>*/          (U)
> <prefix>/(lib/<arch>|lib|share)/<name>*/                (U)
> <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/  (U)
> 
> On systems supporting OS X Frameworks and Application Bundles the following
> directories are searched for frameworks or bundles containing a
> configuration file: <prefix>/<name>.framework/Resources/                  
>  (A)
> <prefix>/<name>.framework/Resources/CMake/              (A)
> <prefix>/<name>.framework/Versions/*/Resources/         (A)
> <prefix>/<name>.framework/Versions/*/Resources/CMake/   (A)
> <prefix>/<name>.app/Contents/Resources/                 (A)
> <prefix>/<name>.app/Contents/Resources/CMake/           (A)

Just use any directory based on your target platform and you're fine.

[1] http://www.cmake.org/cmake/help/v3.0/command/find_package.html

HTH,
  Johannes

On Friday, 3. October 2014, 12:22:57, Alexander Lamaison wrote:
> Noah Roberts <roberts.noah at gmail.com>
> writes:
> 
> snip
> 
> > I gather I need to create a BlahModule.cmake file that implements the
> > package finding stuff.  I want to install this wherever cmake will find
> > it.  I don't want to put it in some place in the system and then expect
> > dependent CMakeLists.txt files to set that path when using
> > find_package.
> 
> snip
> 
> > So what is the variable I use in the install() function for the
> > DESTINATION parameter to do this?  I assume there must be one...  I
> > can't seem to find it in the documentation though.
> 
> Me neither.  This answer [1] lists the places that CMake looks for the
> BlahConfig.cmake file so on Unix it's fairly simple.  Set the
> DESTINATION to 'lib' which will install it to
> /usr/local/lib/BlahConfig.cmake where, presumable, find_package will
> locate it.  I don't understand how this is meant to work on Windows,
> though.  How is CMake meant to know which root to start thee search
> under?
> 
> [1] http://stackoverflow.com/a/11965673/67013
> 
> Alex


From sonitushar at gmail.com  Mon Oct  6 08:30:06 2014
From: sonitushar at gmail.com (Tushar Soni)
Date: Mon, 6 Oct 2014 14:30:06 +0200
Subject: [CMake] Cmake(3.0.2) Eclipse project indexing issues under linux
Message-ID: <CABPoMet-0P8-aoFApCx6yHq=ifOnLLxVdHChkhWHjviDJENw4A@mail.gmail.com>

Hi,

After generating Eclipse projects and importing them, Eclipse is not
indexing all source files. I have detailed the issue (so sorry for the long
email) and the experiments I have performed to resolve the issue. I would
be really glad if someone could point out, what is going wrong or is there
some bug?

Not to go in too much details, here is how my directory (project) structure
looks like in order to explain the issue in more details:

Sources:


*$someDir/common/project_a/src/source_a.cpp*
*$someDir/common/project_a/CMakeLists.tx*t -> Project A is a common lib,
uses by many tests

*$someDir/tests/test_a/src/test_a.cpp*
*$someDir/tests/test_a/CMakeLists.txt* -> Includes the Project A using
add_subdirectory and creates a share object

Cmake build directories:
*$someDir/cmakeOut/**common/project_a/*
*$someDir/cmakeOut/tests/test_a/*

Cmake generated everything without errors and building the project using
make or Eclipse was not an issue. The issue is only when I import the
project in Eclipse (version 4.3.2) by *Import -> General -> Existing
Project -> $someDir/cmakeOut/tests/test_a/*, the indexer does not seem to
be working properly. It only indexes one source (test_a.cpp) whereas it
should index two (test_a.cpp + sourc_a.cpp).

this is just an example setup, in my actual project, only 1 source file
gets indexed out of the 142 it should do. therefore it makes using Eclipse
very hard!

Now this is what I noticed with my experiments.

*Experiment 1*: Change cmake version and compare

I used the exact same files and folder structure but changed the cmake
version to 2.8.10.2. The generated Eclipse project was able to index both
the source files! This was mind boggling. I have to use the cmake 3.0.2
version, so I tried to narrow down the issue.

When I did the diff of the .cproject created by the two cmake version I saw
this:

cmake 3.0.2 has this in the .cproject

*<pathentry kind="src" path="[Source directory]"/>*
<pathentry excluding="*[Source directory]/|***/CMakeFiles/" kind="out"
path=""/>

cmake 2.8.10.2 has this in the .cproject

<pathentry excluding="**/CMakeFiles/" kind="out" path=""/>

The rest of the file is similar (except cmake path, which is obvious).

*Success Result*: If I delete the line *<pathentry kind="src" path="[Source
directory]"/> *from the .cproject and then import the project, indexing
seems to be working!!! however I cant use this solution as my project is
not checked in and every body using it needs to make this step manually.

*Experiment 2*: Change the import method

After a lot of googling I found out that someone was suggesting to import
the project using this method (BTW, for totally different problem): *Import
-> C/C++ -> Existing Code as Makefile Project ->
$someDir/cmakeOut/tests/test_a/ *. When I did this, it again works! Mind
boggling yet again!

Just by chance I found out that this method works because, by importing
this way Eclipse somehow modifies the .cproject and removed the lines like
I did in first experiment.

*Conclusion*: So based on my experiments this line in the .cproject is
causing an issue with indexing:
*<pathentry kind="src" path="[Source directory]"/>*

I know most likely my conclusion is not correct but I do not have any other
explanation. Also I do not know why this line is actually the issue!
Therfore I am writing to you all to understand the issue a bit better.
Maybe the issue is elsewhere.

Thanks in advance!

-- 
Best Regards,

Tushar Soni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141006/b4efd425/attachment.html>

From bill.hoffman at kitware.com  Mon Oct  6 10:51:45 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 06 Oct 2014 10:51:45 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
References: <54308CFD.4010206@limitpoint.com>
 <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
Message-ID: <5432AC81.5080903@kitware.com>

Bill,

I want to reset this conversation a bit.  What you are doing should work 
no problem.  Most of the suggestions should not be needed.  I do agree 
that glob is bad, but it will cause different problems.   Anyway, I 
created the following example based on your posts and it works with VS 
2010.   Can you try this and report back?  This could be a bug in VS as 
CMake has very little to do with depends like this and the VS IDE.

I did this to test:
$ ls -l b/cmTestMain/Debug/
total 684
-rwxr-xr-x 1 hoffman Domain Users  28160 Oct  6 10:47 cmTestMain.exe

hoffman at quasar ~/Work/dep
$ touch cmTestLib/MySub.cpp

#build from VS IDE and exe relinks
hoffman at quasar ~/Work/dep
$ ls -l b/cmTestMain/Debug/
total 684
-rwxr-xr-x 1 hoffman Domain Users  28160 Oct  6 10:48 cmTestMain.exe


hoffman at quasar ~/Work/dep
$ touch cmTestLib/MySub.h

# build from VS IDE exe relinks again
hoffman at quasar ~/Work/dep
$ ls -l b/cmTestMain/Debug
total 684
-rwxr-xr-x 1 hoffman Domain Users  28160 Oct  6 10:49 cmTestMain.exe




top level:
-----------
cmake_minimum_required (VERSION 2.8)
project(cmTest)
add_subdirectory (cmTestLib)
add_subdirectory (cmTestMain)

cmTestLib
--------------
add_library (cmTestLib STATIC MySub.cpp MySub.h)

------ cmTestLib/MySub.cpp
#include "MySub.h"

int hello()  { return 0;}

----- cmTestLib/MySub.h
int hello();

cmTestMain
----------------
include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
add_executable (cmTestMain cmTestMain.cpp)
target_link_libraries (cmTestMain cmTestLib)


Here are the source files:

------ cmTestLib/MySub.cpp
#include "MySub.h"

int hello()  { return 0;}

----- cmTestLib/MySub.h
int hello();

cmTestMain/cmTestMain.cpp

#include "MySub.h"

int main()
{
   return hello();
}




From masariello at gmail.com  Mon Oct  6 11:34:57 2014
From: masariello at gmail.com (Alessio Massaro)
Date: Mon, 6 Oct 2014 16:34:57 +0100
Subject: [CMake] Problem with Cmake 3.0.2 and MSVC: devenv.com does not
 print CMAKE_C_COMPILER=<path_to_cl.exe> during
 CMakeDetermineCompilerId.cmake
Message-ID: <CAL_VXbaCae5SmJEMB8-Y_PKzxhNThnBV9soxzn08Q+gu56budA@mail.gmail.com>

Hi there,

For some mysterious reason the invocation in subject does not print out the
all-important message CMAKE_C_COMPILER=<path_to_cl.exe> after the
compilation of CompilerIdC.c

The invocation in question is in CMakeDetermnineCompilerId.cmake like 188.
The CMAKE_C_COMPILER message is the one echo'ed by a the
VCPostBuildEventTool action in CompilerIdC.vcproj

I suppose I should send the query to a Microsoft forum, really. But I was
hoping someone would have seen this odd behavior before.

If I build CompilerIdC.vcproj in Visual Studio, then I do see the message
in the build output.

Note that the compilation of CompilerIdC.c does work properly. And so does
the extraction of the compiler ID strings from the executable binary.

I currently have Visual Studio both VS2013 and the Intel C++ compiler
installed on the same machine. Could that be having a nefarious influence?

I'm seeing the same behavior with CMake 2.8.12.

Big thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141006/3075ae70/attachment.html>

From w.h.greene at gmail.com  Mon Oct  6 14:10:25 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Mon, 6 Oct 2014 14:10:25 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <5432AC81.5080903@kitware.com>
References: <54308CFD.4010206@limitpoint.com>
 <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
 <5432AC81.5080903@kitware.com>
Message-ID: <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>

Thanks very much for taking a careful look at this, Bill.

The source files in my test were more or less the same as yours but I
changed them to be identical.

Most of my previous tests were with the 2013 Express version of VS but
I had also done a couple of tests with 2010 Express. Previously, I
was seeing the same dependency behavior problem with both versions.
I did this latest test with 2010 Express. The version of that I currently
have installed is: Version 10.0.40219.1 SP1Rel.

After I change MySub.cpp, either with "touch" or by editing the file in the
GUI, and rebuild either with the F7 key or by selecting the "Build Solution"
menu item, I see something like this:

$ ls -l cmTest*/Debug
cmTestLib/Debug:
total 4
----------+ 1 bgreene None 2742 Oct  6 13:59 cmTestLib.lib

cmTestMain/Debug:
total 692
----------+ 1 bgreene None  28160 Oct  6 13:46 cmTestMain.exe
----------+ 1 bgreene None 312688 Oct  6 13:46 cmTestMain.ilk
----------+ 1 bgreene None 363520 Oct  6 13:46 cmTestMain.pdb

If I do, "Rebuild Solution", not surprisingly, both the lib and exe get
rebuilt.

 >This could be a bug in VS as CMake has very little to do with depends
like this and the VS IDE.

I'm certainly not an expert with Visual Studio but this sure has all the
appearances of a VS bug.
The VS solution generated by cmake looks "right" to me. However, the fact
that this behavior occurs
in both VS 2010 and VS 2013 seems surprising.

Bill

On Mon, Oct 6, 2014 at 10:51 AM, Bill Hoffman <bill.hoffman at kitware.com>
wrote:

> Bill,
>
> I want to reset this conversation a bit.  What you are doing should work
> no problem.  Most of the suggestions should not be needed.  I do agree that
> glob is bad, but it will cause different problems.   Anyway, I created the
> following example based on your posts and it works with VS 2010.   Can you
> try this and report back?  This could be a bug in VS as CMake has very
> little to do with depends like this and the VS IDE.
>
> I did this to test:
> $ ls -l b/cmTestMain/Debug/
> total 684
> -rwxr-xr-x 1 hoffman Domain Users  28160 Oct  6 10:47 cmTestMain.exe
>
> hoffman at quasar ~/Work/dep
> $ touch cmTestLib/MySub.cpp
>
> #build from VS IDE and exe relinks
> hoffman at quasar ~/Work/dep
> $ ls -l b/cmTestMain/Debug/
> total 684
> -rwxr-xr-x 1 hoffman Domain Users  28160 Oct  6 10:48 cmTestMain.exe
>
>
> hoffman at quasar ~/Work/dep
> $ touch cmTestLib/MySub.h
>
> # build from VS IDE exe relinks again
> hoffman at quasar ~/Work/dep
> $ ls -l b/cmTestMain/Debug
> total 684
> -rwxr-xr-x 1 hoffman Domain Users  28160 Oct  6 10:49 cmTestMain.exe
>
>
>
>
> top level:
> -----------
> cmake_minimum_required (VERSION 2.8)
> project(cmTest)
> add_subdirectory (cmTestLib)
> add_subdirectory (cmTestMain)
>
> cmTestLib
> --------------
> add_library (cmTestLib STATIC MySub.cpp MySub.h)
>
> ------ cmTestLib/MySub.cpp
> #include "MySub.h"
>
> int hello()  { return 0;}
>
> ----- cmTestLib/MySub.h
> int hello();
>
> cmTestMain
> ----------------
> include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
> add_executable (cmTestMain cmTestMain.cpp)
> target_link_libraries (cmTestMain cmTestLib)
>
>
> Here are the source files:
>
> ------ cmTestLib/MySub.cpp
> #include "MySub.h"
>
> int hello()  { return 0;}
>
> ----- cmTestLib/MySub.h
> int hello();
>
> cmTestMain/cmTestMain.cpp
>
> #include "MySub.h"
>
> int main()
> {
>   return hello();
>
> }
>
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141006/f23af4f8/attachment-0001.html>

From bill.hoffman at kitware.com  Mon Oct  6 16:46:29 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 06 Oct 2014 16:46:29 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>
References: <54308CFD.4010206@limitpoint.com>	<CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>	<5432AC81.5080903@kitware.com>
 <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>
Message-ID: <5432FFA5.4040701@kitware.com>

On 10/6/2014 2:10 PM, Bill Greene wrote:
> After I change MySub.cpp, either with "touch" or by editing the file in the
> GUI, and rebuild either with the F7 key or by selecting the "Build Solution"
> menu item, I see something like this:
What if you right click on ALL_BUILD and build that project?  It maybe 
that you just have the wrong project setup as the main project to build 
and it is only building the library and not the executable.  CMake does 
not control that.  You have to pick the active project from the GUI.

Another thing to try is to run cmake --build . and see if that works. 
That will always build the ALL_BUILD target.

-Bill


From a.neundorf-work at gmx.net  Mon Oct  6 16:51:20 2014
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Mon, 06 Oct 2014 22:51:20 +0200
Subject: [CMake] Cmake(3.0.2) Eclipse project indexing issues under linux
In-Reply-To: <CABPoMet-0P8-aoFApCx6yHq=ifOnLLxVdHChkhWHjviDJENw4A@mail.gmail.com>
References: <CABPoMet-0P8-aoFApCx6yHq=ifOnLLxVdHChkhWHjviDJENw4A@mail.gmail.com>
Message-ID: <6934939.JrfAfnnRdt@tuxedo.neundorf.net>

Hi,

thanks for your detailled findings.
Can you please create a ticket in the bug tracker with this, so it doesn't get 
lost ?
http://public.kitware.com/Bug

Thanks
Alex

On Monday, October 06, 2014 14:30:06 Tushar Soni wrote:
> Hi,
> 
> After generating Eclipse projects and importing them, Eclipse is not
> indexing all source files. I have detailed the issue (so sorry for the long
> email) and the experiments I have performed to resolve the issue. I would
> be really glad if someone could point out, what is going wrong or is there
> some bug?
> 
> Not to go in too much details, here is how my directory (project) structure
> looks like in order to explain the issue in more details:
> 
> Sources:
> 
> 
> *$someDir/common/project_a/src/source_a.cpp*
> *$someDir/common/project_a/CMakeLists.tx*t -> Project A is a common lib,
> uses by many tests
> 
> *$someDir/tests/test_a/src/test_a.cpp*
> *$someDir/tests/test_a/CMakeLists.txt* -> Includes the Project A using
> add_subdirectory and creates a share object
> 
> Cmake build directories:
> *$someDir/cmakeOut/**common/project_a/*
> *$someDir/cmakeOut/tests/test_a/*
> 
> Cmake generated everything without errors and building the project using
> make or Eclipse was not an issue. The issue is only when I import the
> project in Eclipse (version 4.3.2) by *Import -> General -> Existing
> Project -> $someDir/cmakeOut/tests/test_a/*, the indexer does not seem to
> be working properly. It only indexes one source (test_a.cpp) whereas it
> should index two (test_a.cpp + sourc_a.cpp).
> 
> this is just an example setup, in my actual project, only 1 source file
> gets indexed out of the 142 it should do. therefore it makes using Eclipse
> very hard!
> 
> Now this is what I noticed with my experiments.
> 
> *Experiment 1*: Change cmake version and compare
> 
> I used the exact same files and folder structure but changed the cmake
> version to 2.8.10.2. The generated Eclipse project was able to index both
> the source files! This was mind boggling. I have to use the cmake 3.0.2
> version, so I tried to narrow down the issue.
> 
> When I did the diff of the .cproject created by the two cmake version I saw
> this:
> 
> cmake 3.0.2 has this in the .cproject
> 
> *<pathentry kind="src" path="[Source directory]"/>*
> <pathentry excluding="*[Source directory]/|***/CMakeFiles/" kind="out"
> path=""/>
> 
> cmake 2.8.10.2 has this in the .cproject
> 
> <pathentry excluding="**/CMakeFiles/" kind="out" path=""/>
> 
> The rest of the file is similar (except cmake path, which is obvious).
> 
> *Success Result*: If I delete the line *<pathentry kind="src" path="[Source
> directory]"/> *from the .cproject and then import the project, indexing
> seems to be working!!! however I cant use this solution as my project is
> not checked in and every body using it needs to make this step manually.
> 
> *Experiment 2*: Change the import method
> 
> After a lot of googling I found out that someone was suggesting to import
> the project using this method (BTW, for totally different problem): *Import
> -> C/C++ -> Existing Code as Makefile Project ->
> $someDir/cmakeOut/tests/test_a/ *. When I did this, it again works! Mind
> boggling yet again!
> 
> Just by chance I found out that this method works because, by importing
> this way Eclipse somehow modifies the .cproject and removed the lines like
> I did in first experiment.
> 
> *Conclusion*: So based on my experiments this line in the .cproject is
> causing an issue with indexing:
> *<pathentry kind="src" path="[Source directory]"/>*
> 
> I know most likely my conclusion is not correct but I do not have any other
> explanation. Also I do not know why this line is actually the issue!
> Therfore I am writing to you all to understand the issue a bit better.
> Maybe the issue is elsewhere.
> 
> Thanks in advance!


From w.h.greene at gmail.com  Mon Oct  6 17:47:43 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Mon, 6 Oct 2014 17:47:43 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <5432FFA5.4040701@kitware.com>
References: <54308CFD.4010206@limitpoint.com>
 <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
 <5432AC81.5080903@kitware.com>
 <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>
 <5432FFA5.4040701@kitware.com>
Message-ID: <CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>

>
>
>
>What if you right click on ALL_BUILD and build that project?
For some reason, the ALL_BUILD project was *not* selected/checked to build.
However if I build it explicitly or
change the VS configuration so it does build, the main program is still not
being re-linked.

>Another thing to try is to run cmake --build . and see if that works.
That appears to compile the lib cpp file and rebuild the library just fine
but it also doesn't re-link the main program.
I've copied the output from "cmake --build" below in case that is of any
use.

Bill

------------------------------------------------------------------------
c:\temp\Projects>cmake --build cmake_test_hoffman
Microsoft (R) Build Engine version 4.0.30319.18408
[Microsoft .NET Framework, version 4.0.30319.18444]
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 10/6/2014 5:29:23 PM.
Project "c:\temp\Projects\cmake_test_hoffman\ALL_BUILD.vcxproj" on node 1
(default targets).
Project "c:\temp\Projects\cmake_test_hoffman\ALL_BUILD.vcxproj" (1) is
building "C:\temp\Projects\cmake_test_hoffman\ZE
RO_CHECK.vcxproj" (2) on node 1 (default targets).
InitializeBuildStatus:
  Creating "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild" because
"AlwaysCreate" was specified.
FinalizeBuildStatus:
  Deleting file "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild".
  Touching "Win32\Debug\ZERO_CHECK\ZERO_CHECK.lastbuildstate".
Done Building Project
"C:\temp\Projects\cmake_test_hoffman\ZERO_CHECK.vcxproj" (default targets).

Project "c:\temp\Projects\cmake_test_hoffman\ALL_BUILD.vcxproj" (1) is
building "C:\temp\Projects\cmake_test_hoffman\cm
TestLib\cmTestLib.vcxproj" (3) on node 1 (default targets).
InitializeBuildStatus:
  Creating "cmTestLib.dir\Debug\cmTestLib.unsuccessfulbuild" because
"AlwaysCreate" was specified.
CustomBuild:
  All outputs are up-to-date.
ClCompile:
  c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /Zi
/nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _
  WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1
/MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope
   /GR /Fo"cmTestLib.dir\Debug\\" /Fd"cmTestLib.dir\Debug\vc100.pdb" /Gd
/TP /analyze- /errorReport:queue ..\..\..\..\w
  greene\tests\c++\cmake_test_hoffman\cmTestLib\MySub.cpp
  MySub.cpp
Lib:
  c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\Lib.exe
/OUT:"C:\temp\Projects\cmake_test_hoffman\cmTestLi
  b\Debug\cmTestLib.lib" /NOLOGO cmTestLib.dir\Debug\MySub.obj
  cmTestLib.vcxproj ->
C:\temp\Projects\cmake_test_hoffman\cmTestLib\Debug\cmTestLib.lib
FinalizeBuildStatus:
  Deleting file "cmTestLib.dir\Debug\cmTestLib.unsuccessfulbuild".
  Touching "cmTestLib.dir\Debug\cmTestLib.lastbuildstate".
Done Building Project
"C:\temp\Projects\cmake_test_hoffman\cmTestLib\cmTestLib.vcxproj" (default
targets).

Project "c:\temp\Projects\cmake_test_hoffman\ALL_BUILD.vcxproj" (1) is
building "C:\temp\Projects\cmake_test_hoffman\cm
TestMain\cmTestMain.vcxproj" (4) on node 1 (default targets).
InitializeBuildStatus:
  Creating "cmTestMain.dir\Debug\cmTestMain.unsuccessfulbuild" because
"AlwaysCreate" was specified.
CustomBuild:
  All outputs are up-to-date.
ClCompile:
  All outputs are up-to-date.
ManifestResourceCompile:
  All outputs are up-to-date.
Link:
  All outputs are up-to-date.
Manifest:
  All outputs are up-to-date.
FinalizeBuildStatus:
  Deleting file "cmTestMain.dir\Debug\cmTestMain.unsuccessfulbuild".
  Touching "cmTestMain.dir\Debug\cmTestMain.lastbuildstate".
Done Building Project
"C:\temp\Projects\cmake_test_hoffman\cmTestMain\cmTestMain.vcxproj"
(default targets).

InitializeBuildStatus:
  Creating "Win32\Debug\ALL_BUILD\ALL_BUILD.unsuccessfulbuild" because
"AlwaysCreate" was specified.
CustomBuild:
  Build all projects
FinalizeBuildStatus:
  Deleting file "Win32\Debug\ALL_BUILD\ALL_BUILD.unsuccessfulbuild".
  Touching "Win32\Debug\ALL_BUILD\ALL_BUILD.lastbuildstate".
Done Building Project
"c:\temp\Projects\cmake_test_hoffman\ALL_BUILD.vcxproj" (default targets).


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141006/11445764/attachment.html>

From Bin.Chen at dts.com  Mon Oct  6 20:43:53 2014
From: Bin.Chen at dts.com (Bin Chen)
Date: Tue, 7 Oct 2014 00:43:53 +0000
Subject: [CMake] Xcode generator per architecture setting
Message-ID: <ABDFA5D59E19E44C8E1B3138320F9AAACD079E64@LAX-EXMB02.dts.local>

Hi,

For Xcode generator, is it possible to specify CFLAGS for each architecture, e.g. i386 and x86_64? Thanks!

Best regards,
Bin Chen


________________________________

Notice:
This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141007/c18a3ff5/attachment-0001.html>

From ruslan_baratov at yahoo.com  Tue Oct  7 02:19:04 2014
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 07 Oct 2014 10:19:04 +0400
Subject: [CMake] Parallel build with custom command
Message-ID: <543385D8.1020804@yahoo.com>

Hi,

I have a problem with parallel build of project with custom command. 
Custom command generates two files and depends on generator script. For 
optimization purpose first file created only when not exists. This lead 
to conflict, even if I "protect" custom command with a custom target and 
set explicit dependencies:

 > cmake -H. -B_builds
 > cmake --build _builds -- -j4 # First build OK
 > touch generate.cmake
 > cmake --build _builds -- -j4 # Second build. Unexpected `Script run` 
several messages
[ 16%] Custom command
Script run
[ 33%] Custom target
[ 33%] Built target Generate
[ 66%] [ 66%] Custom command
Custom command
Script run
Script run
Scanning dependencies of target Blib
[ 66%] Custom command
Script run
[ 66%] [ 83%] Built target Alib
Custom command
Script run
[100%] Building CXX object CMakeFiles/Blib.dir/B.cpp.o
Linking CXX static library libBlib.a
[100%] Built target Blib

CMakeLists.txt: http://pastebin.com/dspw4j1S
generate.cmake: http://pastebin.com/XNS6hPRX

Is it a known issue?

From syntheticpp at gmx.net  Tue Oct  7 03:58:08 2014
From: syntheticpp at gmx.net (Peter Kuemmel)
Date: Tue, 7 Oct 2014 09:58:08 +0200
Subject: [CMake] Policy CMP0020 setting is ignored
Message-ID: <trinity-cd0b12c5-5208-421a-bac7-81db9af249c2-1412668688895@3capp-gmx-bs30>

> Hi
>
> although I have "cmake_policy (SET CMP0020 NEW)" in my top level  
> CMakeLists.txt file I get a lot of warnings about "Policy CMP0020 is  
> not set..."
> After some testing it seems to me that the policy setting is only  
> respected for the configure but not for the generate step.
> Has anyone an idea what might be the cause?
>
> Dominik

A call to cmake_minimum_required() resets the policy setting.

Peter

From brad.king at kitware.com  Tue Oct  7 09:33:46 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 07 Oct 2014 09:33:46 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>
References: <54308CFD.4010206@limitpoint.com>
 <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
 <5432AC81.5080903@kitware.com>
 <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>
 <5432FFA5.4040701@kitware.com>
 <CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>
Message-ID: <5433EBBA.1050108@kitware.com>

On Mon, Oct 6, 2014 at 5:47 PM, Bill Greene wrote:
>>Another thing to try is to run cmake --build . and see if that works.
> That appears to compile the lib cpp file and rebuild the library just fine
> but it also doesn't re-link the main program.

I also cannot reproduce this from Bill H's example.  Both the .lib and
.exe file are rebuilt after touching only the lib .cpp file.

Try building the main target directly after touching the lib .cpp file:

 cmake --build . --config Debug --target cmTestMain

If that reproduces the issue then we can ask msbuild for verbose logging
info.  Touch the lib .cpp file again and then run:

 cmake --build . --config Debug --target cmTestMain -- -verbosity:diag >log 2>&1

The log file will be big and verbose.  If you see something stand out
in it then please reply with a relevant subset of the log.  Otherwise
please zip it up and send the log to me and Bill H. off-list since
it will likely be too big to attach on-list.

Thanks,
-Brad

From bill.hoffman at kitware.com  Tue Oct  7 10:00:53 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 07 Oct 2014 10:00:53 -0400
Subject: [CMake] Parallel build with custom command
In-Reply-To: <543385D8.1020804@yahoo.com>
References: <543385D8.1020804@yahoo.com>
Message-ID: <5433F215.9040502@kitware.com>

On 10/7/2014 2:19 AM, Ruslan Baratov via CMake wrote:
> Hi,
>
> I have a problem with parallel build of project with custom command.
> Custom command generates two files and depends on generator script. For
> optimization purpose first file created only when not exists. This lead
> to conflict, even if I "protect" custom command with a custom target and
> set explicit dependencies:

Can you give an example?

add_dependencies should be what you use.
http://www.cmake.org/cmake/help/v3.0/command/add_dependencies.html
CMake does not know about the generated files.  But if you have targets 
that depend on each other, they will build in order.

-Bill

From ruslan_baratov at yahoo.com  Tue Oct  7 10:26:54 2014
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 07 Oct 2014 18:26:54 +0400
Subject: [CMake] Parallel build with custom command
In-Reply-To: <5433F215.9040502@kitware.com>
References: <543385D8.1020804@yahoo.com> <5433F215.9040502@kitware.com>
Message-ID: <5433F82E.4010202@yahoo.com>

On 07-Oct-14 18:00, Bill Hoffman wrote:
> On 10/7/2014 2:19 AM, Ruslan Baratov via CMake wrote:
>> Hi,
>>
>> I have a problem with parallel build of project with custom command.
>> Custom command generates two files and depends on generator script. For
>> optimization purpose first file created only when not exists. This lead
>> to conflict, even if I "protect" custom command with a custom target and
>> set explicit dependencies:
>
> Can you give an example?
Yes, I leave a links at the end of the previous message:

CMakeLists.txt: http://pastebin.com/dspw4j1S
generate.cmake: http://pastebin.com/XNS6hPRX
>
> add_dependencies should be what you use.
Have it:

add_custom_target(
     Generate
     ...
)
add_library(Alib "${A}")
add_library(Blib "${B}")
add_dependencies(Alib Generate)
add_dependencies(Blib Generate)

Tested on Ubuntu with Makefile generator:
  > cmake -H. -B_builds
  > cmake --build _builds -- -j4 # First build OK
  > touch generate.cmake
  > cmake --build _builds -- -j4 # Second build. Unexpected `Script run`

I'm expecting 1 message `Script run`, but I have 5 messages. If I modify 
`generate.cmake` script so it always write the file then everything 
works fine.

Ruslo

From bill.hoffman at kitware.com  Tue Oct  7 11:14:47 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 07 Oct 2014 11:14:47 -0400
Subject: [CMake] Parallel build with custom command
In-Reply-To: <5433F82E.4010202@yahoo.com>
References: <543385D8.1020804@yahoo.com> <5433F215.9040502@kitware.com>
 <5433F82E.4010202@yahoo.com>
Message-ID: <54340367.9010400@kitware.com>

On 10/7/2014 10:26 AM, Ruslan Baratov wrote:
>
> I'm expecting 1 message `Script run`, but I have 5 messages. If I modify
> `generate.cmake` script so it always write the file then everything
> works fine.
Ah OK, I see.  Your depend never gets up to date.  If you touch 
generate.cmake, and the file already exists, then generate.cmake will 
always be newer than the file.  And it will always try to run it.  So 
this is expected.

-Bill


From w.h.greene at gmail.com  Tue Oct  7 11:18:42 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Tue, 7 Oct 2014 11:18:42 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <5433EBBA.1050108@kitware.com>
References: <54308CFD.4010206@limitpoint.com>
 <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
 <5432AC81.5080903@kitware.com>
 <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>
 <5432FFA5.4040701@kitware.com>
 <CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>
 <5433EBBA.1050108@kitware.com>
Message-ID: <CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>

>cmake --build . --config Debug --target cmTestMain

Just as before, this re-compiles the cpp file and re-builds the lib but
does not re-link the exe.

>cmake --build . --config Debug --target cmTestMain -- -verbosity:diag >log
2>&1

I looked through this log file fairly carefully but, unfortunately, my
understanding of MSBuild is too
limited to say anything intelligent about it. I'll compress it and send it
on to you directly.

Thanks again for looking into this.

Bill

On Tue, Oct 7, 2014 at 9:33 AM, Brad King <brad.king at kitware.com> wrote:

> On Mon, Oct 6, 2014 at 5:47 PM, Bill Greene wrote:
> >>Another thing to try is to run cmake --build . and see if that works.
> > That appears to compile the lib cpp file and rebuild the library just
> fine
> > but it also doesn't re-link the main program.
>
> I also cannot reproduce this from Bill H's example.  Both the .lib and
> .exe file are rebuilt after touching only the lib .cpp file.
>
> Try building the main target directly after touching the lib .cpp file:
>
>  cmake --build . --config Debug --target cmTestMain
>
> If that reproduces the issue then we can ask msbuild for verbose logging
> info.  Touch the lib .cpp file again and then run:
>
>  cmake --build . --config Debug --target cmTestMain -- -verbosity:diag
> >log 2>&1
>
> The log file will be big and verbose.  If you see something stand out
> in it then please reply with a relevant subset of the log.  Otherwise
> please zip it up and send the log to me and Bill H. off-list since
> it will likely be too big to attach on-list.
>
> Thanks,
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141007/bc5d2938/attachment.html>

From ruslan_baratov at yahoo.com  Tue Oct  7 12:14:03 2014
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Tue, 07 Oct 2014 20:14:03 +0400
Subject: [CMake] Parallel build with custom command
In-Reply-To: <54340367.9010400@kitware.com>
References: <543385D8.1020804@yahoo.com> <5433F215.9040502@kitware.com>
 <5433F82E.4010202@yahoo.com> <54340367.9010400@kitware.com>
Message-ID: <5434114B.8010005@yahoo.com>

On 07-Oct-14 19:14, Bill Hoffman wrote:
> On 10/7/2014 10:26 AM, Ruslan Baratov wrote:
>>
>> I'm expecting 1 message `Script run`, but I have 5 messages. If I modify
>> `generate.cmake` script so it always write the file then everything
>> works fine.
> Ah OK, I see.  Your depend never gets up to date.  If you touch 
> generate.cmake, and the file already exists, then generate.cmake will 
> always be newer than the file.  And it will always try to run it.  So 
> this is expected.
>
Yes, that's why second file always modified. So assume I have a script 
that generates a lot of *.cpp files. I modify script so it only change 
one file, one file modified - one file recompiled. So what I trying to 
do is optimization that can be checked by rule: "if there is at least 
one file from OUTPUT list that is newer then any file from DEPENDS list 
- you don't need to rerun custom command".

So this optimization is not possible (?) custom command must modify all 
the files from OUTPUT list?

Ruslo

From brad.king at kitware.com  Tue Oct  7 12:47:25 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 07 Oct 2014 12:47:25 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>
References: <54308CFD.4010206@limitpoint.com>	<CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>	<5432AC81.5080903@kitware.com>	<CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>	<5432FFA5.4040701@kitware.com>	<CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>	<5433EBBA.1050108@kitware.com>
 <CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>
Message-ID: <5434191D.3080306@kitware.com>

On 10/07/2014 11:18 AM, Bill Greene wrote:
>>cmake --build . --config Debug --target cmTestMain -- -verbosity:diag >log 2>&1
> 
> I'll compress it and send it on to you directly.

In the log I see:

> Task "LIB" (TaskId:51)
>   Task Parameter:
>       Sources=
>           cmTestLib.dir\Debug\MySub.obj
>   ...
>   Outputs for C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTLIB\CMTESTLIB.DIR\DEBUG\MYSUB.OBJ: (TaskId:51)
>   	C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTLIB\DEBUG\CMTESTLIB.LIB (TaskId:51)
>   Inputs for C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTLIB\CMTESTLIB.DIR\DEBUG\MYSUB.OBJ: (TaskId:51)
>   	C:\WINDOWS\SYSTEM32\TZRES.DLL (TaskId:51)
>   	C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTLIB\CMTESTLIB.DIR\DEBUG\MYSUB.OBJ (TaskId:51)
>   Source compilation required: input C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTLIB\CMTESTLIB.DIR\DEBUG\MYSUB.OBJ is newer than output C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTLIB\DEBUG\CMTESTLIB.LIB. (TaskId:51)
>   c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\Lib.exe /OUT:"C:\temp\Projects\cmake_test_hoffman\cmTestLib\Debug\cmTestLib.lib" /NOLOGO cmTestLib.dir\Debug\MySub.obj (TaskId:51)
> Done executing task "LIB". (TaskId:51)

showing the correct re-run of the librarian.  Then:

> Task "Link" (TaskId:92)
>   Task Parameter:
>       Sources=
>           cmTestMain.dir\Debug\cmTestMain.exe.embed.manifest.res
>             ...
>           cmTestMain.dir\Debug\cmTestMain.obj
>             ...
>           C:\temp\Projects\cmake_test_hoffman\cmTestLib\Debug\cmTestLib.lib
>             ...
>   ...
>   Outputs for C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTLIB\DEBUG\CMTESTLIB.LIB|C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTMAIN\CMTESTMAIN.DIR\DEBUG\CMTESTMAIN.EXE.EMBED.MANIFEST.RES|C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTMAIN\CMTESTMAIN.DIR\DEBUG\CMTESTMAIN.OBJ: (TaskId:92)
>   	C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTMAIN\DEBUG\CMTESTMAIN.ILK (TaskId:92)
>   	C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTMAIN\DEBUG\CMTESTMAIN.EXE (TaskId:92)
>   	C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTMAIN\CMTESTMAIN.DIR\DEBUG\CMTESTMAIN.EXE.INTERMEDIATE.MANIFEST (TaskId:92)
>   	C:\TEMP\PROJECTS\CMAKE_TEST_HOFFMAN\CMTESTMAIN\DEBUG\CMTESTMAIN.PDB (TaskId:92)
>   All outputs are up-to-date. (TaskId:92)
> Done executing task "Link". (TaskId:92)

The list of Inputs is missing.  The list of outputs includes the input lib.
Clearly something goes wrong with the evaluation by msbuild.  When I run
the same case locally the corresponding location in the log correctly
shows the list of outputs and inputs, and then links.

What version of CMake have you been using to test?
Please try with 3.0.2 and with a nightly binary from:

 http://www.cmake.org/files/dev/?C=M;O=D

Thanks,
-Brad


From w.h.greene at gmail.com  Tue Oct  7 13:23:00 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Tue, 7 Oct 2014 13:23:00 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <5434191D.3080306@kitware.com>
References: <54308CFD.4010206@limitpoint.com>
 <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
 <5432AC81.5080903@kitware.com>
 <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>
 <5432FFA5.4040701@kitware.com>
 <CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>
 <5433EBBA.1050108@kitware.com>
 <CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>
 <5434191D.3080306@kitware.com>
Message-ID: <CABUrC_b_o3UcpBV4L4uwmKyWYrQzMCxfi1daUdTAvw-quC+XhQ@mail.gmail.com>

>What version of CMake have you been using to test?
I have been using 3.0.0 for all my tests.

I just downloaded and installed this version:
cmake version 3.0.20141006-g05d79
Then I removed the project directory created by the previous of
version of cmake and did a configure/generate (I've been using
cmake-gui for that step).

Unfortunately, I'm still seeing the library being rebuilt but not the exe.
This is true whether I build in VS or with
cmake --build . --config Debug --target cmTestMain

I'd be happy to send you another log file, if you like.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141007/923743f7/attachment.html>

From brad.king at kitware.com  Tue Oct  7 13:29:07 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 07 Oct 2014 13:29:07 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_b_o3UcpBV4L4uwmKyWYrQzMCxfi1daUdTAvw-quC+XhQ@mail.gmail.com>
References: <54308CFD.4010206@limitpoint.com>	<CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>	<5432AC81.5080903@kitware.com>	<CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>	<5432FFA5.4040701@kitware.com>	<CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>	<5433EBBA.1050108@kitware.com>	<CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>	<5434191D.3080306@kitware.com>
 <CABUrC_b_o3UcpBV4L4uwmKyWYrQzMCxfi1daUdTAvw-quC+XhQ@mail.gmail.com>
Message-ID: <543422E3.4040800@kitware.com>

On 10/07/2014 01:23 PM, Bill Greene wrote:
> I'm still seeing the library being rebuilt but not the exe.

Unfortunately I do not know where to send you from here.  I do not think
it is CMake bug.  The generated project is correct.  This is an extremely
common use case that seems to work in general.  CMake has nightly testing
of this use case that runs on all supported tools.

Generic ideas to try:

- Disable any antivirus tool you have running
- Re-install VS from scratch
- Try to reproducing this on another machine

-Brad


From bill.hoffman at kitware.com  Tue Oct  7 13:45:45 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 07 Oct 2014 13:45:45 -0400
Subject: [CMake] Early registration ends tomorrow for CMake and VTK/ParaView
 training courses in Carrboro
Message-ID: <543426C9.1010802@kitware.com>

The early registration deadline for our CMake and VTK/ParaView training 
courses in Carrboro ends tomorrow. Here is more information about the 
course:

http://training.kitware.fr/browse/72

Thanks.

-Bill

From bill.hoffman at kitware.com  Tue Oct  7 14:13:59 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 07 Oct 2014 14:13:59 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <543422E3.4040800@kitware.com>
References: <54308CFD.4010206@limitpoint.com>	<CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>	<5432AC81.5080903@kitware.com>	<CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>	<5432FFA5.4040701@kitware.com>	<CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>	<5433EBBA.1050108@kitware.com>	<CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>	<5434191D.3080306@kitware.com>
 <CABUrC_b_o3UcpBV4L4uwmKyWYrQzMCxfi1daUdTAvw-quC+XhQ@mail.gmail.com>
 <543422E3.4040800@kitware.com>
Message-ID: <54342D67.8010706@kitware.com>

On 10/7/2014 1:29 PM, Brad King wrote:
> Unfortunately I do not know where to send you from here.  I do not think
> it is CMake bug.  The generated project is correct.  This is an extremely
> common use case that seems to work in general.  CMake has nightly testing
> of this use case that runs on all supported tools.
>
> Generic ideas to try:
>
> - Disable any antivirus tool you have running
> - Re-install VS from scratch
> - Try to reproducing this on another machine
Could it be an odd version of msbuild on the machine?  Maybe one that 
does not match the IDE you are using?  Did you install the windows SDK 
or some other software that might have put a different msbuild on the 
machine?

-Bill


From brad.king at kitware.com  Tue Oct  7 14:34:25 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 07 Oct 2014 14:34:25 -0400
Subject: [CMake] Parallel build with custom command
In-Reply-To: <5434114B.8010005@yahoo.com>
References: <543385D8.1020804@yahoo.com> <5433F215.9040502@kitware.com>
 <5433F82E.4010202@yahoo.com> <54340367.9010400@kitware.com>
 <5434114B.8010005@yahoo.com>
Message-ID: <54343231.8040909@kitware.com>

On 10/07/2014 12:14 PM, Ruslan Baratov via CMake wrote:
> Yes, that's why second file always modified. So assume I have a script 
> that generates a lot of *.cpp files. I modify script so it only change 
> one file, one file modified - one file recompiled. So what I trying to 
> do is optimization that can be checked by rule: "if there is at least 
> one file from OUTPUT list that is newer then any file from DEPENDS list 
> - you don't need to rerun custom command".
> 
> So this optimization is not possible (?) custom command must modify all 
> the files from OUTPUT list?

Build systems will re-run a rule if any input is newer than any output.
One way to achieve what you want is to not list the .cpp files as outputs.
Instead just use some cpp-generated.stamp file as the output that you do
touch every time.  The .cpp files will be generated as side-effects, and
the rule will re-run only when the input changes regardless of whether
the generated .cpp files change.

FYI, there is an open issue for Ninja support of this case:

 http://www.cmake.org/Bug/view.php?id=14963

-Brad


From w.h.greene at gmail.com  Tue Oct  7 15:00:42 2014
From: w.h.greene at gmail.com (Bill Greene)
Date: Tue, 7 Oct 2014 15:00:42 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <54342D67.8010706@kitware.com>
References: <54308CFD.4010206@limitpoint.com>
 <CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>
 <5432AC81.5080903@kitware.com>
 <CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>
 <5432FFA5.4040701@kitware.com>
 <CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>
 <5433EBBA.1050108@kitware.com>
 <CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>
 <5434191D.3080306@kitware.com>
 <CABUrC_b_o3UcpBV4L4uwmKyWYrQzMCxfi1daUdTAvw-quC+XhQ@mail.gmail.com>
 <543422E3.4040800@kitware.com> <54342D67.8010706@kitware.com>
Message-ID: <CABUrC_b5m1=T9oz88mg-3qts3383R8jA4NxiLizft8jw=_1x7g@mail.gmail.com>

On Tue, Oct 7, 2014 at 2:13 PM, Bill Hoffman <bill.hoffman at kitware.com>
wrote:

> On 10/7/2014 1:29 PM, Brad King wrote:
>
>> Unfortunately I do not know where to send you from here.  I do not think
>> it is CMake bug.  The generated project is correct.  This is an extremely
>> common use case that seems to work in general.  CMake has nightly testing
>> of this use case that runs on all supported tools.
>>
>> Generic ideas to try:
>>
>> - Disable any antivirus tool you have running
>> - Re-install VS from scratch
>> - Try to reproducing this on another machine
>>
> Could it be an odd version of msbuild on the machine?  Maybe one that does
> not match the IDE you are using?  Did you install the windows SDK or some
> other software that might have put a different msbuild on the machine?
>
>
>
I see that I have (at least) two versions of MSBuild-- 4.0 and 12.0. I'm
not certain how either of them got there ;-(
I suspect that version 12 was installed when I installed/upgraded VS 2013.
I also have a couple of versions of the
windows SDK that I installed after installing VS 2010.

>From the verbose log file I generated earlier this morning, I can see this
line:
C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe -verbosity:diag
/p:VisualStudioVersion=10.0 cmTestMain/cmTestMain.vcxproj

As another experiment, I asked cmake to create a VS 2013 solution with
these same bits. After doing a verbose
build in that project, the log file shows:

C:/Program Files (x86)/MSBuild/12.0/bin/MSBuild.exe -verbosity:diag
/p:VisualStudioVersion=12.0 cmTestMain/cmTestMain.vcxproj

Both the VS 2010 and 2013 solutions show the same exe/lib dependency
problem. So if the culprit is MSBuild,
the problem is quite subtle.

At this point, I'm not sure we know much more than that MS has an extremely
complex and idiosyncratic build system;
something we probably knew before.

Thanks to both of you for taking the time to investigate.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141007/ff1e75a4/attachment-0001.html>

From bill.hoffman at kitware.com  Tue Oct  7 21:44:59 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 07 Oct 2014 21:44:59 -0400
Subject: [CMake] Main program not getting rebuilt when library changes.
In-Reply-To: <CABUrC_b5m1=T9oz88mg-3qts3383R8jA4NxiLizft8jw=_1x7g@mail.gmail.com>
References: <54308CFD.4010206@limitpoint.com>	<CABUrC_bofYyKpjd82iri2rwUaopwWCxKu93GqDXeKDSaYg8ySg@mail.gmail.com>	<5432AC81.5080903@kitware.com>	<CABUrC_Y1VVrf224AKW=OWuRH0=KiZ6vUPbKPUd4Q7Pn3f=-UVQ@mail.gmail.com>	<5432FFA5.4040701@kitware.com>	<CABUrC_beLKNpossT2UQmvLBQo-_jobR=dVNop1--6gbRWv2BiQ@mail.gmail.com>	<5433EBBA.1050108@kitware.com>	<CABUrC_bzkZ0Lr9RY-vdnnp3guoes2mdf5Aqrk8tOpz7FW6GsSg@mail.gmail.com>	<5434191D.3080306@kitware.com>	<CABUrC_b_o3UcpBV4L4uwmKyWYrQzMCxfi1daUdTAvw-quC+XhQ@mail.gmail.com>	<543422E3.4040800@kitware.com>	<54342D67.8010706@kitware.com>
 <CABUrC_b5m1=T9oz88mg-3qts3383R8jA4NxiLizft8jw=_1x7g@mail.gmail.com>
Message-ID: <5434971B.4090508@kitware.com>

On 10/7/2014 3:00 PM, Bill Greene wrote:
>
> At this point, I'm not sure we know much more than that MS has an
> extremely complex and idiosyncratic build system;
> something we probably knew before.
>
> Thanks to both of you for taking the time to investigate.
Something is very strange here.  I would recommend you install VS on a 
different computer and see if you can reproduce.  If this did not work 
consistently lots of folks would complain about it and the cmake test 
cases would be failing all over the place.  There is something very 
"special" about your setup...

-Bill


From ruslan_baratov at yahoo.com  Wed Oct  8 07:22:38 2014
From: ruslan_baratov at yahoo.com (Ruslan Baratov)
Date: Wed, 08 Oct 2014 15:22:38 +0400
Subject: [CMake] Parallel build with custom command
In-Reply-To: <54343231.8040909@kitware.com>
References: <543385D8.1020804@yahoo.com> <5433F215.9040502@kitware.com>
 <5433F82E.4010202@yahoo.com> <54340367.9010400@kitware.com>
 <5434114B.8010005@yahoo.com> <54343231.8040909@kitware.com>
Message-ID: <54351E7E.4040208@yahoo.com>

On 07-Oct-14 22:34, Brad King wrote:
> On 10/07/2014 12:14 PM, Ruslan Baratov via CMake wrote:
>> Yes, that's why second file always modified. So assume I have a script
>> that generates a lot of *.cpp files. I modify script so it only change
>> one file, one file modified - one file recompiled. So what I trying to
>> do is optimization that can be checked by rule: "if there is at least
>> one file from OUTPUT list that is newer then any file from DEPENDS list
>> - you don't need to rerun custom command".
>>
>> So this optimization is not possible (?) custom command must modify all
>> the files from OUTPUT list?
> Build systems will re-run a rule if any input is newer than any output.
Thanks! It's pretty clear and simple statement (but important one). What 
do you think about having it in documentation?
> One way to achieve what you want is to not list the .cpp files as outputs.
> Instead just use some cpp-generated.stamp file as the output that you do
> touch every time.  The .cpp files will be generated as side-effects, and
> the rule will re-run only when the input changes regardless of whether
> the generated .cpp files change.
Nice trick, but there is one catch - if you remove generated file 
(accidentially or on purpose) then nobody will rebuild it, since build 
system do not know what target exactly (custom command to be precise) 
responsible for it.
>
> FYI, there is an open issue for Ninja support of this case:
>
>   http://www.cmake.org/Bug/view.php?id=14963
Good to know, thanks.

Ruslo

From paul at mad-scientist.net  Wed Oct  8 12:15:46 2014
From: paul at mad-scientist.net (Paul Smith)
Date: Wed, 08 Oct 2014 12:15:46 -0400
Subject: [CMake] Forcing colorization of output from cmake
In-Reply-To: <1367417913.4101.127.camel@pdsdesk>
References: <1367417913.4101.127.camel@pdsdesk>
Message-ID: <1412784946.29340.123.camel@mad-scientist.net>

On Wed, 2013-05-01 at 10:18 -0400, Paul Smith wrote:
> I'm wondering if there's any way to force the output from cmake (using a
> unix makefile generator for example) to be colorized, even if stdout
> doesn't appear to be a TTY.
> 
> Is that possible?  Some extra switch to cmake_echo_color?

I sent this a year and a half ago or so, but no response.  Reading the
code it doesn't appear to be possible.  I tried forcing the --switch=ON
flag in the cmake_echo_color command, but that doesn't help.

This is an important issue because newer versions of GNU make provide a
way to avoid having output from multiple jobs jumbled together during
parallel builds, which is extremely helpful; however obviously this
requires that the output be redirected to a temporary file rather than
displayed directly on the terminal.  Making use of this feature means
that you lose colorized output from cmake makefiles.

However, GNU make (4.1) provides an environment variable which tells its
children whether IT was started with a terminal for stdout/stderr:
MAKE_TERMOUT will be non-empty if make believes that its output will
eventually be dumped to stdout: ditto for MAKE_TERMERR.

So I thought about adding this into my environment:

  export COLOR='$(if $(MAKE_TERMOUT),YES)'

and that does work to set "--switch=YES" when make thinks that it's
output is stdout, but that doesn't help because cmake ignores this
setting.  I traced the code through and found that at the end we simply
run isatty() on the output stream, and if that returns false we never
colorize and there's no option to manage this.

Compare this to other tools such as GCC, where they allow you to force
colorization always, regardless of the TTY settings.

Maybe we could add another valid value to --switch, like --switch=FORCE
which would always colorize.

There are a number of layers between where cmake parses the command line
and where it makes the decision on whether to colorize or not.  The best
option seems to be to add another flag to the "color" bitflag variable
that forces colorization always.  The AssumeTTY flag kind of does this,
but currently it's only enabled on Windows and doesn't quite fit the
bill: its use and meaning would need to be tweaked I think.


From nico.schloemer at gmail.com  Wed Oct  8 12:40:53 2014
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Wed, 8 Oct 2014 18:40:53 +0200
Subject: [CMake] CMake Error: install(EXPORT "A" ...) includes target "b"
 which requires target "c" that is not in this export set,
 but x times in others.
Message-ID: <CAK6Z60fMQEYRDLJz15LXPC_arRUiw5HbGpO9MVpA1uc0nMHUCg@mail.gmail.com>

Hi all,

in on CMake project of mine, all seems to configure fine until the
very end where I'm getting error messages like
```
CMake Error: install(EXPORT "A" ...) includes target "b" which
requires target "c" that is not in this export set, but x times in
others.
```
First of all, CMake does seem to create all files necessary for
building the project, since that goes without error. Hence, I'm not
really sure CMake yells at me.
Second, I don't really understand the message. Indeed, I have a couple
of export sets in my project, and the libraries there in depend on
each other. Why the target "c" need to be in the same export set as
"b"?

This is with CMake 2.8.12.2.

Cheers,
Nico

From brad.king at kitware.com  Wed Oct  8 12:55:20 2014
From: brad.king at kitware.com (Brad King)
Date: Wed, 08 Oct 2014 12:55:20 -0400
Subject: [CMake] Forcing colorization of output from cmake
In-Reply-To: <1412784946.29340.123.camel@mad-scientist.net>
References: <1367417913.4101.127.camel@pdsdesk>
 <1412784946.29340.123.camel@mad-scientist.net>
Message-ID: <54356C78.7060501@kitware.com>

On 10/08/2014 12:15 PM, Paul Smith wrote:
> Maybe we could add another valid value to --switch, like --switch=FORCE
> which would always colorize.
[snip]
> The best option seems to be to add another flag to the "color" bitflag
> variable that forces colorization always.

Yes, I think both of the above make sense.  If you want to work on
it please read CONTRIBUTING.rst from the top of our source tree
in Git ( http://cmake.org/cmake.git ) and come to the developers
list with a proposal:

 http://www.cmake.org/mailman/listinfo/cmake-developers

Thanks,
-Brad


From a.neundorf-work at gmx.net  Wed Oct  8 15:48:01 2014
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Wed, 08 Oct 2014 21:48:01 +0200
Subject: [CMake] CMake Error: install(EXPORT "A" ...) includes target
	"b" which requires target "c" that is not in this export set,
	but x times in others.
In-Reply-To: <CAK6Z60fMQEYRDLJz15LXPC_arRUiw5HbGpO9MVpA1uc0nMHUCg@mail.gmail.com>
References: <CAK6Z60fMQEYRDLJz15LXPC_arRUiw5HbGpO9MVpA1uc0nMHUCg@mail.gmail.com>
Message-ID: <15884420.OjgmOI0GUf@tuxedo.neundorf.net>

On Wednesday, October 08, 2014 18:40:53 Nico Schl?mer wrote:
> Hi all,
> 
> in on CMake project of mine, all seems to configure fine until the
> very end where I'm getting error messages like
> ```
> CMake Error: install(EXPORT "A" ...) includes target "b" which
> requires target "c" that is not in this export set, but x times in
> others.
> ```
> First of all, CMake does seem to create all files necessary for
> building the project, since that goes without error. Hence, I'm not
> really sure CMake yells at me.
> Second, I don't really understand the message. Indeed, I have a couple
> of export sets in my project, and the libraries there in depend on
> each other. Why the target "c" need to be in the same export set as
> "b"?

It doesn't.
If target c depends on target b, and target c is exported, cmake checks that 
target b is exported too. This is necessary so cmake can put the name of the 
exported "b" library into the dependencies of c.
This is possible if b is exported in the same export set as c, or if b is in a 
different export set, but only in one. Then cmake can use the name of the 
exported target b as it is used in the other export set.
If b is exported in multiple export sets, each of these export sets can use a 
different namespace, and it is not clear which of these different names for b 
should be used as dependency for c.
If b is in only one export set, it will be used with the namespace as used 
there in the list of dependencies of c.

Alex


From mohammedrashadkm at gmail.com  Thu Oct  9 03:49:31 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Thu, 9 Oct 2014 13:19:31 +0530
Subject: [CMake] CTEST_CUSTOM_WARNING_EXCEPTION does not ignore
	vcl_deprecated_header
Message-ID: <CANNqv9c+LGQ+D+ssp22Yx05Du2BEG96zE6eBKwfZynf5nQyYdA@mail.gmail.com>

Hi,

Below is from CTestCustom.cmake to ignore warning from
vcl_deperacated_header.h

set(CTEST_CUSTOM_WARNING_EXCEPTION
  ${CTEST_CUSTOM_WARNING_EXCEPTION}
  "vcl_deprecated_header")

here is the dashboard submission -
http://dash.orfeo-toolbox.org/viewBuildError.php?type=1&buildid=159898

here is the ctest script -
http://hg.orfeo-toolbox.org/OTB-DevUtils/file/dffb9a74dd71/Config/pc-christophe/pc-christophe-OTB-Nightly.cmake

Note that I had  removed -Wno-cpp from CMAKE_CXX_FLAGS to test
CTestCustom.cmake in my local copy.

Can anyone explain why this behaviour?

-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141009/ac1f8771/attachment.html>

From jkoregaokar at hotmail.com  Thu Oct  9 08:06:29 2014
From: jkoregaokar at hotmail.com (jay75)
Date: Thu, 9 Oct 2014 05:06:29 -0700 (PDT)
Subject: [CMake] 2 libs stuck together !
Message-ID: <1412856389178-7588712.post@n2.nabble.com>

i am working on ros indigo, ubuntu 14.04 trusty, opencv 2.4.9

i get this message:
/usr/bin/ld: cannot find -lopencv_calib3dlibpthread

now, "libpthread.so.0"  and "libopencv_calib3d.so" are two separate libs in
"/usr/lib/x86_64-linux-gnu/", which i have added successfully to my
"link_libraries". what am i doing wrong? here is my cmakelists.txt :
cmake_minimum_required(VERSION 2.8.3)
project(hal_main)

find_package(cmake_modules REQUIRED)
find_package(Eigen REQUIRED)
find_package(Boost REQUIRED thread date_time system filesystem
program_options python )

## Find catkin macros and libraries
## if COMPONENTS list like find_package(catkin REQUIRED COMPONENTS xyz)
## is used, also find other catkin packages
find_package(catkin REQUIRED COMPONENTS
  actionlib
  actionlib_msgs
  message_generation
  roscpp
  rospy
  std_msgs
  genmsg
  visualization_msgs 
  clam_controller 
  clam_msgs
  pcl_ros
  cv_bridge
  eigen_conversions
  moveit_msgs
  geometry_msgs
  moveit_ros_planning 
  moveit_ros_planning_interface
  tf
  tf_conversions
  moveit_simple_grasps
  cmake_modules
  moveit_core 
  # eigen_conversions
)



find_package(OpenCV REQUIRED )
find_package(OpenCV 2 REQUIRED )
#find_package(OpenCV 2 REQUIRED COMPONENTS calib3dlibpthread)

include_directories(${EIGEN_INCLUDE_DIRS})

add_definitions(${EIGEN_DEFINITIONS})

#SET( CMAKE_MODULE_PATH "/usr/share/cmake-2.8/Modules/" )
#set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
"${CMAKE_SOURCE_DIR}/share/cmake_modules/cmake/Modules/")

find_package(MySQL REQUIRED COMPONENTS libmysqlcppconn.so.7.1.1.3)
include_directories(${MYSQL_INCLUDE_DIRS})
add_definitions(${MYSQL_DEFINITIONS})
#link_directories(/usr/lib/mysql/plugin/${MYSQL_LIBRARY_DIRS})



#find_package(OpenCV2 REQUIRED)
#find_package(mysql REQUIRED)
## System dependencies are found with CMake's conventions
# find_package(Boost REQUIRED COMPONENTS system)


## Uncomment this if the package has a setup.py. This macro ensures
## modules and global scripts declared therein get installed
## See http://ros.org/doc/api/catkin/html/user_guide/setup_dot_py.html
# catkin_python_setup()

################################################
## Declare ROS messages, services and actions ##
################################################

## To declare and build messages, services or actions from within this
## package, follow these steps:
## * Let MSG_DEP_SET be the set of packages whose message types you use in
##   your messages/services/actions (e.g. std_msgs, actionlib_msgs, ...).
## * In the file package.xml:
##   * add a build_depend and a run_depend tag for each package in
MSG_DEP_SET
##   * If MSG_DEP_SET isn't empty the following dependencies might have been
##     pulled in transitively but can be declared for certainty nonetheless:
##     * add a build_depend tag for "message_generation"
##     * add a run_depend tag for "message_runtime"
## * In this file (CMakeLists.txt):
##   * add "message_generation" and every package in MSG_DEP_SET to
     #find_package(catkin REQUIRED COMPONENTS actionlib_msgs geometry_msgs
moveit_msgs )
##   * add "message_runtime" and every package in MSG_DEP_SET to
##     catkin_package(CATKIN_DEPENDS ...)
##   * uncomment the add_*_files sections below as needed
##     and list every .msg/.srv/.action file to be processed
##   * uncomment the generate_messages entry below
##   * add every package in MSG_DEP_SET to generate_messages(DEPENDENCIES
...)

## Generate messages in the 'msg' folder
 add_message_files(
   FILES
   instr_set_arm.msg
   instr_set_legs.msg
   object.msg
 )

## Generate services in the 'srv' folder
# add_service_files(
#   FILES
#   Service1.srv
#   Service2.srv
# )

## Generate actions in the 'action' folder
 add_action_files(
   FILES
   arminstr.action
   leginstr.action
   objrecog_posit.action
   sendcommand.action

 )

## Generate added messages and services with any dependencies listed here
 generate_messages(
   DEPENDENCIES
   actionlib_msgs
   std_msgs
   geometry_msgs
   moveit_msgs
   
 )

 catkin_package(
  CATKIN_DEPENDS
  actionlib
  actionlib_msgs
  message_generation
  roscpp
  rospy
  std_msgs
  genmsg
  visualization_msgs 
  clam_controller 
  clam_msgs
  pcl_ros
  cv_bridge
  eigen_conversions 
  moveit_msgs
  geometry_msgs
  moveit_ros_planning 
  moveit_ros_planning_interface
  tf
  tf_conversions
  moveit_simple_grasps
  moveit_core
#  INCLUDE_DIRS include
)
###################################
## catkin specific configuration ##
###################################
## The catkin_package macro generates cmake config files for your package
## Declare things to be passed to dependent projects
## INCLUDE_DIRS: include/hal_main
## LIBRARIES: libraries you create in this project that dependent projects
also need
## CATKIN_DEPENDS: catkin_packages dependent projects also need
## DEPENDS: system dependencies of this project that dependent projects also
need
catkin_package(
#  INCLUDE_DIRS include include/hal_main
${CMAKE_INSTALL_PREFIX}/include/hal_main
#  LIBRARIES hal_main
#   CATKIN_DEPENDS actionlib actionlib_msgs message_generation roscpp rospy
std_msgs message_runtime geometry_msgs moveit_msgs 
#  DEPENDS 
)

###########
## Build ##
###########

## Specify additional locations of header files
## Your package locations should be listed before other locations
# include_directories(include)
include_directories( ${catkin_INCLUDE_DIRS})
include_directories( /usr/include/mysql ${MYSQL_INCLUDE_DIRS})
add_definitions(${MYSQL_DEFINITIONS})
link_directories(/usr/lib )
#${MYSQL_LIBRARY_DIRS}
include_directories(SYSTEM ${Boost_INCLUDE_DIR} ${EIGEN_INCLUDE_DIRS})

include_directories( ${OpenCV_INCLUDE_DIRS} /usr/include/opencv 
/usr/include/opencv2 )
add_definitions(${OpenCV_DEFINITIONS})
link_directories(${OpenCV_DIRECTORIES}   )
link_libraries(${OpenCV_LIBS}libpthread.so.0  libopencv_calib3d.so)
#link_libraries(${OpenCV_LIBS}libpthread.so.0 libopencv_calib3d.so)

#include_directories( ${OpenCV 2_INCLUDE_DIRS}  /usr/include/opencv2 )
#add_definitions(${OpenCV 2_DEFINITIONS})
#link_directories(/usr/local/lib/ )
#link_libraries(${OpenCV 2_LIBRARIES} )

## Declare a cpp library
# add_library(hal_main
#   src/${PROJECT_NAME}/hal_main.cpp
# )

## Declare a cpp executable
add_executable(command_action_client src/commandclient.cpp)
add_dependencies(command_action_client hal_main_generate_messages_cpp)
target_link_libraries(command_action_client ${catkin_LIBRARIES})

#add_executable(command_action_server src/commandserver.cpp)
#add_dependencies(command_action_server hal_main_generate_messages_cpp) 
#target_link_libraries(command_action_server ${MySQL_LIBRARIES}
${catkin_LIBRARIES})

if(MySQL_FOUND)
    include_directories(${MySQL_INCLUDE_DIRS}) 
    add_executable(command_action_server src/commandserver.cpp)
    add_dependencies(command_action_server hal_main_generate_messages_cpp) 
    target_link_libraries(command_action_server ${MySQL_LIBRARIES})                                                                                                                                                                                                                           
endif()

add_executable(arms_action_server src/arms_server.cpp)
add_dependencies(arms_action_server hal_main_generate_messages_cpp)
target_link_libraries(arms_action_server ${catkin_LIBRARIES})

if(OpenCV_FOUND)
  include_directories(${OpenCV_INCLUDE_DIRS}) 
  add_executable(object_recog_pos_server src/obj_recog_posit_server.cpp)
  add_dependencies(object_recog_pos_server hal_main_generate_messages_cpp)
  target_link_libraries(object_recog_pos_server ${OpenCV_LIBS} )
endif()

## Add cmake target dependencies of the executable/library
## as an example, message headers may need to be generated before nodes

## Specify libraries to link a library or executable target against
#target_link_libraries(tf_listener ${catkin_LIBRARIES})

#############
## Install ##
#############

# all install targets should use catkin DESTINATION variables
# See http://ros.org/doc/api/catkin/html/adv_user_guide/variables.html

## Mark executable scripts (Python etc.) for installation
## in contrast to setup.py, you can choose the destination
# install(PROGRAMS
#   scripts/my_python_script
#   DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
# )

## Mark executables and/or libraries for installation
# install(TARGETS hal_main hal_main_node
#   ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
#   LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
#   RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
# )

## Mark cpp header files for installation
# install(DIRECTORY include/${PROJECT_NAME}/
#   DESTINATION ${CATKIN_PACKAGE_INCLUDE_DESTINATION}
#   FILES_MATCHING PATTERN "*.h"
#   PATTERN ".svn" EXCLUDE
# )

## Mark other files for installation (e.g. launch and bag files, etc.)
# install(FILES
#   # myfile1
#   # myfile2
#   DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
# )

#############
## Testing ##
#############

## Add gtest based cpp test target and link libraries
# catkin_add_gtest(${PROJECT_NAME}-test test/test_hal_main.cpp)
# if(TARGET ${PROJECT_NAME}-test)
#   target_link_libraries(${PROJECT_NAME}-test ${PROJECT_NAME})
# endif()

## Add folders to be run by python nosetests
# catkin_add_nosetests(test)




--
View this message in context: http://cmake.3232098.n2.nabble.com/2-libs-stuck-together-tp7588712.html
Sent from the CMake mailing list archive at Nabble.com.

From eric.noulard at gmail.com  Thu Oct  9 11:00:08 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 9 Oct 2014 17:00:08 +0200
Subject: [CMake] Call for volunteer for CPackRPM, CPackDeb maintenance.
Message-ID: <CAPASGLpvhUBN-8uRH9fS9o38WnBUtHmGJF6_HXdaTnbRkwHSQA@mail.gmail.com>

Hi everybody,

This message is an open request to find volunteer maintainers for CPackRPM
and CPackDeb
which were my main contributions to CPack (CPackDeb was initially
contributed by Mathieu).

I have 21 Mantis tickets (http://public.kitware.com/Bug) assigned to me I
will soon
unassign them or "transfer" them to volunteering people.

I did contribute to CMake/CPack for some time (~2007) now but my "CMake
free time"
is now too small to be able to test and integrate contribution/patches to
CPackDeb and
CPackRPM.

I will be listening to the mailing lists as usual but one shall not count
on a timely responsiveness
from me. I shall say that this is not a lack of interest but a clear lack
of time.
I do continue to use CMake/CPack/CTest on a daily basis but cannot find
enough time
to contribute anymore.

I'll try my best to help the volunteer(s) to take over. People interested
may answer here
and/or send me direct e-mail if they find it necessary.

I shall say that the CMake developer community including Kitware people
(off course)
were (and are) very helpful and always kind to handle my cmake/cpack
contribution.

-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141009/0fce8b92/attachment.html>

From Lucas.Pettey at engilitycorp.com  Thu Oct  9 11:48:34 2014
From: Lucas.Pettey at engilitycorp.com (Lucas.Pettey at engilitycorp.com)
Date: Thu, 9 Oct 2014 15:48:34 +0000
Subject: [CMake] CMake configuration hangs with TAU on Mac OSX
Message-ID: <45BF0169B950CD4A97DC5223BB2B44B30818B9DC@VACH-MX1.EGL.ENGILITYCORP.COM>

Hello,

I cannot seem to get CMake to work with TAU on a Mac. I have tried Mountain Lion and Mavericks.

I have tried "CC=tau_cc.sh CXX=tau_cxx.sh ccmake" but the configuration step hangs at 6%.

I know my tau installation is working because it was able to build the program using a handwritten makefile.

I know the CMake files are good because the program will configure, generate and build using CMake and the gcc compilers.

Any ides?


Lucas Pettey, PhD
HPCMP PETTT EQM CTA Lead
ERDC-DSRC OnSite
Vicksburg, MS
512-297-9833 Mobile (preferred)
601-634-2980 Office
lucas.pettey at engilitycorp.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141009/e0f2eabb/attachment.html>

From jmerkow at gmail.com  Thu Oct  9 20:14:33 2014
From: jmerkow at gmail.com (jmerkow)
Date: Thu, 9 Oct 2014 17:14:33 -0700 (PDT)
Subject: [CMake] file(UPLOAD what does it support?
Message-ID: <1412900073098-7588715.post@n2.nabble.com>

Hello,

I am trying to use file(UPLOAD.  The documentation [1] is a little lacking
on what types of uploading it supports. 

Is there a wiki or example page somewhere that goes over whats supported and
how to use it?

-Jameson

[1] http://www.cmake.org/cmake/help/v3.0/command/file.html?highlight=UPLOAD



--
View this message in context: http://cmake.3232098.n2.nabble.com/file-UPLOAD-what-does-it-support-tp7588715.html
Sent from the CMake mailing list archive at Nabble.com.

From DLRdave at aol.com  Thu Oct  9 21:45:11 2014
From: DLRdave at aol.com (David Cole)
Date: Thu, 9 Oct 2014 21:45:11 -0400
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <1412900073098-7588715.post@n2.nabble.com>
References: <1412900073098-7588715.post@n2.nabble.com>
Message-ID: <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>

The documentation might be a little sparse, but file UPLOAD uses curl
in its implementation. So whatever protocols curl supports for
uploading to a URL should be supported by file UPLOAD, too. I know for
a fact it works with http, https and ftp. Is there some other protocol
you are trying to use that isn't working?

HTH,
David C.


On Thu, Oct 9, 2014 at 8:14 PM, jmerkow <jmerkow at gmail.com> wrote:
> Hello,
>
> I am trying to use file(UPLOAD.  The documentation [1] is a little lacking
> on what types of uploading it supports.
>
> Is there a wiki or example page somewhere that goes over whats supported and
> how to use it?
>
> -Jameson
>
> [1] http://www.cmake.org/cmake/help/v3.0/command/file.html?highlight=UPLOAD
>
>
>
> --
> View this message in context: http://cmake.3232098.n2.nabble.com/file-UPLOAD-what-does-it-support-tp7588715.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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

From verbeek at servicerobotics.eu  Fri Oct 10 05:48:16 2014
From: verbeek at servicerobotics.eu (Dr. Christian Verbeek)
Date: Fri, 10 Oct 2014 11:48:16 +0200
Subject: [CMake] Quoting and Escapes
Message-ID: <5437AB60.2080007@servicerobotics.eu>

Dear cmake users,

I am using cmake 3.0.2 on WIndows.

INCLUDE( C:/Program Files (x86)/somepath )
->  include called with wrong number of arguments.  include() only takes 
one file.
Ok. Because of the white spaces.

INCLUDE( "C:/Program Files (x86)/somepath" )
->  include could not find load file: somepath
Ok. Probably because of the ().

INCLUDE( "C:/Program Files \(x86\)/somepath" )
->  include could not find load file: somepath
Still the same error even though () had been escaped.

INCLUDE( C:/Program\ Files\ \(x86\)/somepath )
->  include could not find load file: somepath
Still the same error. Confusion reached it's maximum.

Does anyone know how to escape the () and also deal with the white space?

Regards
Christian

-- 
___________________________________________________________________________
REC GmbH                                   http://www.roboparts.de
Dr. Christian Verbeek                      http://www.servicerobotics.eu
Robert-Koch-Str. 2, 82152 Planegg          http://wiki.openrobotino.org
                                            http://forum.openrobotino.org
Tel:    +49 89 85689672
Fax:    +49 89 85902327
Mobile: +49 160 7056589
e-mail: verbeek at servicerobotics.eu

Gesch?ftsf?hrer: Dr. Christian Verbeek
Registergericht: AG M?nchen (HRB 154463)
___________________________________________________________________________


From nilsgladitz at gmail.com  Fri Oct 10 06:07:22 2014
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 10 Oct 2014 12:07:22 +0200
Subject: [CMake] Quoting and Escapes
In-Reply-To: <5437AB60.2080007@servicerobotics.eu>
References: <5437AB60.2080007@servicerobotics.eu>
Message-ID: <5437AFDA.1070202@gmail.com>

On 10/10/2014 11:48 AM, Dr. Christian Verbeek wrote:

> INCLUDE( "C:/Program Files (x86)/somepath" )
> ->  include could not find load file: somepath

This one should work as-is.
Is "somepath" an existing regular CMake script (text file)?

Nils

From petr.kmoch at gmail.com  Fri Oct 10 07:24:00 2014
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Fri, 10 Oct 2014 13:24:00 +0200
Subject: [CMake] Quoting and Escapes
In-Reply-To: <5437AFDA.1070202@gmail.com>
References: <5437AB60.2080007@servicerobotics.eu> <5437AFDA.1070202@gmail.com>
Message-ID: <CAKohaZcyXJRpXWV9OA5jTgAwDCVTqekpMhgUT355VFru0fvU+A@mail.gmail.com>

Hi Christian.

Were you perhaps looking for

INCLUDE_DIRECTORIES("C:/Program Files (x86)/somepath")

instead?

Petr

On Fri, Oct 10, 2014 at 12:07 PM, Nils Gladitz <nilsgladitz at gmail.com>
wrote:

> On 10/10/2014 11:48 AM, Dr. Christian Verbeek wrote:
>
>  INCLUDE( "C:/Program Files (x86)/somepath" )
>> ->  include could not find load file: somepath
>>
>
> This one should work as-is.
> Is "somepath" an existing regular CMake script (text file)?
>
> Nils
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141010/27c0ae41/attachment.html>

From sbv1976 at gmail.com  Fri Oct 10 12:43:53 2014
From: sbv1976 at gmail.com (Steven Velez)
Date: Fri, 10 Oct 2014 12:43:53 -0400
Subject: [CMake] VERSION and SOVERSION target properties on OS X
Message-ID: <CAEiokwQFzDRF-01N-CjB6ghYdmhhqNvSsiXcdKz+ftDfwma_kg@mail.gmail.com>

Forgive me if this question has been answered before but with CMAKE 2.8.12
(I believe) xcode builds on OS X started generating shared libraries
decorated with the "VERSION" target property and symlinked by a bare dylib
name and one decorated with the SOVERSION.

I understand this is common practice on many unixen, but it is complicating
our deployment and update logic (not cpack, sorry to say).

Our application is fairly self-contained, so we would like to continue
generating only those bare-named dylibs, but we need to keep the SOVERSION
set to that the embedded "compatibility version" remains how we want it.

I have not found a combination of values to these properties that does what
I would like, so I was wondering if there was a way to get the old
behavior.... perhaps with a policy or something?

If there isn't a way to do it now, would there be an acceptable way to
specify this behavior that would be accepted as a patch?

Thanks,
Steven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141010/e340cc97/attachment-0001.html>

From mohammedrashadkm at gmail.com  Sat Oct 11 09:47:30 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Sat, 11 Oct 2014 19:17:30 +0530
Subject: [CMake] CTest Custom warning exception in CTestCustom.cmake.in
Message-ID: <CANNqv9dTWUe6XAj=2-xJoYzktY5BNt2duCtjZeM2CTEa8Fn9-g@mail.gmail.com>

Hi all,

Can anyone explain me how to filter out the below warning from dashboard?

warning: #warning "deprecated"
...../vcl_deprecated_header.h:10:3: warning: #warning "deprecated" [-Wcpp]
 # warning "deprecated"

So far I tried having below in CTestCustom.cmake

set(CTEST_CUSTOM_WARNING_EXCEPTION
  ${CTEST_CUSTOM_WARNING_EXCEPTION}
  ".*vcl_deprecated_header.*warning.*"
  "vcl_deprecated_header"
...
)



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141011/e0209314/attachment.html>

From houssen at ipgp.fr  Sat Oct 11 13:05:09 2014
From: houssen at ipgp.fr (houssen)
Date: Sat, 11 Oct 2014 19:05:09 +0200
Subject: [CMake] =?utf-8?q?What_is_the_CMake_equivalent_for_autotools_=22m?=
 =?utf-8?q?ake_dist=22_=3F?=
Message-ID: <0133c7a456fcaaac6ebdf01fd85d7ce5@imap.ipgp.fr>

Hello,

What is the CMake equivalent for autotools "make dist" ?
By autotools "make dist", I mean a way to wrap all sources and test 
files needed to build and test the package and / or to be ready for dev.

I googled this question : I heard about CPack (and "make package"), 
but, I am not sure to understand if this is designed to answer the same 
question.
Using CPack and "make package", I get a tar.gz that contains the 
executable (the binary in a bin directory) but without the source : this 
is not what I want as sources are missing (the tar.gz is not ready for 
dev).

Is this the expected behavior ? ("make package" is intended to provide 
only binaries to be installed ? Not the source / test files ?)
Did I miss something ? Did I forgot something in the CMakeLists.txt ?
I am supposed to tar the root directory (= project directory containing 
hello.cpp and CMakeLists.txt) after I suppressed all BUILD directories 
that could have been built previously ?

FH
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141011/43f505fe/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.cpp
Type: text/x-c
Size: 139 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141011/43f505fe/attachment.bin>

From iosif.neitzke+cmake at gmail.com  Sat Oct 11 14:03:15 2014
From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke)
Date: Sat, 11 Oct 2014 13:03:15 -0500
Subject: [CMake] What is the CMake equivalent for autotools "make dist" ?
In-Reply-To: <0133c7a456fcaaac6ebdf01fd85d7ce5@imap.ipgp.fr>
References: <0133c7a456fcaaac6ebdf01fd85d7ce5@imap.ipgp.fr>
Message-ID: <CAGyo1oxat_B3VduqMo8FPEVXxsRW41_pmfCNOhPyU7cqTxUb8A@mail.gmail.com>

With CPack enabled, "make help" will show all the valid targets.  The
"package_source" target should be one of those targets.

A simple project on Linux built with "make package_source" gives me:

${CMAKE_BINARY_DIR}/_CPack_Packages/Linux-Source/{TZ,TGZ,TBZ2}/CPack_Example-0.1.1-Linux.tar.{bz2,gz,Z}

All three files contain all the source files in my
${CMAKE_SOURCE_DIR}.  (Including CMakeLists.txt)



On Sat, Oct 11, 2014 at 12:05 PM, houssen <houssen at ipgp.fr> wrote:
> Hello,
>
> What is the CMake equivalent for autotools "make dist" ?
> By autotools "make dist", I mean a way to wrap all sources and test files
> needed to build and test the package and / or to be ready for dev.
>
> I googled this question : I heard about CPack (and "make package"), but, I
> am not sure to understand if this is designed to answer the same question.
> Using CPack and "make package", I get a tar.gz that contains the executable
> (the binary in a bin directory) but without the source : this is not what I
> want as sources are missing (the tar.gz is not ready for dev).
>
> Is this the expected behavior ? ("make package" is intended to provide only
> binaries to be installed ? Not the source / test files ?)
> Did I miss something ? Did I forgot something in the CMakeLists.txt ?
> I am supposed to tar the root directory (= project directory containing
> hello.cpp and CMakeLists.txt) after I suppressed all BUILD directories that
> could have been built previously ?
>
> FH
> --
>
> 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

From DLRdave at aol.com  Sat Oct 11 19:01:10 2014
From: DLRdave at aol.com (David Cole)
Date: Sat, 11 Oct 2014 19:01:10 -0400
Subject: [CMake] CTest Custom warning exception in CTestCustom.cmake.in
In-Reply-To: <CANNqv9dTWUe6XAj=2-xJoYzktY5BNt2duCtjZeM2CTEa8Fn9-g@mail.gmail.com>
References: <CANNqv9dTWUe6XAj=2-xJoYzktY5BNt2duCtjZeM2CTEa8Fn9-g@mail.gmail.com>
Message-ID: <CAKME8fFAMuud_wf1Pxsv4GYhABU+NANyqpQdv1Uy88FAjD1icA@mail.gmail.com>

Does your dashboard script call ctest_read_custom_files after ctest_configure?

You should do that, as the CMake and VTK (and other) dashboards do:

http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;h=576db9a98725503b53e0a6e29f4db7682cfaf1a2;hb=182b93635464ee35100522dec811abb76b55c742#l367

Looks like the regular expressions are correct... but if you're not
calling ctest_read_custom_files, the CTestCustom file will have no
effect.


HTH,
David



On Sat, Oct 11, 2014 at 9:47 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:
> Hi all,
>
> Can anyone explain me how to filter out the below warning from dashboard?
>
> warning: #warning "deprecated"
> ...../vcl_deprecated_header.h:10:3: warning: #warning "deprecated" [-Wcpp]
>  # warning "deprecated"
>
> So far I tried having below in CTestCustom.cmake
>
> set(CTEST_CUSTOM_WARNING_EXCEPTION
>   ${CTEST_CUSTOM_WARNING_EXCEPTION}
>   ".*vcl_deprecated_header.*warning.*"
>   "vcl_deprecated_header"
> ...
> )
>
>
>
> --
> Regards,
>    Rashad
>
> --
>
> 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

From mohammedrashadkm at gmail.com  Sun Oct 12 00:42:34 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Sun, 12 Oct 2014 10:12:34 +0530
Subject: [CMake] CTest Custom warning exception in CTestCustom.cmake.in
In-Reply-To: <CAKME8fFAMuud_wf1Pxsv4GYhABU+NANyqpQdv1Uy88FAjD1icA@mail.gmail.com>
References: <CANNqv9dTWUe6XAj=2-xJoYzktY5BNt2duCtjZeM2CTEa8Fn9-g@mail.gmail.com>
 <CAKME8fFAMuud_wf1Pxsv4GYhABU+NANyqpQdv1Uy88FAjD1icA@mail.gmail.com>
Message-ID: <CANNqv9fpG4G_3H3cWNia4ZQopWQV1OHrFFnJmi7hJsTJdUUndg@mail.gmail.com>

Hello David,

On Sun, Oct 12, 2014 at 4:31 AM, David Cole <DLRdave at aol.com> wrote:

> Does your dashboard script call ctest_read_custom_files after
> ctest_configure?
>
> You should do that, as the CMake and VTK (and other) dashboards do:
>
>
> http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;h=576db9a98725503b53e0a6e29f4db7682cfaf1a2;hb=182b93635464ee35100522dec811abb76b55c742#l367
>
> Looks like the regular expressions are correct... but if you're not
> calling ctest_read_custom_files, the CTestCustom file will have no
> effect.
>
> Yes I have ctest_read_custom_files after ctest_confgiure

see build notes - http://dash.orfeo-toolbox.org/viewNotes.php?buildid=160097


I thought it has something to do with '#' and quotes in the warning

....#warning "deprecated" [-Wcpp]



> HTH,
> David
>
>
>
> On Sat, Oct 11, 2014 at 9:47 AM, Rashad M <mohammedrashadkm at gmail.com>
> wrote:
> > Hi all,
> >
> > Can anyone explain me how to filter out the below warning from dashboard?
> >
> > warning: #warning "deprecated"
> > ...../vcl_deprecated_header.h:10:3: warning: #warning "deprecated"
> [-Wcpp]
> >  # warning "deprecated"
> >
> > So far I tried having below in CTestCustom.cmake
> >
> > set(CTEST_CUSTOM_WARNING_EXCEPTION
> >   ${CTEST_CUSTOM_WARNING_EXCEPTION}
> >   ".*vcl_deprecated_header.*warning.*"
> >   "vcl_deprecated_header"
> > ...
> > )
> >
> >
> >
> > --
> > Regards,
> >    Rashad
> >
> > --
> >
> > 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
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141012/1d9630f6/attachment.html>

From Fabien.Spindler at inria.fr  Sun Oct 12 13:24:13 2014
From: Fabien.Spindler at inria.fr (Fabien Spindler)
Date: Sun, 12 Oct 2014 19:24:13 +0200
Subject: [CMake] What is recommended to export a package definition ?
Message-ID: <543AB93D.1010206@inria.fr>

Hi,

I want to create a config file for my package so that it can be found 
using find_package()

In the config file, I have to define the following variables:

  * <NAME>_FOUND
  * <NAME>_INCLUDE_DIRS
  * <NAME>_LIBRARIES
  * <NAME>_DEFINITIONS

I can't find any clear documentation concerning <NAME>_DEFINITION.
Should I export the definitions prefixed with or without "-D".

To be clear, if the package neads to be build with
add_definitions("-DMY_DEF")
in <NAME>Config.cmake should I set <NAME>_DEFINITIONS var as "MY_DEF" or 
"-DMY_DEF" ?

I would prefer "-DMY_DEF" so that in the project that will use my 
package I can simply call
add_definitions(${<NAME>_DEFINITIONS}), but I'm not sure this is the 
recommended ?


Thanks
Fabien

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141012/8f55fe78/attachment.html>

From verbeek at servicerobotics.eu  Mon Oct 13 09:20:22 2014
From: verbeek at servicerobotics.eu (Dr. Christian Verbeek)
Date: Mon, 13 Oct 2014 15:20:22 +0200
Subject: [CMake] Quoting and Escapes
In-Reply-To: <5437B522.6010508@gmail.com>
References: <5437AB60.2080007@servicerobotics.eu> <5437AFDA.1070202@gmail.com>
 <5437B3F7.6000808@servicerobotics.eu> <5437B522.6010508@gmail.com>
Message-ID: <543BD196.60209@servicerobotics.eu>

Am 10.10.14 um 12:29 schrieb Nils Gladitz:
> On 10/10/2014 12:24 PM, Dr. Christian Verbeek wrote:
>> Am 10.10.14 um 12:07 schrieb Nils Gladitz:
>>> On 10/10/2014 11:48 AM, Dr. Christian Verbeek wrote:
>>>
>>>> INCLUDE( "C:/Program Files (x86)/somepath" )
>>>> ->  include could not find load file: somepath
>>>
>>> This one should work as-is.
>>> Is "somepath" an existing regular CMake script (text file)?
>>>
>>> Nils
>>>
>> The whole string is
>> C:/Program Files 
>> (x86)/Didactic/RobotinoView3/api/cmake/unit_plugin.cmake
>> and Yes unit_plugin.cmake is existing and regular.
>> The string gets truncated to /cmake/unit_plugin.cmake
>>
>> So it's definitely not working. I checked it more than twice.
>
> Are there any other errors in context?
>
> CMake reports that it can not find a module also when there is some 
> error in that file.
>
> The path itself should not be the issue.
>
> CMake itself uses absolute paths to modules in it's own module 
> directory (which on 64 bit windows also resides in "C:/Program Files 
> (x86)" per default).
>
> Nils
>
You made a point Nils. The error occured within the included cmake file. 
The path was not the problem. Thanks for pointing me into the right 
direction.

Christian


From dominik at itis.ethz.ch  Mon Oct 13 10:24:07 2014
From: dominik at itis.ethz.ch (Dominik Szczerba)
Date: Mon, 13 Oct 2014 16:24:07 +0200
Subject: [CMake] Specify Configuration with -D on command line
Message-ID: <CALm7otr_nUq4XP8K7n7aJSwrsVtgRF0DgfPC6ZiwM2=4GyHoKw@mail.gmail.com>

Hi,

Is it possible to do something like:

cmake -DBOOST_LIBRARYDIR:PATH=C:/tmp//$(Configuration) ...

from command line? Such that when I swich between release/debug in the
gui the correct versions will be taken? Windows 7 64 bit, Visual
Studio 2012 here.

Many thanks!
Dominik

From houssen at ipgp.fr  Mon Oct 13 10:47:24 2014
From: houssen at ipgp.fr (houssen)
Date: Mon, 13 Oct 2014 16:47:24 +0200
Subject: [CMake]
 =?utf-8?q?What_is_the_CMake_equivalent_for_autotools_=22m?=
 =?utf-8?q?ake_dist=22_=3F?=
In-Reply-To: <CAGyo1oxat_B3VduqMo8FPEVXxsRW41_pmfCNOhPyU7cqTxUb8A@mail.gmail.com>
References: <0133c7a456fcaaac6ebdf01fd85d7ce5@imap.ipgp.fr>
 <CAGyo1oxat_B3VduqMo8FPEVXxsRW41_pmfCNOhPyU7cqTxUb8A@mail.gmail.com>
Message-ID: <31eb6090e00ca7a98be64b2789e3ad76@imap.ipgp.fr>

Thanks, "make package_source" is what I need.

FH

Le 2014-10-11 20:03, Iosif Neitzke a ?crit?:
> With CPack enabled, "make help" will show all the valid targets.  The
> "package_source" target should be one of those targets.
>
> A simple project on Linux built with "make package_source" gives me:
>
> 
> ${CMAKE_BINARY_DIR}/_CPack_Packages/Linux-Source/{TZ,TGZ,TBZ2}/CPack_Example-0.1.1-Linux.tar.{bz2,gz,Z}
>
> All three files contain all the source files in my
> ${CMAKE_SOURCE_DIR}.  (Including CMakeLists.txt)
>
>
>
> On Sat, Oct 11, 2014 at 12:05 PM, houssen <houssen at ipgp.fr> wrote:
>> Hello,
>>
>> What is the CMake equivalent for autotools "make dist" ?
>> By autotools "make dist", I mean a way to wrap all sources and test 
>> files
>> needed to build and test the package and / or to be ready for dev.
>>
>> I googled this question : I heard about CPack (and "make package"), 
>> but, I
>> am not sure to understand if this is designed to answer the same 
>> question.
>> Using CPack and "make package", I get a tar.gz that contains the 
>> executable
>> (the binary in a bin directory) but without the source : this is not 
>> what I
>> want as sources are missing (the tar.gz is not ready for dev).
>>
>> Is this the expected behavior ? ("make package" is intended to 
>> provide only
>> binaries to be installed ? Not the source / test files ?)
>> Did I miss something ? Did I forgot something in the CMakeLists.txt 
>> ?
>> I am supposed to tar the root directory (= project directory 
>> containing
>> hello.cpp and CMakeLists.txt) after I suppressed all BUILD 
>> directories that
>> could have been built previously ?
>>
>> FH
>> --
>>
>> 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


From clinton at elemtech.com  Mon Oct 13 11:50:29 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Mon, 13 Oct 2014 09:50:29 -0600
Subject: [CMake] VERSION and SOVERSION target properties on OS X
In-Reply-To: <CAEiokwQFzDRF-01N-CjB6ghYdmhhqNvSsiXcdKz+ftDfwma_kg@mail.gmail.com>
References: <CAEiokwQFzDRF-01N-CjB6ghYdmhhqNvSsiXcdKz+ftDfwma_kg@mail.gmail.com>
Message-ID: <41589377.pD7rSnvIx4@stryke>

On Friday, October 10, 2014 12:43:53 PM Steven Velez wrote:
> Forgive me if this question has been answered before but with CMAKE 2.8.12
> (I believe) xcode builds on OS X started generating shared libraries
> decorated with the "VERSION" target property and symlinked by a bare dylib
> name and one decorated with the SOVERSION.
> 
> I understand this is common practice on many unixen, but it is complicating
> our deployment and update logic (not cpack, sorry to say).
> 
> Our application is fairly self-contained, so we would like to continue
> generating only those bare-named dylibs, but we need to keep the SOVERSION
> set to that the embedded "compatibility version" remains how we want it.
> 
> I have not found a combination of values to these properties that does what
> I would like, so I was wondering if there was a way to get the old
> behavior.... perhaps with a policy or something?
> 
> If there isn't a way to do it now, would there be an acceptable way to
> specify this behavior that would be accepted as a patch?
> 
> Thanks,
> Steven

That change was made to make the Xcode and Makefile generators consistent.

To get what you want now (with both the older and newer CMake versions), you 
can remove the SOVERSION property and set the LINK_FLAGS property to pass -
compatibilty_version to the linker.

Clint

From hobbes1069 at gmail.com  Mon Oct 13 15:28:53 2014
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Mon, 13 Oct 2014 14:28:53 -0500
Subject: [CMake] Visual Basic support
Message-ID: <CAN3TeO3AgM8rDrZx+gR2KY+KbkjEkH_NHbUSqh2PQppo501NWg@mail.gmail.com>

Is it currently possible to build a VB project with cmake? I can't seem to
find any references to do so. I'm planning on using the bvnc compiler from
the mono package for linux.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141013/35380683/attachment.html>

From peastman at stanford.edu  Mon Oct 13 17:38:48 2014
From: peastman at stanford.edu (Peter Eastman)
Date: Mon, 13 Oct 2014 14:38:48 -0700
Subject: [CMake] Installation corrupts library on OS X
Message-ID: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>

Hi,

I'm using CMake 3.0.2 on OS X 10.9.4.  When I do a "make install", it's somehow corrupting some of my libraries at install time.

Here is what otool reports for the library in my build directory - that is, the state of the library prior to installation:

$ otool -L libOpenMMAmoebaCUDA.dylib 
libOpenMMAmoebaCUDA.dylib:
	/Users/peastman/workspace/openmm/bin-release/libOpenMMAmoebaCUDA.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current version 6.0.37)
	/Users/peastman/workspace/openmm/bin-release/libOpenMM.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	/Users/peastman/workspace/openmm/bin-release/libOpenMMCUDA.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/peastman/workspace/openmm/bin-release/libOpenMMAmoeba.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current version 6.0.37)
	@rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)

No problems.  Everything looks ok.  Now here is what it reports for the same library in the install directory - the is, the state of the library after installation:

$ otool -L /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib 
/usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib:
	@rpath/libOpenMMAmoebaCUDA.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current version 6.0.37)
	@rpath/libOpenMM.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	@rpath/libOpenMMCUDA.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libOpenMMAmoeba.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current version 6.0.37)
	@rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
load command 22 size zero (can't advance to other load commands)

As expected, the absolute paths have been replaced by relative paths.  But it also now reports an error message at the end about "load command 22 size zero".  This error does not prevent the library from actually being loaded.  It seems to work fine as far as that is concerned.  However, if I try to use install_name_tool to make any further changes to the paths in the library it fails with an error message:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for architecture i386 object: /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib malformed object (load command 22 cmdsize is zero)

Any idea what's going on?

Thanks!

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141013/629bf245/attachment.html>

From clinton at elemtech.com  Mon Oct 13 22:33:27 2014
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Mon, 13 Oct 2014 20:33:27 -0600 (MDT)
Subject: [CMake] Installation corrupts library on OS X
In-Reply-To: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
References: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
Message-ID: <752261796.1242716.1413254007546.JavaMail.zimbra@elemtech.com>

----- Original Message -----

> Hi,

> I'm using CMake 3.0.2 on OS X 10.9.4. When I do a "make install", it's
> somehow corrupting some of my libraries at install time.

> Here is what otool reports for the library in my build directory - that is,
> the state of the library prior to installation:

> $ otool -L libOpenMMAmoebaCUDA.dylib
> libOpenMMAmoebaCUDA.dylib:
> /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoebaCUDA.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current
> version 6.0.37)
> /Users/peastman/workspace/openmm/bin-release/libOpenMM.dylib (compatibility
> version 0.0.0, current version 0.0.0)
> @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version
> 6.0.37)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> /Users/peastman/workspace/openmm/bin-release/libOpenMMCUDA.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoeba.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current
> version 6.0.37)
> @rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version
> 6.0.37)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)

> No problems. Everything looks ok. Now here is what it reports for the same
> library in the install directory - the is, the state of the library after
> installation:

> $ otool -L /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib
> /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib:
> @rpath/libOpenMMAmoebaCUDA.dylib (compatibility version 0.0.0, current
> version 0.0.0)
> @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current
> version 6.0.37)
> @rpath/libOpenMM.dylib (compatibility version 0.0.0, current version 0.0.0)
> @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version
> 6.0.37)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> @rpath/libOpenMMCUDA.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> @rpath/libOpenMMAmoeba.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current
> version 6.0.37)
> @rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version
> 6.0.37)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> load command 22 size zero (can't advance to other load commands)

> As expected, the absolute paths have been replaced by relative paths. But it
> also now reports an error message at the end about "load command 22 size
> zero". This error does not prevent the library from actually being loaded.
> It seems to work fine as far as that is concerned. However, if I try to use
> install_name_tool to make any further changes to the paths in the library it
> fails with an error message:

> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
> for architecture i386 object:
> /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib malformed object
> (load command 22 cmdsize is zero)

> Any idea what's going on?

Yeah, I think you have duplicate LC_RPATH load commands. In that case, your binaries can be corrupted by install_name_tool during "make install." 
To check if that is your case, you can run this on the binary before installation to see if you have duplicates. 

otool -l app | grep -A2 LC_RPATH 

If the duplicates come from your own linker flags such as, -Wl,-rpath,/some/path, you may need to remove those. 
Otherwise, it would help if you can provide a minimal test case to reproduce the problem. 

It would also help if someone could report this corruption by install_name_tool bug to Apple. You are the second to come to this mailing list about this bug. 

Clint 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141013/1708db4d/attachment-0001.html>

From j.kreuzberger at procitec.de  Tue Oct 14 03:21:31 2014
From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=)
Date: Tue, 14 Oct 2014 09:21:31 +0200
Subject: [CMake]
	=?utf-8?q?What_is_the_CMake_equivalent_for_autotools_=22m?=
	=?utf-8?q?ake_dist=22_=3F?=
Message-ID: <zarafa.543ccefb.1671.083c34eb00de8ddf@zarafa.procitec.de>

Hi!

This was also new to me, quite good. Question is now: i have configured cpack in my CMakeLists to use TGZ only (on linux).
The binary package is made as tgz. For the source 3 packages are generated (as in your example). How could this be
limited to the same as for the binaries or a different but just one?
With my sources it takes some time to package...


>Subject: Re: [CMake] What is the CMake equivalent for autotools "make
>	dist" ?
>
>With CPack enabled, "make help" will show all the valid targets.  The
>"package_source" target should be one of those targets.
>
>A simple project on Linux built with "make package_source" gives me:
>
>${CMAKE_BINARY_DIR}/_CPack_Packages/Linux-Source/{TZ,TGZ,TBZ2}/CPack_Example-0.1.1-Linux.tar.{bz2,gz,Z}
>
>All three files contain all the source files in my
>${CMAKE_SOURCE_DIR}.  (Including CMakeLists.txt)

Mannheim HRB 504702
Gesch?ftsf?hrer: Dipl.-Ing. (FH) Michael Brenk (Vorsitzender), Dipl.-Ing. (FH) Dipl.-Inf. (FH) Jens Heyen

This e-mail may contain confidential and/or legally protected information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.
Thank you!



From j.kreuzberger at procitec.de  Tue Oct 14 03:24:40 2014
From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=)
Date: Tue, 14 Oct 2014 09:24:40 +0200
Subject: [CMake]
	=?utf-8?q?What_is_the_CMake_equivalent_for_autotools_=22m?=
	=?utf-8?q?ake_dist=22_=3F?=
Message-ID: <zarafa.543ccfb8.1711.2bc4f65947dc7fe5@zarafa.procitec.de>

Ok, found it: i must set CPACK_SOURCE_TZ to off to avoid the source to be packaged as tz.
its a little bit different as for the binary package, but ok.

Thanks

Joerg

>Hi!
>
>This was also new to me, quite good. Question is now: i have configured cpack in my CMakeLists to use TGZ only (on >linux).
>The binary package is made as tgz. For the source 3 packages are generated (as in your example). How could this be
>limited to the same as for the binaries or a different but just one?
>With my sources it takes some time to package...
>
>
>>Subject: Re: [CMake] What is the CMake equivalent for autotools "make
>>	dist" ?
>>
>>With CPack enabled, "make help" will show all the valid targets.  The
>>"package_source" target should be one of those targets.
>>
>>A simple project on Linux built with "make package_source" gives me:
>>
>>${CMAKE_BINARY_DIR}/_CPack_Packages/Linux-Source/{TZ,TGZ,TBZ2}/CPack_Example-0.1.1-Linux.tar.{bz2,gz,Z}
>>
>>All three files contain all the source files in my
>>${CMAKE_SOURCE_DIR}.  (Including CMakeLists.txt)

Mannheim HRB 504702
Gesch?ftsf?hrer: Dipl.-Ing. (FH) Michael Brenk (Vorsitzender), Dipl.-Ing. (FH) Dipl.-Inf. (FH) Jens Heyen

This e-mail may contain confidential and/or legally protected information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.
Thank you!



From eric.noulard at gmail.com  Tue Oct 14 03:31:46 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 14 Oct 2014 09:31:46 +0200
Subject: [CMake] What is the CMake equivalent for autotools "make dist" ?
In-Reply-To: <zarafa.543ccefb.1671.083c34eb00de8ddf@zarafa.procitec.de>
References: <zarafa.543ccefb.1671.083c34eb00de8ddf@zarafa.procitec.de>
Message-ID: <CAPASGLr7FKsd8GP1EQ_pkrq02dZhWHwazdiFAXNZkehapHyxgg@mail.gmail.com>

2014-10-14 9:21 GMT+02:00 J?rg Kreuzberger <j.kreuzberger at procitec.de>:

> Hi!
>
> This was also new to me, quite good. Question is now: i have configured
> cpack in my CMakeLists to use TGZ only (on linux).
> The binary package is made as tgz. For the source 3 packages are generated
> (as in your example). How could this be
> limited to the same as for the binaries or a different but just one?
> With my sources it takes some time to package...
>

The way to select the list of CPack generator to be used is the same for
BINARY or SOURCE.

set(CPACK_GENERATOR "TGZ")
select TGZ for BINARY

set(CPACK_SOURCE_GENERATOR "TGZ")
does the same for SOURCE.

the default value of CPACK_SOURCE_GENERATOR is "TZ;TGZ;TBZ2"  (On unix).


-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/adda8d2d/attachment.html>

From eric.noulard at gmail.com  Tue Oct 14 03:44:11 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 14 Oct 2014 09:44:11 +0200
Subject: [CMake] What is the CMake equivalent for autotools "make dist" ?
In-Reply-To: <zarafa.543ccfb8.1711.2bc4f65947dc7fe5@zarafa.procitec.de>
References: <zarafa.543ccfb8.1711.2bc4f65947dc7fe5@zarafa.procitec.de>
Message-ID: <CAPASGLpffM8hrzHuzR6e8ovwGoK1KzxkUisZ37HhzGfheLN_pw@mail.gmail.com>

2014-10-14 9:24 GMT+02:00 J?rg Kreuzberger <j.kreuzberger at procitec.de>:

> Ok, found it: i must set CPACK_SOURCE_TZ to off to avoid the source to be
> packaged as tz.
> its a little bit different as for the binary package, but ok.
>

This is a another way to select CPack generator but you can always specify
the list explicitely
in your CMakeLists.txt **before** include(CPack).

You may have some "logic" depending on the target platform e.g;

if(WIN32)
    set(CPACK_SOURCE_GENERATOR "ZIP")
    set(CPACK_GENERATOR "ZIP")

    # Add NSIS generator iff makensis is found on the system
    find_program(MAKENSIS_EXECUTABLE
                 NAMES makensis
                 DOC "The NSIS package maker command")
    if (MAKENSIS_EXECUTABLE)
      list(APPEND CPACK_GENERATOR "NSIS")
    endif(MAKENSIS_EXECUTABLE)
else(WIN32)
    set(CPACK_SOURCE_GENERATOR "TGZ;ZIP")
    if(APPLE)
      set(CPACK_GENERATOR "TGZ;PackageMaker")
    else(APPLE)
      set(CPACK_GENERATOR "TGZ;RPM;DEB")
    endif(APPLE)
endif(WIN32)

include(CPack)


With this if you are in the build directory
make package (or in a generator independent way "cmake --build . --target
package")
or
make package_source

will build the list of specified CPack generators packages.

However you can always override that by doing (in the build dir as well):
cpack -G TGZ

which will only build the binary TGZ whatever was specified in the
CMakeLists.txt.

for the source package this is done using the CPackSourceConfig.cmake file:

cpack -G TGZ --config CPackSourceConfig.cmake

I hope this helps in understanding the way CPack works.


-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/16303f0d/attachment.html>

From kim at rthansen.dk  Tue Oct 14 07:24:19 2014
From: kim at rthansen.dk (Kim Rydhof Thor Hansen)
Date: Tue, 14 Oct 2014 13:24:19 +0200
Subject: [CMake] moc is not rebuilding when included metadata.json is changed
Message-ID: <CAEGYRW6rm-MjEtqrbH04Y+EKHV+YtJ1_+Ok9qyGYBaGkKkaihA@mail.gmail.com>

Hi CMake mailing list

In the attached example project metadata.json is included in plugin.h
by moc and the build is controlled using automoc. When the json file
is changed this should trigger a rerun of moc and a rebuild of the
plugin, but it doesn't.

How can I change CMakeLists.txt such that the rebuild will be triggered?

Regards,
-- 
Kim Rydhof Thor Hansen
Vadg?rdsvej 3, 2. tv.
2860 S?borg
Phone: +45 3091 2437
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugin-rebuild.zip
Type: application/zip
Size: 1310 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/68a35ed1/attachment.zip>

From GAujay at invensense.com  Tue Oct 14 11:57:37 2014
From: GAujay at invensense.com (Gregoire Aujay)
Date: Tue, 14 Oct 2014 15:57:37 +0000
Subject: [CMake] IAR IDE Generator Support
Message-ID: <3A27EB644551254E9CC610A9420792A202A164D0@IUSEXCH01.invcorp.invensense.com>

Hello,

Does someone know about any initiative to add IAR WorkBench IDE to the list of supported generators. I cannot find a Mantis issue about that.

This would not be a Makefile based generator but a native one like XCode or VisualStudio.

Regards,
Gregoire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/8b8c22db/attachment.html>

From peastman at stanford.edu  Tue Oct 14 13:19:41 2014
From: peastman at stanford.edu (Peter Eastman)
Date: Tue, 14 Oct 2014 10:19:41 -0700
Subject: [CMake] Installation corrupts library on OS X
In-Reply-To: <752261796.1242716.1413254007546.JavaMail.zimbra@elemtech.com>
References: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
 <752261796.1242716.1413254007546.JavaMail.zimbra@elemtech.com>
Message-ID: <3AC869C4-DC53-446C-B0B8-B447DC997E43@stanford.edu>

Hi Clint,

You're absolutely right:

$ otool -l libOpenMMAmoebaCUDA.dylib | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 32
         path /usr/local/cuda/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 32
         path /usr/local/cuda/lib (offset 12)

I'll try to figure out where the duplicate is coming from and see if that fixes it.

I'd be glad to report this to Apple, but I can't figure out how to reproduce the problem without using CMake.  I tried using install_name_tool to directly change all the paths myself, and that worked fine.  It didn't produce the problem.  Is CMake doing something different from just a series of calls to "install_name_tool -change" and "install_name_tool -id"?

Peter


On Oct 13, 2014, at 7:33 PM, clinton at elemtech.com wrote:

> Yeah, I think you have duplicate LC_RPATH load commands.  In that case, your binaries can be corrupted by install_name_tool during "make install."
> To check if that is your case, you can run this on the binary before installation to see if you have duplicates.
> otool -l app | grep -A2 LC_RPATH
> 
> If the duplicates come from your own linker flags such as, -Wl,-rpath,/some/path, you may need to remove those.
> Otherwise, it would help if you can provide a minimal test case to reproduce the problem.
> 
> It would also help if someone could report this corruption by install_name_tool bug to Apple.  You are the second to come to this mailing list about this bug.
> 
> Clint
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/deab4108/attachment-0001.html>

From clinton at elemtech.com  Tue Oct 14 14:06:27 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 14 Oct 2014 12:06:27 -0600
Subject: [CMake] Installation corrupts library on OS X
In-Reply-To: <3AC869C4-DC53-446C-B0B8-B447DC997E43@stanford.edu>
References: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
 <752261796.1242716.1413254007546.JavaMail.zimbra@elemtech.com>
 <3AC869C4-DC53-446C-B0B8-B447DC997E43@stanford.edu>
Message-ID: <1939272.lNxsrSxB3M@stryke>

On Tuesday, October 14, 2014 10:19:41 AM Peter Eastman wrote:
> Hi Clint,
> 
> You're absolutely right:
> 
> $ otool -l libOpenMMAmoebaCUDA.dylib | grep -A2 LC_RPATH
>           cmd LC_RPATH
>       cmdsize 32
>          path /usr/local/cuda/lib (offset 12)
> --
>           cmd LC_RPATH
>       cmdsize 32
>          path /usr/local/cuda/lib (offset 12)
> 
> I'll try to figure out where the duplicate is coming from and see if that
> fixes it.
> 
> I'd be glad to report this to Apple, but I can't figure out how to reproduce
> the problem without using CMake.  I tried using install_name_tool to
> directly change all the paths myself, and that worked fine.  It didn't
> produce the problem.  Is CMake doing something different from just a series
> of calls to "install_name_tool -change" and "install_name_tool -id"?
> 
> Peter

Here's a simple way to reproduce from the command line:

echo "void foo() {}" > lib.c
gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib -Wl,-rpath,/usr/lib lib.c
install_name_tool -delete_rpath /usr/lib libtest.dylib
otool -L libtest.dylib
  # gives me the error: "load command 13 size zero (can't advance to other 
load commands)"

At install time, CMake will call "install_name_tool -delete_rpath ... " as 
needed.

I can't get into Apple's bug tracker.  I don't know why.  When I try to log 
in, it comes back with a generic error and it asks me to email them with 
details about the error.

When I do the same on Linux, the GNU linker will consolidate the duplicate 
paths.

Thanks!

Clint


> 
> On Oct 13, 2014, at 7:33 PM, clinton at elemtech.com wrote:
> > Yeah, I think you have duplicate LC_RPATH load commands.  In that case,
> > your binaries can be corrupted by install_name_tool during "make
> > install." To check if that is your case, you can run this on the binary
> > before installation to see if you have duplicates. otool -l app | grep
> > -A2 LC_RPATH
> > 
> > If the duplicates come from your own linker flags such as,
> > -Wl,-rpath,/some/path, you may need to remove those. Otherwise, it would
> > help if you can provide a minimal test case to reproduce the problem.
> > 
> > It would also help if someone could report this corruption by
> > install_name_tool bug to Apple.  You are the second to come to this
> > mailing list about this bug.
> > 
> > Clint

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com

From sbv1976 at gmail.com  Tue Oct 14 14:35:43 2014
From: sbv1976 at gmail.com (Steven Velez)
Date: Tue, 14 Oct 2014 14:35:43 -0400
Subject: [CMake] VERSION and SOVERSION target properties on OS X
In-Reply-To: <41589377.pD7rSnvIx4@stryke>
References: <CAEiokwQFzDRF-01N-CjB6ghYdmhhqNvSsiXcdKz+ftDfwma_kg@mail.gmail.com>
 <41589377.pD7rSnvIx4@stryke>
Message-ID: <CAEiokwQFM_hEOED_eE3Hr=O0gTdOmbh-9emFvF=7FjTTi7GWRA@mail.gmail.com>

Ah... good idea.  I should have considered that.  Thanks.

On Mon, Oct 13, 2014 at 11:50 AM, Clinton Stimpson <clinton at elemtech.com>
wrote:

> On Friday, October 10, 2014 12:43:53 PM Steven Velez wrote:
> > Forgive me if this question has been answered before but with CMAKE
> 2.8.12
> > (I believe) xcode builds on OS X started generating shared libraries
> > decorated with the "VERSION" target property and symlinked by a bare
> dylib
> > name and one decorated with the SOVERSION.
> >
> > I understand this is common practice on many unixen, but it is
> complicating
> > our deployment and update logic (not cpack, sorry to say).
> >
> > Our application is fairly self-contained, so we would like to continue
> > generating only those bare-named dylibs, but we need to keep the
> SOVERSION
> > set to that the embedded "compatibility version" remains how we want it.
> >
> > I have not found a combination of values to these properties that does
> what
> > I would like, so I was wondering if there was a way to get the old
> > behavior.... perhaps with a policy or something?
> >
> > If there isn't a way to do it now, would there be an acceptable way to
> > specify this behavior that would be accepted as a patch?
> >
> > Thanks,
> > Steven
>
> That change was made to make the Xcode and Makefile generators consistent.
>
> To get what you want now (with both the older and newer CMake versions),
> you
> can remove the SOVERSION property and set the LINK_FLAGS property to pass -
> compatibilty_version to the linker.
>
> Clint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/9285c575/attachment.html>

From sebastien.pulverail at sogeti.com  Tue Oct 14 14:29:06 2014
From: sebastien.pulverail at sogeti.com (PULVERAIL, Sebastien)
Date: Tue, 14 Oct 2014 18:29:06 +0000
Subject: [CMake] Compile a fortran exe from several subdirs
Message-ID: <ef4c678b991d4866b2cfd4fe5742dad5@DB4PR02MB0366.eurprd02.prod.outlook.com>

Hi everyone,

I'm using cmake to generate my executable. And I am facing some issues.
Let's assume I have the following tree :

Src/
    01_Module1/
        File1.F90
        File2.F90
   02_Module2/
        File3.F90
        File4.F90
        File5.F90
    03_Module3/
        File6.F90
        File7.F90
Bin/
Obj/

I need to generate "exe1" in "Bin" directory from all the Fortran source files in "Src" directory.
Moreover:

? "01_Module1" has to be compile before "02_Module2" and "02_Module2" has to be compiled before "03_Module3".

? All the F90 source files in the "Src" directory have to be compiled and linked to generate "exe1".

? All the object files have to be generated in "Obj" directory.

I have strictly no idea how I have to make my CMakeLists.txt files, and I really need your help on this.
Can you help me doing this please?

Thanks in advance for your help!

S?bastien.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/710c43ef/attachment.html>

From peastman at stanford.edu  Tue Oct 14 15:10:36 2014
From: peastman at stanford.edu (Peter Eastman)
Date: Tue, 14 Oct 2014 12:10:36 -0700
Subject: [CMake] Installation corrupts library on OS X
In-Reply-To: <1939272.lNxsrSxB3M@stryke>
References: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
 <752261796.1242716.1413254007546.JavaMail.zimbra@elemtech.com>
 <3AC869C4-DC53-446C-B0B8-B447DC997E43@stanford.edu>
 <1939272.lNxsrSxB3M@stryke>
Message-ID: <2B019054-27DB-4496-A175-5203664B97B8@stanford.edu>

Hi Clint,

In my case, it wasn't anything like that.  I was only specifying /usr/local/cuda/lib once.  More specifically, my CMakeLists.txt specified

TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})

where CUDA_LIBRARIES is

/usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib

This library also linked against another of my libraries, that also happened to link against CUDA.  So that's why it was getting referenced twice: once directly, and once indirectly via a second library.

In any case, it's not clear to me why CMake is calling "install_name_tool -delete_rpath".  Everything works fine without doing that.  And when you do it, that breaks things.

Peter


On Oct 14, 2014, at 11:06 AM, Clinton Stimpson <clinton at elemtech.com> wrote:

> Here's a simple way to reproduce from the command line:
> 
> echo "void foo() {}" > lib.c
> gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib -Wl,-rpath,/usr/lib lib.c
> install_name_tool -delete_rpath /usr/lib libtest.dylib
> otool -L libtest.dylib
>  # gives me the error: "load command 13 size zero (can't advance to other 
> load commands)"
> 
> At install time, CMake will call "install_name_tool -delete_rpath ... " as 
> needed.
> 
> I can't get into Apple's bug tracker.  I don't know why.  When I try to log 
> in, it comes back with a generic error and it asks me to email them with 
> details about the error.
> 
> When I do the same on Linux, the GNU linker will consolidate the duplicate 
> paths.
> 
> Thanks!
> 
> Clint



From clinton at elemtech.com  Tue Oct 14 15:56:54 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 14 Oct 2014 13:56:54 -0600
Subject: [CMake] Installation corrupts library on OS X
In-Reply-To: <2B019054-27DB-4496-A175-5203664B97B8@stanford.edu>
References: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
 <1939272.lNxsrSxB3M@stryke>
 <2B019054-27DB-4496-A175-5203664B97B8@stanford.edu>
Message-ID: <7162180.XNoJrk3aCc@stryke>

On Tuesday, October 14, 2014 12:10:36 PM Peter Eastman wrote:
> Hi Clint,
> 
> In my case, it wasn't anything like that.  I was only specifying
> /usr/local/cuda/lib once.  More specifically, my CMakeLists.txt specified
> 
> TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})
> 
> where CUDA_LIBRARIES is
> 
> /usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib

Since CMake 2.8.12, CMake will automatically figure out the 
-Wl,-rpath-Wl,/usr/local/cuda/lib part for 
/usr/local/cuda/lib/libcudart.dylib.

So, the duplicate comes from CMake adding it once, and you adding it once.

You should be able to remove any -Wl,-rpath flags that you add manually with 
CMake 2.8.12 and newer, and let CMake take care of that for you.

> 
> This library also linked against another of my libraries, that also happened
> to link against CUDA.  So that's why it was getting referenced twice: once
> directly, and once indirectly via a second library.
> 
> In any case, it's not clear to me why CMake is calling "install_name_tool
> -delete_rpath".  Everything works fine without doing that.  And when you do
> it, that breaks things.

CMake calls "install_name_tool -delete_rpath" at install time to remove the 
build rpaths and add install rpaths as specified by the INSTALL_RPATH target 
property.

For more details and examples:
http://www.kitware.com/blog/home/post/510
http://www.cmake.org/Wiki/CMake_RPATH_handling

Clint

> 
> Peter
> 
> On Oct 14, 2014, at 11:06 AM, Clinton Stimpson <clinton at elemtech.com> wrote:
> > Here's a simple way to reproduce from the command line:
> > 
> > echo "void foo() {}" > lib.c
> > gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib -Wl,-rpath,/usr/lib
> > lib.c install_name_tool -delete_rpath /usr/lib libtest.dylib
> > otool -L libtest.dylib
> > 
> >  # gives me the error: "load command 13 size zero (can't advance to other
> > 
> > load commands)"
> > 
> > At install time, CMake will call "install_name_tool -delete_rpath ... " as
> > needed.
> > 
> > I can't get into Apple's bug tracker.  I don't know why.  When I try to
> > log
> > in, it comes back with a generic error and it asks me to email them with
> > details about the error.
> > 
> > When I do the same on Linux, the GNU linker will consolidate the duplicate
> > paths.
> > 
> > Thanks!
> > 
> > Clint

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com

From george.zagaris at gmail.com  Tue Oct 14 22:23:57 2014
From: george.zagaris at gmail.com (George Zagaris)
Date: Tue, 14 Oct 2014 19:23:57 -0700
Subject: [CMake] Specifying different compilers for subsets of a project
Message-ID: <CAA2FMY+TgoRWXCU2KwLgTN3Q9+PJqmP7-zLc4Yzaci7Z8SpSyQ@mail.gmail.com>

Dear all,

I am working on a project where on certain platforms, namely, on a BG/Q or
Cray, we have to cross-compile the code, but still, there are parts of the
code that should only be compiled for the front end, login nodes.

Typically, we have a toolchain file, which among other things sets:
- CMAKE_CXX_COMPILER
- CMAKE_C_COMPILER
- CMAKE_FORTRAN_COMPILER

to the respective cross-compilers available on the target platform.

This compiles everything for the back-end.

The obvious way to compile front-end tools is to create another directory,
e.g., "front-end-build" and run cmake therein to re-configure and build
with a front-end compiler.

However, since only a relatively small subset of the files needs to be
compiled for the front-end, it is desirable to do this within the same
build, which leads to my question:

Is it possible to tell CMake to build certain files with a different
compiler? I know there is a way to set file properties to control the
compiler flags of certain files. Is there a "blessed" approach to control
the compiler for certain files and/or directories (and avoid things like
set(CMAKE_CXX_COMPILER...) within a CMakeLists file)?

Thank you very much for all your help.

Best,
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141014/b5fd3ee8/attachment.html>

From loose at astron.nl  Wed Oct 15 04:54:48 2014
From: loose at astron.nl (Marcel Loose)
Date: Wed, 15 Oct 2014 10:54:48 +0200
Subject: [CMake] Specifying different compilers for subsets of a project
In-Reply-To: <CAA2FMY+TgoRWXCU2KwLgTN3Q9+PJqmP7-zLc4Yzaci7Z8SpSyQ@mail.gmail.com>
References: <CAA2FMY+TgoRWXCU2KwLgTN3Q9+PJqmP7-zLc4Yzaci7Z8SpSyQ@mail.gmail.com>
Message-ID: <543E3658.90307@astron.nl>

Hi George,

You could (ab)use the "assembler plugin" system for that. Define your
own CMake-ASM-BGQ*.cmake files and use the assembler to compile the
sources.

Here's how I did this a couple of years ago for the BG/P.

In the CMakeLists.txt file for the files that need to be compiled with
the BG/P compiler I have:

## ---------------------------------------------------------------------------
## Enable BGP specific assembler.
## Use the BGP assembler also for linking C/C++ programs.
## ---------------------------------------------------------------------------
enable_language(ASM-BGP)
set(CMAKE_C_LINK_EXECUTABLE ${CMAKE_ASM-BGP_LINK_EXECUTABLE})
set(CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_ASM-BGP_LINK_EXECUTABLE})

CMakeASM-BGPInformation.cmake:

set(ASM_DIALECT "-BGP")
set(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS S)
set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT "<CMAKE_ASM${ASM_DIALECT}_COMPILER> <DEFINES> <FLAGS> -c -o <OBJECT> <SOURCE>")
set(CMAKE_ASM${ASM_DIALECT}_LINK_EXECUTABLE "<CMAKE_ASM${ASM_DIALECT}_COMPILER> <FLAGS> <LINK_FLAGS> <OBJECTS>  -o <TARGET> <LINK_LIBRARIES>")
include(CMakeASMInformation)
set(ASM_DIALECT)


CMakeDetermineASM-BGPCompiler.cmake:

set(ASM_DIALECT "-BGP")
set(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT ${CMAKE_ASM_COMPILER})
include(CMakeDetermineASMCompiler)
set(ASM_DIALECT)

CMakeTestASM-BGPCompiler.cmake:

set(ASM_DIALECT "-BGP")
include(CMakeTestASMCompiler)
set(ASM_DIALECT)


Hope this helps.

Regards,
Marcel Loose.

On 15/10/14 04:23, George Zagaris wrote:
> Dear all,
>
> I am working on a project where on certain platforms, namely, on a
> BG/Q or Cray, we have to cross-compile the code, but still, there are
> parts of the code that should only be compiled for the front end,
> login nodes.
>
> Typically, we have a toolchain file, which among other things sets:
> - CMAKE_CXX_COMPILER
> - CMAKE_C_COMPILER
> - CMAKE_FORTRAN_COMPILER
>
> to the respective cross-compilers available on the target platform.
>
> This compiles everything for the back-end.
>
> The obvious way to compile front-end tools is to create another
> directory, e.g., "front-end-build" and run cmake therein to
> re-configure and build with a front-end compiler.
>
> However, since only a relatively small subset of the files needs to be
> compiled for the front-end, it is desirable to do this within the same
> build, which leads to my question:
>
> Is it possible to tell CMake to build certain files with a different
> compiler? I know there is a way to set file properties to control the
> compiler flags of certain files. Is there a "blessed" approach to
> control the compiler for certain files and/or directories (and avoid
> things like set(CMAKE_CXX_COMPILER...) within a CMakeLists file)?
>
> Thank you very much for all your help.
>
> Best,
> George
>
>  
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141015/17afa42d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loose.vcf
Type: text/x-vcard
Size: 292 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141015/17afa42d/attachment.vcf>

From johannes.zarl at jku.at  Wed Oct 15 07:51:28 2014
From: johannes.zarl at jku.at (Johannes Zarl)
Date: Wed, 15 Oct 2014 13:51:28 +0200
Subject: [CMake] 2 libs stuck together !
In-Reply-To: <1412856389178-7588712.post@n2.nabble.com>
References: <1412856389178-7588712.post@n2.nabble.com>
Message-ID: <201410151351.28833.johannes.zarl@jku.at>

Hi,

It would be a lot easier to help you if you tried to minimize the 
CMakeLists.txt file before posting it to the list. The file as you posted it 
contains many unrelated stuff and even commented-out lines.

Not wanting to look at the whole thing as it is, my advice to you is to search 
for the lines in which you add the pthread and opencv_calib3d lines. Maybe you 
used quotes incorrectly when adding these lines...

Cheers,
  Johannes

On Thursday, 9. October 2014, 14:06:29, jay75 wrote:
> i am working on ros indigo, ubuntu 14.04 trusty, opencv 2.4.9
> 
> i get this message:
> /usr/bin/ld: cannot find -lopencv_calib3dlibpthread
> 
> now, "libpthread.so.0"  and "libopencv_calib3d.so" are two separate libs in
> "/usr/lib/x86_64-linux-gnu/", which i have added successfully to my
> "link_libraries". what am i doing wrong? here is my cmakelists.txt :
> cmake_minimum_required(VERSION 2.8.3)
> project(hal_main)
> 
> find_package(cmake_modules REQUIRED)
> find_package(Eigen REQUIRED)
> find_package(Boost REQUIRED thread date_time system filesystem
> program_options python )
> 
> ## Find catkin macros and libraries
> ## if COMPONENTS list like find_package(catkin REQUIRED COMPONENTS xyz)
> ## is used, also find other catkin packages
> find_package(catkin REQUIRED COMPONENTS
>   actionlib
>   actionlib_msgs
>   message_generation
>   roscpp
>   rospy
>   std_msgs
>   genmsg
>   visualization_msgs
>   clam_controller
>   clam_msgs
>   pcl_ros
>   cv_bridge
>   eigen_conversions
>   moveit_msgs
>   geometry_msgs
>   moveit_ros_planning
>   moveit_ros_planning_interface
>   tf
>   tf_conversions
>   moveit_simple_grasps
>   cmake_modules
>   moveit_core
>   # eigen_conversions
> )
> 
> 
> 
> find_package(OpenCV REQUIRED )
> find_package(OpenCV 2 REQUIRED )
> #find_package(OpenCV 2 REQUIRED COMPONENTS calib3dlibpthread)
> 
> include_directories(${EIGEN_INCLUDE_DIRS})
> 
> add_definitions(${EIGEN_DEFINITIONS})
> 
> #SET( CMAKE_MODULE_PATH "/usr/share/cmake-2.8/Modules/" )
> #set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
> "${CMAKE_SOURCE_DIR}/share/cmake_modules/cmake/Modules/")
> 
> find_package(MySQL REQUIRED COMPONENTS libmysqlcppconn.so.7.1.1.3)
> include_directories(${MYSQL_INCLUDE_DIRS})
> add_definitions(${MYSQL_DEFINITIONS})
> #link_directories(/usr/lib/mysql/plugin/${MYSQL_LIBRARY_DIRS})
> 
> 
> 
> #find_package(OpenCV2 REQUIRED)
> #find_package(mysql REQUIRED)
> ## System dependencies are found with CMake's conventions
> # find_package(Boost REQUIRED COMPONENTS system)
> 
> 
> ## Uncomment this if the package has a setup.py. This macro ensures
> ## modules and global scripts declared therein get installed
> ## See http://ros.org/doc/api/catkin/html/user_guide/setup_dot_py.html
> # catkin_python_setup()
> 
> ################################################
> ## Declare ROS messages, services and actions ##
> ################################################
> 
> ## To declare and build messages, services or actions from within this
> ## package, follow these steps:
> ## * Let MSG_DEP_SET be the set of packages whose message types you use in
> ##   your messages/services/actions (e.g. std_msgs, actionlib_msgs, ...).
> ## * In the file package.xml:
> ##   * add a build_depend and a run_depend tag for each package in
> MSG_DEP_SET
> ##   * If MSG_DEP_SET isn't empty the following dependencies might have
> been ##     pulled in transitively but can be declared for certainty
> nonetheless: ##     * add a build_depend tag for "message_generation"
> ##     * add a run_depend tag for "message_runtime"
> ## * In this file (CMakeLists.txt):
> ##   * add "message_generation" and every package in MSG_DEP_SET to
>      #find_package(catkin REQUIRED COMPONENTS actionlib_msgs geometry_msgs
> moveit_msgs )
> ##   * add "message_runtime" and every package in MSG_DEP_SET to
> ##     catkin_package(CATKIN_DEPENDS ...)
> ##   * uncomment the add_*_files sections below as needed
> ##     and list every .msg/.srv/.action file to be processed
> ##   * uncomment the generate_messages entry below
> ##   * add every package in MSG_DEP_SET to generate_messages(DEPENDENCIES
> ...)
> 
> ## Generate messages in the 'msg' folder
>  add_message_files(
>    FILES
>    instr_set_arm.msg
>    instr_set_legs.msg
>    object.msg
>  )
> 
> ## Generate services in the 'srv' folder
> # add_service_files(
> #   FILES
> #   Service1.srv
> #   Service2.srv
> # )
> 
> ## Generate actions in the 'action' folder
>  add_action_files(
>    FILES
>    arminstr.action
>    leginstr.action
>    objrecog_posit.action
>    sendcommand.action
> 
>  )
> 
> ## Generate added messages and services with any dependencies listed here
>  generate_messages(
>    DEPENDENCIES
>    actionlib_msgs
>    std_msgs
>    geometry_msgs
>    moveit_msgs
> 
>  )
> 
>  catkin_package(
>   CATKIN_DEPENDS
>   actionlib
>   actionlib_msgs
>   message_generation
>   roscpp
>   rospy
>   std_msgs
>   genmsg
>   visualization_msgs
>   clam_controller
>   clam_msgs
>   pcl_ros
>   cv_bridge
>   eigen_conversions
>   moveit_msgs
>   geometry_msgs
>   moveit_ros_planning
>   moveit_ros_planning_interface
>   tf
>   tf_conversions
>   moveit_simple_grasps
>   moveit_core
> #  INCLUDE_DIRS include
> )
> ###################################
> ## catkin specific configuration ##
> ###################################
> ## The catkin_package macro generates cmake config files for your package
> ## Declare things to be passed to dependent projects
> ## INCLUDE_DIRS: include/hal_main
> ## LIBRARIES: libraries you create in this project that dependent projects
> also need
> ## CATKIN_DEPENDS: catkin_packages dependent projects also need
> ## DEPENDS: system dependencies of this project that dependent projects
> also need
> catkin_package(
> #  INCLUDE_DIRS include include/hal_main
> ${CMAKE_INSTALL_PREFIX}/include/hal_main
> #  LIBRARIES hal_main
> #   CATKIN_DEPENDS actionlib actionlib_msgs message_generation roscpp rospy
> std_msgs message_runtime geometry_msgs moveit_msgs
> #  DEPENDS
> )
> 
> ###########
> ## Build ##
> ###########
> 
> ## Specify additional locations of header files
> ## Your package locations should be listed before other locations
> # include_directories(include)
> include_directories( ${catkin_INCLUDE_DIRS})
> include_directories( /usr/include/mysql ${MYSQL_INCLUDE_DIRS})
> add_definitions(${MYSQL_DEFINITIONS})
> link_directories(/usr/lib )
> #${MYSQL_LIBRARY_DIRS}
> include_directories(SYSTEM ${Boost_INCLUDE_DIR} ${EIGEN_INCLUDE_DIRS})
> 
> include_directories( ${OpenCV_INCLUDE_DIRS} /usr/include/opencv
> /usr/include/opencv2 )
> add_definitions(${OpenCV_DEFINITIONS})
> link_directories(${OpenCV_DIRECTORIES}   )
> link_libraries(${OpenCV_LIBS}libpthread.so.0  libopencv_calib3d.so)
> #link_libraries(${OpenCV_LIBS}libpthread.so.0 libopencv_calib3d.so)
> 
> #include_directories( ${OpenCV 2_INCLUDE_DIRS}  /usr/include/opencv2 )
> #add_definitions(${OpenCV 2_DEFINITIONS})
> #link_directories(/usr/local/lib/ )
> #link_libraries(${OpenCV 2_LIBRARIES} )
> 
> ## Declare a cpp library
> # add_library(hal_main
> #   src/${PROJECT_NAME}/hal_main.cpp
> # )
> 
> ## Declare a cpp executable
> add_executable(command_action_client src/commandclient.cpp)
> add_dependencies(command_action_client hal_main_generate_messages_cpp)
> target_link_libraries(command_action_client ${catkin_LIBRARIES})
> 
> #add_executable(command_action_server src/commandserver.cpp)
> #add_dependencies(command_action_server hal_main_generate_messages_cpp)
> #target_link_libraries(command_action_server ${MySQL_LIBRARIES}
> ${catkin_LIBRARIES})
> 
> if(MySQL_FOUND)
>     include_directories(${MySQL_INCLUDE_DIRS})
>     add_executable(command_action_server src/commandserver.cpp)
>     add_dependencies(command_action_server hal_main_generate_messages_cpp)
>     target_link_libraries(command_action_server ${MySQL_LIBRARIES})
> endif()
> 
> add_executable(arms_action_server src/arms_server.cpp)
> add_dependencies(arms_action_server hal_main_generate_messages_cpp)
> target_link_libraries(arms_action_server ${catkin_LIBRARIES})
> 
> if(OpenCV_FOUND)
>   include_directories(${OpenCV_INCLUDE_DIRS})
>   add_executable(object_recog_pos_server src/obj_recog_posit_server.cpp)
>   add_dependencies(object_recog_pos_server hal_main_generate_messages_cpp)
>   target_link_libraries(object_recog_pos_server ${OpenCV_LIBS} )
> endif()
> 
> ## Add cmake target dependencies of the executable/library
> ## as an example, message headers may need to be generated before nodes
> 
> ## Specify libraries to link a library or executable target against
> #target_link_libraries(tf_listener ${catkin_LIBRARIES})
> 
> #############
> ## Install ##
> #############
> 
> # all install targets should use catkin DESTINATION variables
> # See http://ros.org/doc/api/catkin/html/adv_user_guide/variables.html
> 
> ## Mark executable scripts (Python etc.) for installation
> ## in contrast to setup.py, you can choose the destination
> # install(PROGRAMS
> #   scripts/my_python_script
> #   DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
> # )
> 
> ## Mark executables and/or libraries for installation
> # install(TARGETS hal_main hal_main_node
> #   ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
> #   LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
> #   RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
> # )
> 
> ## Mark cpp header files for installation
> # install(DIRECTORY include/${PROJECT_NAME}/
> #   DESTINATION ${CATKIN_PACKAGE_INCLUDE_DESTINATION}
> #   FILES_MATCHING PATTERN "*.h"
> #   PATTERN ".svn" EXCLUDE
> # )
> 
> ## Mark other files for installation (e.g. launch and bag files, etc.)
> # install(FILES
> #   # myfile1
> #   # myfile2
> #   DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
> # )
> 
> #############
> ## Testing ##
> #############
> 
> ## Add gtest based cpp test target and link libraries
> # catkin_add_gtest(${PROJECT_NAME}-test test/test_hal_main.cpp)
> # if(TARGET ${PROJECT_NAME}-test)
> #   target_link_libraries(${PROJECT_NAME}-test ${PROJECT_NAME})
> # endif()
> 
> ## Add folders to be run by python nosetests
> # catkin_add_nosetests(test)
> 
> 
> 
> 
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/2-libs-stuck-together-tp7588712.html
> Sent from the CMake mailing list archive at Nabble.com.


From luc_j_bourhis at mac.com  Wed Oct 15 13:45:26 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Wed, 15 Oct 2014 10:45:26 -0700 (PDT)
Subject: [CMake] [CPack] RPM generator and directory symlink
Message-ID: <1413395126322-7588751.post@n2.nabble.com>

Hi,

I am trying to package a hierarchy with the following feature:



and subdir-version does indeed exist in that lib directory. CPack create a
specs featuring



but then rpmbuild chokes on it with an "error: not a directory:
/usr/local/lib/subdir". The %dir should not be there, should it?

This is with cpack 2.8.12.2 installed with yum on Fedora 20, and therefore
rpmbuild version 4.11.3.

Best wishes,

Luc J. Bourhis



-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751.html
Sent from the CMake mailing list archive at Nabble.com.

From luc_j_bourhis at mac.com  Wed Oct 15 13:47:15 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Wed, 15 Oct 2014 10:47:15 -0700 (PDT)
Subject: [CMake] [CPack] RPM generator and directory symlink
In-Reply-To: <1413395126322-7588751.post@n2.nabble.com>
References: <1413395126322-7588751.post@n2.nabble.com>
Message-ID: <1413395235952-7588752.post@n2.nabble.com>

Just to make it crystal clear, subdir-version is a directory!



-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751p7588752.html
Sent from the CMake mailing list archive at Nabble.com.

From luc_j_bourhis at mac.com  Wed Oct 15 13:34:03 2014
From: luc_j_bourhis at mac.com (Luc Bourhis)
Date: Wed, 15 Oct 2014 19:34:03 +0200
Subject: [CMake] [CPack] RPM generator and directory symlink
Message-ID: <4864B7F9-B647-4EC2-A9EC-D540EC186A92@mac.com>

Hi,

I am trying to package a hierarchy with the following feature:

~> cd ROOT/usr/local/lib
~> ls -l subdir
subdir -> subdir-version

and subdir-version does indeed exist in that lib directory. CPack create a specs featuring

%dir /usr/local/lib/subdir

but then rpmbuild chokes on it with an "error: not a directory: /usr/local/lib/subdir". The %dir should not be there, should it?

This is with cpack 2.8.12.2 installed with yum on Fedora 20, and therefore rpmbuild version 4.11.3.

Best wishes,

Luc J. Bourhis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2290 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141015/03f8fe4d/attachment-0001.bin>

From luc_j_bourhis at mac.com  Wed Oct 15 16:59:02 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Wed, 15 Oct 2014 13:59:02 -0700 (PDT)
Subject: [CMake] [CPack] RPM generator and directory symlink
In-Reply-To: <1413395126322-7588751.post@n2.nabble.com>
References: <1413395126322-7588751.post@n2.nabble.com>
Message-ID: <1413406742079-7588754.post@n2.nabble.com>

According to  the answer to this bug report
<https://bugzilla.redhat.com/show_bug.cgi?id=1005529>  , rpmbuild changed
the way it deals with 



when foo or bar are actually symlinks. So it looks like CPack 2.8.12 has not
been changed accordingly. This looks like bug report material, doesn't it?




-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751p7588754.html
Sent from the CMake mailing list archive at Nabble.com.

From domen.vrankar at gmail.com  Wed Oct 15 17:54:10 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Wed, 15 Oct 2014 23:54:10 +0200
Subject: [CMake] [CPack] RPM generator and directory symlink
In-Reply-To: <1413406742079-7588754.post@n2.nabble.com>
References: <1413395126322-7588751.post@n2.nabble.com>
 <1413406742079-7588754.post@n2.nabble.com>
Message-ID: <CAKgx6BKaSw34cTTnN97JLFoQEZuLf2jkK4JTFNA+ry0=kwXKog@mail.gmail.com>

Hi,

I'm assuming that you used something like:

install(CODE "
    EXECUTE_PROCESS(COMMAND ln -sf ${SOME_PATH}/subdir-version subdir
       WORKING_DIRECTORY ${LOCATION_WHERE_CPackRPM_IS_PACKAGING_YOUR_FILES}
       )
    " COMPONENT bin)

in your CMakeLists.txt

Currently CPackRPM doesn't automatically detect a symlink.

A workaround that you could use is to specify something like

set(CPACK_RPM_bin_USER_FILELIST "%config /subdir")

and this will force CPackRPM to treat the symlink as a config file.

Please file a bug report regarding CPackRPM treating symlinks to
directories as directories and not as symlinks.

Regards,
Domen


2014-10-15 22:59 GMT+02:00 Luc J. Bourhis <luc_j_bourhis at mac.com>:

> According to  the answer to this bug report
> <https://bugzilla.redhat.com/show_bug.cgi?id=1005529>  , rpmbuild changed
> the way it deals with
>
>
>
> when foo or bar are actually symlinks. So it looks like CPack 2.8.12 has
> not
> been changed accordingly. This looks like bug report material, doesn't it?
>
>
>
>
> -----
> --
> Luc J. Bourhis
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751p7588754.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141015/84afd07a/attachment.html>

From luc_j_bourhis at mac.com  Wed Oct 15 18:08:39 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Wed, 15 Oct 2014 15:08:39 -0700 (PDT)
Subject: [CMake] [CPack] RPM generator and directory symlink
In-Reply-To: <CAKgx6BKaSw34cTTnN97JLFoQEZuLf2jkK4JTFNA+ry0=kwXKog@mail.gmail.com>
References: <1413395126322-7588751.post@n2.nabble.com>
 <1413406742079-7588754.post@n2.nabble.com>
 <CAKgx6BKaSw34cTTnN97JLFoQEZuLf2jkK4JTFNA+ry0=kwXKog@mail.gmail.com>
Message-ID: <1413410919285-7588756.post@n2.nabble.com>

Thanks for your help!


Domen Vrankar wrote
> I'm assuming that you used something like:
> 
> install(CODE "
>     EXECUTE_PROCESS(COMMAND ln -sf ${SOME_PATH}/subdir-version subdir
>        WORKING_DIRECTORY
> ${LOCATION_WHERE_CPackRPM_IS_PACKAGING_YOUR_FILES}
>        )
>     " COMPONENT bin)

No, I used install(DIRECTORY ?). It was all built and installed using
External_Project. Thus the directory symlink was not created by my code.


Domen Vrankar wrote
> A workaround that you could use is to specify something like
> 
> set(CPACK_RPM_bin_USER_FILELIST "%config /subdir")
> 
> and this will force CPackRPM to treat the symlink as a config file.

What is the meaning of bin in the middle of that variable name?



-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751p7588756.html
Sent from the CMake mailing list archive at Nabble.com.

From dank at kegel.com  Wed Oct 15 21:49:00 2014
From: dank at kegel.com (Dan Kegel)
Date: Wed, 15 Oct 2014 18:49:00 -0700
Subject: [CMake] INSTALL DIRECTORY patterns highly confusing
Message-ID: <CAPF-yOb+udRxbTAg1wT0EgbCp1_bbEpGaJGgdrDXdniZ__Sp_Q@mail.gmail.com>

The doc could use some more examples.  I am having a hard
time figuring out how to install a directory tree but exclude
files matching .gitignore and Makefile.in.

From george.zagaris at gmail.com  Wed Oct 15 21:55:49 2014
From: george.zagaris at gmail.com (George Zagaris)
Date: Wed, 15 Oct 2014 18:55:49 -0700
Subject: [CMake] Specifying different compilers for subsets of a project
In-Reply-To: <543E3658.90307@astron.nl>
References: <CAA2FMY+TgoRWXCU2KwLgTN3Q9+PJqmP7-zLc4Yzaci7Z8SpSyQ@mail.gmail.com>
 <543E3658.90307@astron.nl>
Message-ID: <CAA2FMYKBZtcsEfPims+2hLzd_44fj2FLn94DZ810S+3bvvvAsw@mail.gmail.com>

Hi Marcel,

Thanks for your e-mail. I am not sure if your approach wil fully satisfy my
use case. I need to compile on both the back-end and front-end.

My question really boils down to whether it's possible to use two different
compilers for the same language within the same configuration.

I was hoping there would be a way to set properties on individual files or
directories and specify a different compiler (as one could specify
different compilers flags). Is that possible?

Perhaps, another alternative is to define a FRONTEND_C, FRONTEND_CXX and
FRONTEND_F90 languages, as well as, define associated
"add_frontend_executable()" and "add_frontend_library()", which would work
with the frontend compiler when we are cross-compiling, or call
"add_executable()" and "add_library" otherwise. This may be a bit of
overkill though (but very useful), given that only a relative small subset
of the project needs to be compiled for the front-end.

Is there a good guide on how would one could define a different language in
CMake?

I am curious if there are any other known alternatives?

Cheers,
George

On Wed, Oct 15, 2014 at 1:54 AM, Marcel Loose <loose at astron.nl> wrote:

>  Hi George,
>
> You could (ab)use the "assembler plugin" system for that. Define your own
> CMake-ASM-BGQ*.cmake files and use the assembler to compile the sources.
>
> Here's how I did this a couple of years ago for the BG/P.
>
> In the CMakeLists.txt file for the files that need to be compiled with the
> BG/P compiler I have:
>
> ## ---------------------------------------------------------------------------
> ## Enable BGP specific assembler.
> ## Use the BGP assembler also for linking C/C++ programs.
> ## ---------------------------------------------------------------------------
> enable_language(ASM-BGP)
> set(CMAKE_C_LINK_EXECUTABLE ${CMAKE_ASM-BGP_LINK_EXECUTABLE})
> set(CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_ASM-BGP_LINK_EXECUTABLE})
>
>
> CMakeASM-BGPInformation.cmake:
>
> set(ASM_DIALECT "-BGP")
> set(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS S)
> set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT "<CMAKE_ASM${ASM_DIALECT}_COMPILER> <DEFINES> <FLAGS> -c -o <OBJECT> <SOURCE>")
> set(CMAKE_ASM${ASM_DIALECT}_LINK_EXECUTABLE "<CMAKE_ASM${ASM_DIALECT}_COMPILER> <FLAGS> <LINK_FLAGS> <OBJECTS>  -o <TARGET> <LINK_LIBRARIES>")
> include(CMakeASMInformation)
> set(ASM_DIALECT)
>
>
> CMakeDetermineASM-BGPCompiler.cmake:
>
> set(ASM_DIALECT "-BGP")
> set(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT ${CMAKE_ASM_COMPILER})
> include(CMakeDetermineASMCompiler)
> set(ASM_DIALECT)
>
>
> CMakeTestASM-BGPCompiler.cmake:
>
> set(ASM_DIALECT "-BGP")
> include(CMakeTestASMCompiler)
> set(ASM_DIALECT)
>
>
> Hope this helps.
>
> Regards,
> Marcel Loose.
>
>
> On 15/10/14 04:23, George Zagaris wrote:
>
> Dear all,
>
>  I am working on a project where on certain platforms, namely, on a BG/Q
> or Cray, we have to cross-compile the code, but still, there are parts of
> the code that should only be compiled for the front end, login nodes.
>
>  Typically, we have a toolchain file, which among other things sets:
> - CMAKE_CXX_COMPILER
> - CMAKE_C_COMPILER
> - CMAKE_FORTRAN_COMPILER
>
>  to the respective cross-compilers available on the target platform.
>
>  This compiles everything for the back-end.
>
>  The obvious way to compile front-end tools is to create another
> directory, e.g., "front-end-build" and run cmake therein to re-configure
> and build with a front-end compiler.
>
>  However, since only a relatively small subset of the files needs to be
> compiled for the front-end, it is desirable to do this within the same
> build, which leads to my question:
>
>  Is it possible to tell CMake to build certain files with a different
> compiler? I know there is a way to set file properties to control the
> compiler flags of certain files. Is there a "blessed" approach to control
> the compiler for certain files and/or directories (and avoid things like
> set(CMAKE_CXX_COMPILER...) within a CMakeLists file)?
>
>  Thank you very much for all your help.
>
>  Best,
> George
>
>
>
>
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141015/8bf097ff/attachment.html>

From dank at kegel.com  Wed Oct 15 22:11:35 2014
From: dank at kegel.com (Dan Kegel)
Date: Wed, 15 Oct 2014 19:11:35 -0700
Subject: [CMake] INSTALL DIRECTORY patterns highly confusing
In-Reply-To: <CAPF-yOb+udRxbTAg1wT0EgbCp1_bbEpGaJGgdrDXdniZ__Sp_Q@mail.gmail.com>
References: <CAPF-yOb+udRxbTAg1wT0EgbCp1_bbEpGaJGgdrDXdniZ__Sp_Q@mail.gmail.com>
Message-ID: <CAPF-yObSGMjM3Y5vBpJ7F20C8PiBbN0fASONxPt=Vb+mpqpmwg@mail.gmail.com>

On Wed, Oct 15, 2014 at 6:49 PM, Dan Kegel <dank at kegel.com> wrote:
> The doc could use some more examples.  I am having a hard
> time figuring out how to install a directory tree but exclude
> files matching .gitignore and Makefile.in.

This turned out to work for me:

install (
  DIRECTORY ${samples_SOURCE_DIR}
  DESTINATION "src"
  PATTERN "*.in" EXCLUDE
  PATTERN ".gitignore" EXCLUDE
)

but lord help me, it took me the longest damn time.

From dank at kegel.com  Wed Oct 15 22:13:51 2014
From: dank at kegel.com (Dan Kegel)
Date: Wed, 15 Oct 2014 19:13:51 -0700
Subject: [CMake] INSTALL DIRECTORY patterns highly confusing
In-Reply-To: <CAPF-yObSGMjM3Y5vBpJ7F20C8PiBbN0fASONxPt=Vb+mpqpmwg@mail.gmail.com>
References: <CAPF-yOb+udRxbTAg1wT0EgbCp1_bbEpGaJGgdrDXdniZ__Sp_Q@mail.gmail.com>
 <CAPF-yObSGMjM3Y5vBpJ7F20C8PiBbN0fASONxPt=Vb+mpqpmwg@mail.gmail.com>
Message-ID: <CAPF-yOZu1_TtEFc2tKS_cb8s0yCs9ZQ+DsY=DMZjq7zeq=EP7g@mail.gmail.com>

> This turned out to work for me:
>
> install (
>   DIRECTORY ${samples_SOURCE_DIR}
>   DESTINATION "src"
>   PATTERN "*.in" EXCLUDE
>   PATTERN ".gitignore" EXCLUDE
> )

Here's one of my earlier attempts:

   PATTERN '*.in' EXCLUDE
   PATTERN 'CMakeLists.txt' EXCLUDE

Is it possible that single quotes cause silent failure?  Maybe those
could be flagged as likely errors.

From domen.vrankar at gmail.com  Thu Oct 16 03:06:41 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 16 Oct 2014 09:06:41 +0200
Subject: [CMake] [CPack] RPM generator and directory symlink
In-Reply-To: <1413410919285-7588756.post@n2.nabble.com>
References: <1413395126322-7588751.post@n2.nabble.com>
 <1413406742079-7588754.post@n2.nabble.com>
 <CAKgx6BKaSw34cTTnN97JLFoQEZuLf2jkK4JTFNA+ry0=kwXKog@mail.gmail.com>
 <1413410919285-7588756.post@n2.nabble.com>
Message-ID: <CAKgx6B+ehVzThoNtW+7MdxEayvLpGTM+79Dok1A9=RD18L=pUQ@mail.gmail.com>

> > A workaround that you could use is to specify something like
> >
> > set(CPACK_RPM_bin_USER_FILELIST "%config /subdir")
> >
> > and this will force CPackRPM to treat the symlink as a config file.
>
> What is the meaning of bin in the middle of that variable name?


CPACK_RPM_USER_FILELIST is used for non component packaging and
CPACK_RPM_<COMPONENT>_USER_FILELIST is used for component packaging so bin
is the same name as used in install command: COMPONENT bin.

Here is the documentation for it:
http://www.cmake.org/cmake/help/v2.8.8/cpack.html#variable:CPACK_RPM_USER_FILELIST
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141016/c9985fce/attachment.html>

From petr.kmoch at gmail.com  Thu Oct 16 03:25:03 2014
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 16 Oct 2014 09:25:03 +0200
Subject: [CMake] INSTALL DIRECTORY patterns highly confusing
In-Reply-To: <CAPF-yOZu1_TtEFc2tKS_cb8s0yCs9ZQ+DsY=DMZjq7zeq=EP7g@mail.gmail.com>
References: <CAPF-yOb+udRxbTAg1wT0EgbCp1_bbEpGaJGgdrDXdniZ__Sp_Q@mail.gmail.com>
 <CAPF-yObSGMjM3Y5vBpJ7F20C8PiBbN0fASONxPt=Vb+mpqpmwg@mail.gmail.com>
 <CAPF-yOZu1_TtEFc2tKS_cb8s0yCs9ZQ+DsY=DMZjq7zeq=EP7g@mail.gmail.com>
Message-ID: <CAKohaZehovBoT-hxrussKyQGtzzVH8EF8T=OEiht2iQuS1jPkQ@mail.gmail.com>

Hi Dan.

Single quotes have no special meaning in CMake syntax, so it was literally
treating them as part of the pattern. This is not special to the install()
command in any way, it's just how CMake works.

Petr

On Thu, Oct 16, 2014 at 4:13 AM, Dan Kegel <dank at kegel.com> wrote:

> > This turned out to work for me:
> >
> > install (
> >   DIRECTORY ${samples_SOURCE_DIR}
> >   DESTINATION "src"
> >   PATTERN "*.in" EXCLUDE
> >   PATTERN ".gitignore" EXCLUDE
> > )
>
> Here's one of my earlier attempts:
>
>    PATTERN '*.in' EXCLUDE
>    PATTERN 'CMakeLists.txt' EXCLUDE
>
> Is it possible that single quotes cause silent failure?  Maybe those
> could be flagged as likely errors.
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141016/e65f5b0e/attachment.html>

From j.kreuzberger at procitec.de  Thu Oct 16 05:26:55 2014
From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=)
Date: Thu, 16 Oct 2014 11:26:55 +0200
Subject: [CMake] Philosophy with Tests for Beginners
Message-ID: <zarafa.543f8f5f.3637.56a2955734668551@zarafa.procitec.de>

Hi!

I have a question regarding handling with tests.
currently my sources are build together with tests. the tests in the binary location could be executed via make test or ctest. So far so good.

Considering our Jenkins / Build Configurations i want to seperate build and tests. That means i want to build the tests with JOB A and execute them on JOB B.
So i have to bring the tests from A to B.
This could i do if i e.g. install the tests (adding install command in CMakeLists) and execute them and find them via scripts.

Is there another solution (e.g. undocumented CMAKE_PACKAGE_TEST ) or another approach that solves my problem in a way that i can use e.g. ctest in the other jobs too?

Other questions is about handling "extra files". So i have for example a test which relies on a test file. Currently i copy it as PRE_BUILD step into the tests binary dir, so it is available on test execution. Is there a better approach without using an install step?


From philipp.schroeter at charite.de  Thu Oct 16 06:17:38 2014
From: philipp.schroeter at charite.de (=?ISO-8859-15?Q?Philipp_Schr=F6ter?=)
Date: Thu, 16 Oct 2014 12:17:38 +0200
Subject: [CMake] Tests not added to CTestTestfile.cmake on OS X
Message-ID: <543F9B42.3000708@charite.de>

Dear all,

I'm encountering a problem when adding tests with add_test for CTest on 
OS X 10.9.4. The CTestTestfile.cmake, which should contain the tests, 
only has the header, but is empty otherwise (the ones in the directories 
above, just include the other directories correctly).
On Windows with Visual Studio all runs fine.

The code looks like this

include_directories(${Boost_INCLUDE})

add_executable(Basic-Tests MACOSX_BUNDLE Vector-Test.cpp)
target_link_libraries(Basic-Tests Basic ${Boost_LIBRARIES})
SET_PROPERTY(TARGET Basic-Tests PROPERTY FOLDER "Tests")
if(Darwin OR APPLE)
    add_test(NAME Basic-Debug-Tests
             CONFIGURATIONS Debug-iphonesimulator
             COMMAND 
"${CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG}/Basic-Tests.app/Basic-Tests" 
${test_parameters} --log_sink=${test_log}/Basic-Tests.xml)
    add_test(NAME Basic-Release-Tests
             CONFIGURATIONS Release-iphonesimulator
             COMMAND 
"${CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE}/Basic-Tests.app/Basic-Tests" 
${test_parameters} --log_sink=${test_log}/Basic-Tests.xml)
else()
    add_test(NAME Basic-Debug-Tests
             CONFIGURATIONS Debug
             COMMAND 
"${CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG}/Basic-Tests" ${test_parameters} 
--log_sink=${test_log}/Basic-Tests.xml)
    add_test(NAME Basic-Release-Tests
             CONFIGURATIONS Release
             COMMAND 
"${CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE}/Basic-Tests" 
${test_parameters} --log_sink=${test_log}/Basic-Tests.xml)
endif()

CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG and 
CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE are set to 
${CMAKE_BINARY_DIR}/Debug/bin and ${CMAKE_BINARY_DIR}/Release/bin before 
the call of add_test (and it is known at this location). The files and 
locations are correct as far as I can see (e.g. when printed as a message).
test_parameters are some arguments for the test runner (I use the Boost 
Test Framework).
enable_testing() is called in the CMakeLists.txt in the the top level 
source directory.

So far, I tried different configurations (Debug and Release, 
Release-iphoneos), checked the COMMAND argument and I also tried to use 
a single test with the same name as the executable target instead of two 
seperate ones.
The tests themselves are build correctly and do run with CTest, if they 
are added manually (and the file is not overwritten before the tests run).

I am not sure, what the problem exactly is and what else to try to get 
to the root of it (or just to solve it). Thank you very much for all 
your help.

Best regards,
Philipp

PS: The CMake version on the Mac system is 3.0.0

From dank at kegel.com  Thu Oct 16 09:29:34 2014
From: dank at kegel.com (Dan Kegel)
Date: Thu, 16 Oct 2014 06:29:34 -0700
Subject: [CMake] INSTALL DIRECTORY patterns highly confusing
In-Reply-To: <CAKohaZehovBoT-hxrussKyQGtzzVH8EF8T=OEiht2iQuS1jPkQ@mail.gmail.com>
References: <CAPF-yOb+udRxbTAg1wT0EgbCp1_bbEpGaJGgdrDXdniZ__Sp_Q@mail.gmail.com>
 <CAPF-yObSGMjM3Y5vBpJ7F20C8PiBbN0fASONxPt=Vb+mpqpmwg@mail.gmail.com>
 <CAPF-yOZu1_TtEFc2tKS_cb8s0yCs9ZQ+DsY=DMZjq7zeq=EP7g@mail.gmail.com>
 <CAKohaZehovBoT-hxrussKyQGtzzVH8EF8T=OEiht2iQuS1jPkQ@mail.gmail.com>
Message-ID: <CAPF-yOZ5TGnNDMfgZQxY1SBBM1-dvxOOyGtKsjXFRy_ym3KnMw@mail.gmail.com>

Of course.  The problem comes when somebody is used to languages that
encourage single-quoted strings (e.g. python or shell) or which have tight
syntax and abort on mistakes like this.

This lack of early feedback coupled with the terse doc and strange
semantics means that when something doesn't work, the user has a hard time
figuring out what kind of mistake he made.
 Am 16.10.2014 00:25 schrieb "Petr Kmoch" <petr.kmoch at gmail.com>:

> Hi Dan.
>
> Single quotes have no special meaning in CMake syntax, so it was literally
> treating them as part of the pattern. This is not special to the install()
> command in any way, it's just how CMake works.
>
> Petr
>
> On Thu, Oct 16, 2014 at 4:13 AM, Dan Kegel <dank at kegel.com> wrote:
>
>> > This turned out to work for me:
>> >
>> > install (
>> >   DIRECTORY ${samples_SOURCE_DIR}
>> >   DESTINATION "src"
>> >   PATTERN "*.in" EXCLUDE
>> >   PATTERN ".gitignore" EXCLUDE
>> > )
>>
>> Here's one of my earlier attempts:
>>
>>    PATTERN '*.in' EXCLUDE
>>    PATTERN 'CMakeLists.txt' EXCLUDE
>>
>> Is it possible that single quotes cause silent failure?  Maybe those
>> could be flagged as likely errors.
>> --
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141016/ae39742c/attachment.html>

From luc_j_bourhis at mac.com  Thu Oct 16 10:53:01 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Thu, 16 Oct 2014 07:53:01 -0700 (PDT)
Subject: [CMake] [CPack] RPM generator and directory symlink
In-Reply-To: <CAKgx6B+ehVzThoNtW+7MdxEayvLpGTM+79Dok1A9=RD18L=pUQ@mail.gmail.com>
References: <1413395126322-7588751.post@n2.nabble.com>
 <1413406742079-7588754.post@n2.nabble.com>
 <CAKgx6BKaSw34cTTnN97JLFoQEZuLf2jkK4JTFNA+ry0=kwXKog@mail.gmail.com>
 <1413410919285-7588756.post@n2.nabble.com>
 <CAKgx6B+ehVzThoNtW+7MdxEayvLpGTM+79Dok1A9=RD18L=pUQ@mail.gmail.com>
Message-ID: <1413471181265-7588766.post@n2.nabble.com>

Just to confirm that your suggestion does indeed work. I did it without
specifying a component since the RPM generator does not have that feature
switched on by default iirc:


Thanks!





-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751p7588766.html
Sent from the CMake mailing list archive at Nabble.com.

From luc_j_bourhis at mac.com  Thu Oct 16 10:54:39 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Thu, 16 Oct 2014 07:54:39 -0700 (PDT)
Subject: [CMake] [CPack] RPM generator and directory symlink
In-Reply-To: <CAKgx6B+ehVzThoNtW+7MdxEayvLpGTM+79Dok1A9=RD18L=pUQ@mail.gmail.com>
References: <1413395126322-7588751.post@n2.nabble.com>
 <1413406742079-7588754.post@n2.nabble.com>
 <CAKgx6BKaSw34cTTnN97JLFoQEZuLf2jkK4JTFNA+ry0=kwXKog@mail.gmail.com>
 <1413410919285-7588756.post@n2.nabble.com>
 <CAKgx6B+ehVzThoNtW+7MdxEayvLpGTM+79Dok1A9=RD18L=pUQ@mail.gmail.com>
Message-ID: <298F315D-DADA-44FE-BE8C-4FE3DB2DA515@mac.com>

Thanks a bunch! I was gonna miss a deadline because of that issue and you really saved the day!


On 16 Oct 2014, at 09:06, Domen Vrankar [via CMake] <ml-node+s3232098n7588761h51 at n2.nabble.com> wrote:

> 
> > A workaround that you could use is to specify something like
> >
> > set(CPACK_RPM_bin_USER_FILELIST "%config /subdir")
> >
> > and this will force CPackRPM to treat the symlink as a config file.
> 
> What is the meaning of bin in the middle of that variable name?
> 
> CPACK_RPM_USER_FILELIST is used for non component packaging and CPACK_RPM_<COMPONENT>_USER_FILELIST is used for component packaging so bin is the same name as used in install command: COMPONENT bin.
> 
> Here is the documentation for it:
> http://www.cmake.org/cmake/help/v2.8.8/cpack.html#variable:CPACK_RPM_USER_FILELIST
> 
> -- 
> 
> 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 
> 
> If you reply to this email, your message will be added to the discussion below:
> http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751p7588761.html
> To unsubscribe from [CPack] RPM generator and directory symlink, click here.
> NAML



smime.p7s (3K) <http://cmake.3232098.n2.nabble.com/attachment/7588767/0/smime.p7s>




-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-and-directory-symlink-tp7588751p7588767.html
Sent from the CMake mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141016/6d50fdbd/attachment.html>

From Philipp.Schroeter at charite.de  Thu Oct 16 12:16:29 2014
From: Philipp.Schroeter at charite.de (=?iso-8859-1?Q?=22Schr=F6ter=2C_Philipp=22?=)
Date: Thu, 16 Oct 2014 18:16:29 +0200
Subject: [CMake] Tests not added to CTestTestfile.cmake on OS X
In-Reply-To: <mailman.6607.1413471185.4706.cmake@cmake.org>
References: <mailman.6607.1413471185.4706.cmake@cmake.org>
Message-ID: <5D4380F254B76A4FBD49DD64B65CD074F8188AA038@EXCHANGE11.charite.de>

Hello again,

I have fixed this issue. Using Debug and Release as configuration did create the tests correctly, I just didn't notice it. So the problem was Debug-/Release-iphonesimulator as configuration.
When CTest is run by XCode and using the iPhone Simulator SDK, "-iphonesimulator" is attached to the configuration used (either Debug or Release). Now the tests are run by CTest directly and not through XCode, which fixes this, too.

Best regards,
Philipp

From chuck.atkins at kitware.com  Thu Oct 16 14:32:13 2014
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Oct 2014 14:32:13 -0400
Subject: [CMake] Specifying different compilers for subsets of a project
In-Reply-To: <CAA2FMY+TgoRWXCU2KwLgTN3Q9+PJqmP7-zLc4Yzaci7Z8SpSyQ@mail.gmail.com>
References: <CAA2FMY+TgoRWXCU2KwLgTN3Q9+PJqmP7-zLc4Yzaci7Z8SpSyQ@mail.gmail.com>
Message-ID: <CAOXZzG6k7amxSzRYXKPuOBt3yNXc5dE+ScR8Th9VqkgfU77swg@mail.gmail.com>

Hi George,


> The obvious way to compile front-end tools is to create another directory,
> e.g., "front-end-build" and run cmake therein to re-configure and build
> with a front-end compiler.
>

> However, since only a relatively small subset of the files needs to be
> compiled for the front-end, it is desirable to do this within the same build
>

This is a common case that occurs when cross compiling where certain
targets are used to generate files used in the rest of the build.  Using
different build directories is the typical way, but you can reduce the host
build as much a possible by creating a BuildTools or CrossTools custom
target with depends only on the targets needing to be build on the host
system. This way, you can build only the subset needed on the host and in
the cross-build, just point the host build directory.  This is how both VTK
and ParaView do it.

Trying to specify multiple compilers isn't so straight forward.  Consider
the entire platform that goes in to cross compiling: you have the entire
build toolset, but then you also have the entire find infrastructure that
needs to look in different places for includes and libraries.  There's an
entire stack of variables, tools, and settings that are needed to build on
a given platform and you would basically need a whole duplicate set
generated from a secondary configure run to make it work in the general
case.  This is what is effectively happening anyways in the two-builds
scenario.

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141016/f303a306/attachment.html>

From clinton at elemtech.com  Thu Oct 16 16:36:12 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Thu, 16 Oct 2014 14:36:12 -0600
Subject: [CMake] cache variables from compiler checks
Message-ID: <10792580.dHTASbpanI@stryke>


I noticed something odd...

If I delete the cache variable CMAKE_STRIP, then re-run cmake, it doesn't come 
back.
If I delete the build/CMakeFiles directory, re-run cmake, it'll come back.

Is that intentional?

I have a dashboard build where I was re-configuring with a different initial 
CMakeCache.txt file, and some of the variables don't come back.  Looks like 
I'll also need to remove the CMakeFiles directory while I write the 
CMakeLists.txt file.

Clint

From george.zagaris at gmail.com  Thu Oct 16 21:54:00 2014
From: george.zagaris at gmail.com (George Zagaris)
Date: Thu, 16 Oct 2014 18:54:00 -0700
Subject: [CMake] Specifying different compilers for subsets of a project
In-Reply-To: <CAOXZzG6k7amxSzRYXKPuOBt3yNXc5dE+ScR8Th9VqkgfU77swg@mail.gmail.com>
References: <CAA2FMY+TgoRWXCU2KwLgTN3Q9+PJqmP7-zLc4Yzaci7Z8SpSyQ@mail.gmail.com>
 <CAOXZzG6k7amxSzRYXKPuOBt3yNXc5dE+ScR8Th9VqkgfU77swg@mail.gmail.com>
Message-ID: <CAA2FMY+81HPs0S+gxa-f=NTSbQjCvj_=Foj=WcnpqG2qpWKC6w@mail.gmail.com>

Hi Chuck,

Thanks for your e-mail.

Yes, the different build directory strategy is definitely the clean way to
do this.

However, it is my experience that folks not familiar with CMake tend to get
a knee-jerk reaction when required to configure and build seperately.
Especially, when something like this is more easily hacked in raw
Makefiles, for example. Hence, I am investigating various alternatives to
contrast with the nominal separate build directory strategy.

I really like the custom target suggestion -- makes perfect sense.

Best,
George

On Thu, Oct 16, 2014 at 11:32 AM, Chuck Atkins <chuck.atkins at kitware.com>
wrote:

> Hi George,
>
>
>> The obvious way to compile front-end tools is to create another
>> directory, e.g., "front-end-build" and run cmake therein to re-configure
>> and build with a front-end compiler.
>>
>
>> However, since only a relatively small subset of the files needs to be
>> compiled for the front-end, it is desirable to do this within the same build
>>
>
> This is a common case that occurs when cross compiling where certain
> targets are used to generate files used in the rest of the build.  Using
> different build directories is the typical way, but you can reduce the host
> build as much a possible by creating a BuildTools or CrossTools custom
> target with depends only on the targets needing to be build on the host
> system. This way, you can build only the subset needed on the host and in
> the cross-build, just point the host build directory.  This is how both VTK
> and ParaView do it.
>
> Trying to specify multiple compilers isn't so straight forward.  Consider
> the entire platform that goes in to cross compiling: you have the entire
> build toolset, but then you also have the entire find infrastructure that
> needs to look in different places for includes and libraries.  There's an
> entire stack of variables, tools, and settings that are needed to build on
> a given platform and you would basically need a whole duplicate set
> generated from a secondary configure run to make it work in the general
> case.  This is what is effectively happening anyways in the two-builds
> scenario.
>
> - Chuck
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141016/c3bdaa77/attachment.html>

From rcdailey.lists at gmail.com  Thu Oct 16 22:37:06 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 16 Oct 2014 21:37:06 -0500
Subject: [CMake] Interface include directories
Message-ID: <CAHd499Av=JRroNOPcHrj+=949G1L803YyOn=K9y8btjnfOaT6w@mail.gmail.com>

I'm ramping up on CMake 3.0 and I like that you've added
INTERFACE_INCLUDE_DIRECTORIES. Is this automatic when I add a
dependency on another target? For example, suppose I have two targets
A and B. And in my target link libraries for B, I specify A. B now
depends on A. Will I also inherit its interface include directories or
do I have to do that manually?

From rcdailey.lists at gmail.com  Fri Oct 17 01:18:34 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 17 Oct 2014 00:18:34 -0500
Subject: [CMake] Is this the proper way to define a package config?
Message-ID: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>

I have a local package of boost built on Windows. It is always
relative to the root of my project at a consistent structure and
location. I wanted to define an import target for this and thought it
might be best to define a BoostConfig.cmake package config file at the
root of the boost lib directory. Is this the right approach? The code
is below.

Note that I do not have this working just yet because I don't know how
to properly setup the interface link libraries. Could use some
guidance here too... thanks.

add_library( Boost STATIC IMPORTED GLOBAL )

file( GLOB boost_debug_libs ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib )
file( GLOB boost_release_libs
${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )

set_target_properties( Boost PROPERTIES
    IMPORTED_LOCATION_DEBUG lib/win32/debug
    IMPORTED_LOCATION_RELEASE lib/win32/release
    INTERFACE_INCLUDE_DIRECTORIES include
    INTERFACE_LINK_LIBRARIES
        $<$<CONFIG:Debug>:${boost_debug_libs}>
        $<$<CONFIG:Release>:${boost_release_libs}>
)

set( Boost_INCLUDE_DIRS include )
set( Boost_LIBRARIES Boost )

From robert.maynard at kitware.com  Fri Oct 17 10:33:12 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 17 Oct 2014 10:33:12 -0400
Subject: [CMake] Interface include directories
In-Reply-To: <CAHd499Av=JRroNOPcHrj+=949G1L803YyOn=K9y8btjnfOaT6w@mail.gmail.com>
References: <CAHd499Av=JRroNOPcHrj+=949G1L803YyOn=K9y8btjnfOaT6w@mail.gmail.com>
Message-ID: <CAFzjYVpGwwUEzuyav7cvnQhAX8M8g0YUtc45bvONSy16kpEz2Q@mail.gmail.com>

They will be inherited based on the linking types ( PUBLIC, PRIVATE,
INTERFACE). The build specification and usage requirements section of cmake
buildsystem documentation is a great introduction to how this all works.
You can read it at:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html

On Thu, Oct 16, 2014 at 10:37 PM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> I'm ramping up on CMake 3.0 and I like that you've added
> INTERFACE_INCLUDE_DIRECTORIES. Is this automatic when I add a
> dependency on another target? For example, suppose I have two targets
> A and B. And in my target link libraries for B, I specify A. B now
> depends on A. Will I also inherit its interface include directories or
> do I have to do that manually?
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141017/7dc1407a/attachment.html>

From filipe.c.maia at gmail.com  Tue Oct 21 12:52:58 2014
From: filipe.c.maia at gmail.com (Filipe Maia)
Date: Tue, 21 Oct 2014 18:52:58 +0200
Subject: [CMake] Installation corrupts library on OS X
In-Reply-To: <7162180.XNoJrk3aCc@stryke>
References: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
 <1939272.lNxsrSxB3M@stryke>
 <2B019054-27DB-4496-A175-5203664B97B8@stanford.edu>
 <7162180.XNoJrk3aCc@stryke>
Message-ID: <CAN5hRiU4DNeODdjGx=ydf4dhGu=DV-DMGFvK-h+qxiRD74qfyw@mail.gmail.com>

CMake's FindCUDA.cmake module adds the rpath when run on Mac OSX
(from FindCUDA.cmake):

if(APPLE)
  # We need to add the path to cudart to the linker using rpath, since the
  # library name for the cuda libraries is prepended with @rpath.
  if(CUDA_BUILD_EMULATION AND CUDA_CUDARTEMU_LIBRARY)
    get_filename_component(_cuda_path_to_cudart "${CUDA_CUDARTEMU_LIBRARY}"
PATH)
  else()
    get_filename_component(_cuda_path_to_cudart "${CUDA_CUDART_LIBRARY}"
PATH)
  endif()
  if(_cuda_path_to_cudart)
    list(APPEND CUDA_LIBRARIES -Wl,-rpath "-Wl,${_cuda_path_to_cudart}")
  endif()
endif()

This causes this problem for anything built with CUDA support
(e.g. CUDA_ADD_EXECUTABLE), by having one rpath from the CUDA module and
another one from cmake trying its automagic.
The rpath should probably be removed from the module.

Filipe

On Tue, Oct 14, 2014 at 9:56 PM, Clinton Stimpson <clinton at elemtech.com>
wrote:

> On Tuesday, October 14, 2014 12:10:36 PM Peter Eastman wrote:
> > Hi Clint,
> >
> > In my case, it wasn't anything like that.  I was only specifying
> > /usr/local/cuda/lib once.  More specifically, my CMakeLists.txt specified
> >
> > TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})
> >
> > where CUDA_LIBRARIES is
> >
> > /usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib
>
> Since CMake 2.8.12, CMake will automatically figure out the
> -Wl,-rpath-Wl,/usr/local/cuda/lib part for
> /usr/local/cuda/lib/libcudart.dylib.
>
> So, the duplicate comes from CMake adding it once, and you adding it once.
>
> You should be able to remove any -Wl,-rpath flags that you add manually
> with
> CMake 2.8.12 and newer, and let CMake take care of that for you.
>
> >
> > This library also linked against another of my libraries, that also
> happened
> > to link against CUDA.  So that's why it was getting referenced twice:
> once
> > directly, and once indirectly via a second library.
> >
> > In any case, it's not clear to me why CMake is calling "install_name_tool
> > -delete_rpath".  Everything works fine without doing that.  And when you
> do
> > it, that breaks things.
>
> CMake calls "install_name_tool -delete_rpath" at install time to remove the
> build rpaths and add install rpaths as specified by the INSTALL_RPATH
> target
> property.
>
> For more details and examples:
> http://www.kitware.com/blog/home/post/510
> http://www.cmake.org/Wiki/CMake_RPATH_handling
>
> Clint
>
> >
> > Peter
> >
> > On Oct 14, 2014, at 11:06 AM, Clinton Stimpson <clinton at elemtech.com>
> wrote:
> > > Here's a simple way to reproduce from the command line:
> > >
> > > echo "void foo() {}" > lib.c
> > > gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib
> -Wl,-rpath,/usr/lib
> > > lib.c install_name_tool -delete_rpath /usr/lib libtest.dylib
> > > otool -L libtest.dylib
> > >
> > >  # gives me the error: "load command 13 size zero (can't advance to
> other
> > >
> > > load commands)"
> > >
> > > At install time, CMake will call "install_name_tool -delete_rpath ...
> " as
> > > needed.
> > >
> > > I can't get into Apple's bug tracker.  I don't know why.  When I try to
> > > log
> > > in, it comes back with a generic error and it asks me to email them
> with
> > > details about the error.
> > >
> > > When I do the same on Linux, the GNU linker will consolidate the
> duplicate
> > > paths.
> > >
> > > Thanks!
> > >
> > > Clint
>
> --
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141021/7c21b0c1/attachment.html>

From clinton at elemtech.com  Tue Oct 21 13:31:00 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 21 Oct 2014 11:31 -0600
Subject: [CMake] Installation corrupts library on OS X
In-Reply-To: <CAN5hRiU4DNeODdjGx=ydf4dhGu=DV-DMGFvK-h+qxiRD74qfyw@mail.gmail.com>
References: <022A1888-ABD8-44AC-99A6-003B9CC5373D@stanford.edu>
 <7162180.XNoJrk3aCc@stryke>
 <CAN5hRiU4DNeODdjGx=ydf4dhGu=DV-DMGFvK-h+qxiRD74qfyw@mail.gmail.com>
Message-ID: <7178808.S9PRIGF5d5@stryke>

On Tuesday, October 21, 2014 06:52:58 PM Filipe Maia wrote:
> CMake's FindCUDA.cmake module adds the rpath when run on Mac OSX
> (from FindCUDA.cmake):
> 
> if(APPLE)
>   # We need to add the path to cudart to the linker using rpath, since the
>   # library name for the cuda libraries is prepended with @rpath.
>   if(CUDA_BUILD_EMULATION AND CUDA_CUDARTEMU_LIBRARY)
>     get_filename_component(_cuda_path_to_cudart "${CUDA_CUDARTEMU_LIBRARY}"
> PATH)
>   else()
>     get_filename_component(_cuda_path_to_cudart "${CUDA_CUDART_LIBRARY}"
> PATH)
>   endif()
>   if(_cuda_path_to_cudart)
>     list(APPEND CUDA_LIBRARIES -Wl,-rpath "-Wl,${_cuda_path_to_cudart}")
>   endif()
> endif()
> 
> This causes this problem for anything built with CUDA support
> (e.g. CUDA_ADD_EXECUTABLE), by having one rpath from the CUDA module and
> another one from cmake trying its automagic.
> The rpath should probably be removed from the module.

Oh!  It comes from Modules/FindCUDA.cmake.  That does need fixed.
Does the attached patch fix your problem?

Clint



> On Tue, Oct 14, 2014 at 9:56 PM, Clinton Stimpson <clinton at elemtech.com>
> 
> wrote:
> > On Tuesday, October 14, 2014 12:10:36 PM Peter Eastman wrote:
> > > Hi Clint,
> > > 
> > > In my case, it wasn't anything like that.  I was only specifying
> > > /usr/local/cuda/lib once.  More specifically, my CMakeLists.txt
> > > specified
> > > 
> > > TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})
> > > 
> > > where CUDA_LIBRARIES is
> > > 
> > > /usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib
> > 
> > Since CMake 2.8.12, CMake will automatically figure out the
> > -Wl,-rpath-Wl,/usr/local/cuda/lib part for
> > /usr/local/cuda/lib/libcudart.dylib.
> > 
> > So, the duplicate comes from CMake adding it once, and you adding it once.
> > 
> > You should be able to remove any -Wl,-rpath flags that you add manually
> > with
> > CMake 2.8.12 and newer, and let CMake take care of that for you.
> > 
> > > This library also linked against another of my libraries, that also
> > 
> > happened
> > 
> > > to link against CUDA.  So that's why it was getting referenced twice:
> > once
> > 
> > > directly, and once indirectly via a second library.
> > > 
> > > In any case, it's not clear to me why CMake is calling
> > > "install_name_tool
> > > -delete_rpath".  Everything works fine without doing that.  And when you
> > 
> > do
> > 
> > > it, that breaks things.
> > 
> > CMake calls "install_name_tool -delete_rpath" at install time to remove
> > the
> > build rpaths and add install rpaths as specified by the INSTALL_RPATH
> > target
> > property.
> > 
> > For more details and examples:
> > http://www.kitware.com/blog/home/post/510
> > http://www.cmake.org/Wiki/CMake_RPATH_handling
> > 
> > Clint
> > 
> > > Peter
> > > 
> > > On Oct 14, 2014, at 11:06 AM, Clinton Stimpson <clinton at elemtech.com>
> > 
> > wrote:
> > > > Here's a simple way to reproduce from the command line:
> > > > 
> > > > echo "void foo() {}" > lib.c
> > > > gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib
> > 
> > -Wl,-rpath,/usr/lib
> > 
> > > > lib.c install_name_tool -delete_rpath /usr/lib libtest.dylib
> > > > otool -L libtest.dylib
> > > > 
> > > >  # gives me the error: "load command 13 size zero (can't advance to
> > 
> > other
> > 
> > > > load commands)"
> > > > 
> > > > At install time, CMake will call "install_name_tool -delete_rpath ...
> > 
> > " as
> > 
> > > > needed.
> > > > 
> > > > I can't get into Apple's bug tracker.  I don't know why.  When I try
> > > > to
> > > > log
> > > > in, it comes back with a generic error and it asks me to email them
> > 
> > with
> > 
> > > > details about the error.
> > > > 
> > > > When I do the same on Linux, the GNU linker will consolidate the
> > 
> > duplicate
> > 
> > > > paths.
> > > > 
> > > > Thanks!
> > > > 
> > > > Clint
> > 
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com
> > --
> > 
> > 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
-------------- next part --------------
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 2e2b21c..3dd975c 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -703,18 +703,6 @@ if(CUDA_BUILD_EMULATION AND CUDA_CUDARTEMU_LIBRARY)
 else()
   set(CUDA_LIBRARIES ${CUDA_CUDART_LIBRARY})
 endif()
-if(APPLE)
-  # We need to add the path to cudart to the linker using rpath, since the
-  # library name for the cuda libraries is prepended with @rpath.
-  if(CUDA_BUILD_EMULATION AND CUDA_CUDARTEMU_LIBRARY)
-    get_filename_component(_cuda_path_to_cudart "${CUDA_CUDARTEMU_LIBRARY}" PATH)
-  else()
-    get_filename_component(_cuda_path_to_cudart "${CUDA_CUDART_LIBRARY}" PATH)
-  endif()
-  if(_cuda_path_to_cudart)
-    list(APPEND CUDA_LIBRARIES -Wl,-rpath "-Wl,${_cuda_path_to_cudart}")
-  endif()
-endif()
 
 # 1.1 toolkit on linux doesn't appear to have a separate library on
 # some platforms.

From luc_j_bourhis at mac.com  Wed Oct 22 07:14:26 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Wed, 22 Oct 2014 04:14:26 -0700 (PDT)
Subject: [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx
Message-ID: <1413976466922-7588778.post@n2.nabble.com>

With

install(FILES xxxxx DESTINATION /usr/local/bin)

CPack 2.8.12 generates a specs file featuring

%dir "/usr/local"
%dir "/usr/local/bin"

Then rpm -i the generated rpm file fails on Fedora 20 with 

	file /usr/local from install of
simple-install-in-usr-local-bin-0.1.1-1.i686 conflicts with file from
package filesystem-3.2-19.fc20.i686
	file /usr/local/bin from install of
simple-install-in-usr-local-bin-0.1.1-1.i686 conflicts with file from
package filesystem-3.2-19.fc20.i686

What is it I am missing?




-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPack-RPM-generator-creates-dir-for-usr-local-xxx-tp7588778.html
Sent from the CMake mailing list archive at Nabble.com.

From bill at classdesign.com  Wed Oct 22 07:20:46 2014
From: bill at classdesign.com (Bill Somerville)
Date: Wed, 22 Oct 2014 12:20:46 +0100
Subject: [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx
In-Reply-To: <1413976466922-7588778.post@n2.nabble.com>
References: <1413976466922-7588778.post@n2.nabble.com>
Message-ID: <5447930E.801@classdesign.com>

On 22/10/2014 12:14, Luc J. Bourhis wrote:

Hi Luc,
> With
>
> install(FILES xxxxx DESTINATION /usr/local/bin)
>
> CPack 2.8.12 generates a specs file featuring
>
> %dir "/usr/local"
> %dir "/usr/local/bin"
>
> Then rpm -i the generated rpm file fails on Fedora 20 with
>
> 	file /usr/local from install of
> simple-install-in-usr-local-bin-0.1.1-1.i686 conflicts with file from
> package filesystem-3.2-19.fc20.i686
> 	file /usr/local/bin from install of
> simple-install-in-usr-local-bin-0.1.1-1.i686 conflicts with file from
> package filesystem-3.2-19.fc20.i686
>
> What is it I am missing?
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
>
>
>
> -----
> --
> Luc J. Bourhis
Regards
Bill.

From eric.noulard at gmail.com  Wed Oct 22 07:42:20 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 22 Oct 2014 13:42:20 +0200
Subject: [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx
In-Reply-To: <5447930E.801@classdesign.com>
References: <1413976466922-7588778.post@n2.nabble.com>
 <5447930E.801@classdesign.com>
Message-ID: <CAPASGLoq+H+HLgHtaMQRS0EoLqqptQaafhEOk3_xXTVmuVzhQQ@mail.gmail.com>

2014-10-22 13:20 GMT+02:00 Bill Somerville <bill at classdesign.com>:

> On 22/10/2014 12:14, Luc J. Bourhis wrote:
>
> Hi Luc,
>
>> With
>>
>> install(FILES xxxxx DESTINATION /usr/local/bin)
>>
>> CPack 2.8.12 generates a specs file featuring
>>
>> %dir "/usr/local"
>> %dir "/usr/local/bin"
>>
>> Then rpm -i the generated rpm file fails on Fedora 20 with
>>
>>         file /usr/local from install of
>> simple-install-in-usr-local-bin-0.1.1-1.i686 conflicts with file from
>> package filesystem-3.2-19.fc20.i686
>>         file /usr/local/bin from install of
>> simple-install-in-usr-local-bin-0.1.1-1.i686 conflicts with file from
>> package filesystem-3.2-19.fc20.i686
>>
>> What is it I am missing?
>>
> CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
>

More docs on this for 2.8.12:

http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION

I guess that "/usr/local" may be added to
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values.

For Domen: see the history of this story here:
http://public.kitware.com/Bug/view.php?id=13609

-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141022/39438c42/attachment.html>

From hobbes1069 at gmail.com  Wed Oct 22 10:36:57 2014
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Wed, 22 Oct 2014 09:36:57 -0500
Subject: [CMake] CPack NSIS installer no desktop icon,
	so don't prompt to install one
Message-ID: <CAN3TeO0wXT156tv9MA1jT85HQ=hkC3MUGm2xjUgEk3mp0gRTZA@mail.gmail.com>

I'm packaging a library using the NSIS CPack installer and it does not have
any executables which require start menu links so needless to say I don't
need any desktop links.

I do want the end user to have the ability to add the location to the path
so I have that enabled but it includes a check box to create desktop links
which doesn't really do anything but I can't seem to find the right option
to suppress it.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141022/362415aa/attachment.html>

From eblot.ml at gmail.com  Wed Oct 22 13:37:00 2014
From: eblot.ml at gmail.com (Emmanuel Blot)
Date: Wed, 22 Oct 2014 19:37:00 +0200
Subject: [CMake] Invoking genassym from cmake
Message-ID: <CAKJJEPx7LkKDPc_=fdGOfVTVDtwVqgGUAv5epTHA+ENNqqgL-w@mail.gmail.com>

Hi,

I'd like to call genassym from cmake.

>From FreeBSD man page:
   sh genassym.sh [-c] C compiler invocation

I do not really get how to perform such a task from CMake, as the "C
compiler invokation" string is similar to what is defined with the
<CMAKE_C_COMPILER> <DEFINES> <FLAGS> (as retrieved from the
CMAKE_C_COMPILE_OBJECT var) but I cannot figure a way to retrieve
<DEFINES> and <FLAGS> contents here. I tried with (too) many
combinations of GET_PROPERTY, with no luck.

What would be the best way to retrieve all the definitions and flags
used for the current target, but invoke the compiler though
genassym.sh?

Thanks,
Manu

From jmerkow at gmail.com  Wed Oct 22 13:56:54 2014
From: jmerkow at gmail.com (jmerkow)
Date: Wed, 22 Oct 2014 10:56:54 -0700 (PDT)
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
Message-ID: <1414000614714-7588783.post@n2.nabble.com>

Sorry for the delayed response.

Im trying to use sftp.

To test it out, I am doing something like:

file(WRITE  upload.txt "testing upload")
file(UPLOAD upload.txt sftp://user:pass at server:/path/on/server STATUS status
SHOW_PROGRESS)
message("STATUS ${status}")

The status is STATUS 1;"unsupported protocol"

SFTP is definitely supported by cURL.

-Jameson



--
View this message in context: http://cmake.3232098.n2.nabble.com/file-UPLOAD-what-does-it-support-tp7588715p7588783.html
Sent from the CMake mailing list archive at Nabble.com.

From rcdailey.lists at gmail.com  Wed Oct 22 14:11:56 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Wed, 22 Oct 2014 13:11:56 -0500
Subject: [CMake] Is this the proper way to define a package config?
In-Reply-To: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
Message-ID: <CAHd499AmuKRWxmF8JWw0P-9Sq6WTbW4pjpdgNLKShgANH=OEeg@mail.gmail.com>

Can anyone help me with this? It would be much appreciated. Thank you.

On Fri, Oct 17, 2014 at 12:18 AM, Robert Dailey
<rcdailey.lists at gmail.com> wrote:
> I have a local package of boost built on Windows. It is always
> relative to the root of my project at a consistent structure and
> location. I wanted to define an import target for this and thought it
> might be best to define a BoostConfig.cmake package config file at the
> root of the boost lib directory. Is this the right approach? The code
> is below.
>
> Note that I do not have this working just yet because I don't know how
> to properly setup the interface link libraries. Could use some
> guidance here too... thanks.
>
> add_library( Boost STATIC IMPORTED GLOBAL )
>
> file( GLOB boost_debug_libs ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib )
> file( GLOB boost_release_libs
> ${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
>
> set_target_properties( Boost PROPERTIES
>     IMPORTED_LOCATION_DEBUG lib/win32/debug
>     IMPORTED_LOCATION_RELEASE lib/win32/release
>     INTERFACE_INCLUDE_DIRECTORIES include
>     INTERFACE_LINK_LIBRARIES
>         $<$<CONFIG:Debug>:${boost_debug_libs}>
>         $<$<CONFIG:Release>:${boost_release_libs}>
> )
>
> set( Boost_INCLUDE_DIRS include )
> set( Boost_LIBRARIES Boost )

From DLRdave at aol.com  Wed Oct 22 14:43:05 2014
From: DLRdave at aol.com (David Cole)
Date: Wed, 22 Oct 2014 14:43:05 -0400
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <1414000614714-7588783.post@n2.nabble.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
 <1414000614714-7588783.post@n2.nabble.com>
Message-ID: <CAKME8fHwQ6UyaVhC7tfNuphJryO-+seikk9kX2C7hz0iLNLLYA@mail.gmail.com>

What version of CMake are you using?
And on what platform?
And did you build it yourself, or are you using pre-built binaries
from somewhere?


On Wed, Oct 22, 2014 at 1:56 PM, jmerkow <jmerkow at gmail.com> wrote:
> Sorry for the delayed response.
>
> Im trying to use sftp.
>
> To test it out, I am doing something like:
>
> file(WRITE  upload.txt "testing upload")
> file(UPLOAD upload.txt sftp://user:pass at server:/path/on/server STATUS status
> SHOW_PROGRESS)
> message("STATUS ${status}")
>
> The status is STATUS 1;"unsupported protocol"
>
> SFTP is definitely supported by cURL.
>
> -Jameson
>
>
>
> --
> View this message in context: http://cmake.3232098.n2.nabble.com/file-UPLOAD-what-does-it-support-tp7588715p7588783.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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

From jmerkow at gmail.com  Wed Oct 22 15:40:35 2014
From: jmerkow at gmail.com (jmerkow)
Date: Wed, 22 Oct 2014 12:40:35 -0700 (PDT)
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <CAKME8fHwQ6UyaVhC7tfNuphJryO-+seikk9kX2C7hz0iLNLLYA@mail.gmail.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
 <1414000614714-7588783.post@n2.nabble.com>
 <CAKME8fHwQ6UyaVhC7tfNuphJryO-+seikk9kX2C7hz0iLNLLYA@mail.gmail.com>
Message-ID: <1414006835366-7588786.post@n2.nabble.com>

I have tried this on linux using 2.8.12, and on windows 7 with 3.0.2. Both
pre-built from http://cmake.org/
Both give the same error.

-Jameson



--
View this message in context: http://cmake.3232098.n2.nabble.com/file-UPLOAD-what-does-it-support-tp7588715p7588786.html
Sent from the CMake mailing list archive at Nabble.com.

From nilsgladitz at gmail.com  Wed Oct 22 15:58:16 2014
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Wed, 22 Oct 2014 21:58:16 +0200
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <1414000614714-7588783.post@n2.nabble.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
 <1414000614714-7588783.post@n2.nabble.com>
Message-ID: <54480C58.1040805@gmail.com>

On 22.10.2014 19:56, jmerkow wrote:
> The status is STATUS 1;"unsupported protocol"
>
> SFTP is definitely supported by cURL.

cURL has external library dependencies to support some of the protocols.
For https for example OpenSSL can be used; which is sometimes forgotten 
in custom cmake builds since it is disabled by default.

SFTP requires libssh2 which I assume isn't available/considered/enabled 
in the cmake release binaries.

Nils

From jmerkow at gmail.com  Wed Oct 22 16:09:50 2014
From: jmerkow at gmail.com (jmerkow)
Date: Wed, 22 Oct 2014 13:09:50 -0700 (PDT)
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <1414006835366-7588786.post@n2.nabble.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
 <1414000614714-7588783.post@n2.nabble.com>
 <CAKME8fHwQ6UyaVhC7tfNuphJryO-+seikk9kX2C7hz0iLNLLYA@mail.gmail.com>
 <1414006835366-7588786.post@n2.nabble.com>
Message-ID: <1414008590916-7588788.post@n2.nabble.com>

So Im most likely out of luck, unless I want to compile cmake myself with
those flags on...
Is there anyway to know which protocols will work with the standard cmake
packages? Besides systematically trying each one... Basically we have a
linux machine that we want to put nightly files on after ctest, its doesn't
have http or ftp.

I can try to work something out with execute_process and use scp, and find a
decent scp for windows.

-Jameson




--
View this message in context: http://cmake.3232098.n2.nabble.com/file-UPLOAD-what-does-it-support-tp7588715p7588788.html
Sent from the CMake mailing list archive at Nabble.com.

From bill.hoffman at kitware.com  Wed Oct 22 18:11:27 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Wed, 22 Oct 2014 18:11:27 -0400
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <1414008590916-7588788.post@n2.nabble.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
 <1414000614714-7588783.post@n2.nabble.com>
 <CAKME8fHwQ6UyaVhC7tfNuphJryO-+seikk9kX2C7hz0iLNLLYA@mail.gmail.com>
 <1414006835366-7588786.post@n2.nabble.com>
 <1414008590916-7588788.post@n2.nabble.com>
Message-ID: <54482B8F.2070703@kitware.com>

On 10/22/2014 4:09 PM, jmerkow wrote:
> So Im most likely out of luck, unless I want to compile cmake myself with
> those flags on...
> Is there anyway to know which protocols will work with the standard cmake
> packages? Besides systematically trying each one... Basically we have a
> linux machine that we want to put nightly files on after ctest, its doesn't
> have http or ftp.
>
> I can try to work something out with execute_process and use scp, and find a
> decent scp for windows.
OK, I took a look.  For this to work the CMakeLists.txt code in 
Utilities/cmcurl/CMakeLists.txt needs to be updated to support 
USE_LIBSSH2.  Then we need to get a version of libssh2 built on our 
windows build machine so that future releases of CMake have libssh2 
support in them.  If you were to make the correct modifications to the 
CMakeLists.txt file and test and build CMake with a libssh2 on Windows, 
I would be willing to get this into the CMake release process.

Right now CMake only links against openssl.  So, https works, but not sftp.

-Bill


From luc_j_bourhis at mac.com  Wed Oct 22 19:57:23 2014
From: luc_j_bourhis at mac.com (Luc J. Bourhis)
Date: Wed, 22 Oct 2014 16:57:23 -0700 (PDT)
Subject: [CMake] [CPACK] [RPM] Support of %preun and %postun
Message-ID: <1414022243056-7588790.post@n2.nabble.com>

Am I missing something or there is no equivalent of
CPACK_RPM_PRE_INSTALL_SCRIPT_FILE to specify %preun or %postun?




-----
--
Luc J. Bourhis

--
View this message in context: http://cmake.3232098.n2.nabble.com/CPACK-RPM-Support-of-preun-and-postun-tp7588790.html
Sent from the CMake mailing list archive at Nabble.com.

From jmerkow at gmail.com  Wed Oct 22 21:41:11 2014
From: jmerkow at gmail.com (jmerkow)
Date: Wed, 22 Oct 2014 18:41:11 -0700 (PDT)
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <54482B8F.2070703@kitware.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
 <1414000614714-7588783.post@n2.nabble.com>
 <CAKME8fHwQ6UyaVhC7tfNuphJryO-+seikk9kX2C7hz0iLNLLYA@mail.gmail.com>
 <1414006835366-7588786.post@n2.nabble.com>
 <1414008590916-7588788.post@n2.nabble.com> <54482B8F.2070703@kitware.com>
Message-ID: <1414028471700-7588791.post@n2.nabble.com>

Sure. I can take this on. Looks like the ifdefs are there and the
cmakedefines are all setup....

I believe that libssh2 is standard on linux and osx.  What about windows is
it even available on windows?

-Jameson



--
View this message in context: http://cmake.3232098.n2.nabble.com/file-UPLOAD-what-does-it-support-tp7588715p7588791.html
Sent from the CMake mailing list archive at Nabble.com.

From bill.hoffman at kitware.com  Wed Oct 22 23:04:56 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Wed, 22 Oct 2014 23:04:56 -0400
Subject: [CMake] file(UPLOAD what does it support?
In-Reply-To: <1414028471700-7588791.post@n2.nabble.com>
References: <1412900073098-7588715.post@n2.nabble.com>
 <CAKME8fH9GoFkyUpm1ssX0dow4iUpCMtLMYRUCzH1EuLeAoCNUg@mail.gmail.com>
 <1414000614714-7588783.post@n2.nabble.com>
 <CAKME8fHwQ6UyaVhC7tfNuphJryO-+seikk9kX2C7hz0iLNLLYA@mail.gmail.com>
 <1414006835366-7588786.post@n2.nabble.com>
 <1414008590916-7588788.post@n2.nabble.com> <54482B8F.2070703@kitware.com>
 <1414028471700-7588791.post@n2.nabble.com>
Message-ID: <54487058.4010706@kitware.com>

On 10/22/2014 9:41 PM, jmerkow wrote:
> Sure. I can take this on. Looks like the ifdefs are there and the
> cmakedefines are all setup....
>
Yup, it is part of curl, just not part of the way we build curl at the 
moment.
> I believe that libssh2 is standard on linux and osx.  What about windows is
> it even available on windows?
Seems to be (after a quick google search).  Not sure how hard it will be 
to use, but it seems that others have built it.

Thanks for helping out.  If you have any issues, you should move the 
conversation to the cmake-developers list.

-Bill


From domen.vrankar at gmail.com  Thu Oct 23 03:03:15 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 23 Oct 2014 09:03:15 +0200
Subject: [CMake] [CPACK] [RPM] Support of %preun and %postun
In-Reply-To: <1414022243056-7588790.post@n2.nabble.com>
References: <1414022243056-7588790.post@n2.nabble.com>
Message-ID: <CAKgx6BLHHE8iYO0Vy2BqzOT0DUrg-_wWv8V-G5fAAzMARnsnLw@mail.gmail.com>

2014-10-23 1:57 GMT+02:00 Luc J. Bourhis <luc_j_bourhis at mac.com>:

> Am I missing something or there is no equivalent of
> CPACK_RPM_PRE_INSTALL_SCRIPT_FILE to specify %preun or %postun?
>
>
The variables are missing in documentation but they exist.

For %preun you can set CPACK_RPM_PRE_UNINSTALL_READ_FILE or
CPACK_RPM_<component>_PRE_UNINSTALL_SCRIPT_FILE for component packaging.
For %postun you can set CPACK_RPM_POST_UNINSTALL_READ_FILE  or
CPACK_RPM_<component>_POST_UNINSTALL_SCRIPT_FILE for component packaging.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141023/2bf4b172/attachment.html>

From johannes.zarl at jku.at  Thu Oct 23 05:59:48 2014
From: johannes.zarl at jku.at (Johannes Zarl)
Date: Thu, 23 Oct 2014 11:59:48 +0200
Subject: [CMake] Is this the proper way to define a package config?
In-Reply-To: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
Message-ID: <1867592.YW9fbP6utO@ersa>

Hi,

Assuming you are not a boost developer / your changes won't be upstreamed, 
then creating a BoostConfig.cmake file won't do you much good. If someone wants 
to use your project, he/she will have to patch the locally installed boost 
version to include a BoostConfig.cmake file.

You might want to have a look into the FindBoost[1] module of cmake.

XXXConfig.cmake files are intended to be written by the creator of a package, 
FindXXX.cmake packages are intended as a workaround when a package does not 
contain an XXXConfig.cmake file and are usually written by a consumer of a 
package.

HTH,
  Johannes

[1] http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html

On Friday 17 October 2014 00:18:34 Robert Dailey wrote:
> I have a local package of boost built on Windows. It is always
> relative to the root of my project at a consistent structure and
> location. I wanted to define an import target for this and thought it
> might be best to define a BoostConfig.cmake package config file at the
> root of the boost lib directory. Is this the right approach? The code
> is below.
> 
> Note that I do not have this working just yet because I don't know how
> to properly setup the interface link libraries. Could use some
> guidance here too... thanks.
> 
> add_library( Boost STATIC IMPORTED GLOBAL )
> 
> file( GLOB boost_debug_libs ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib
> ) file( GLOB boost_release_libs
> ${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
> 
> set_target_properties( Boost PROPERTIES
>     IMPORTED_LOCATION_DEBUG lib/win32/debug
>     IMPORTED_LOCATION_RELEASE lib/win32/release
>     INTERFACE_INCLUDE_DIRECTORIES include
>     INTERFACE_LINK_LIBRARIES
>         $<$<CONFIG:Debug>:${boost_debug_libs}>
>         $<$<CONFIG:Release>:${boost_release_libs}>
> )
> 
> set( Boost_INCLUDE_DIRS include )
> set( Boost_LIBRARIES Boost )


From eblot.ml at gmail.com  Thu Oct 23 09:21:19 2014
From: eblot.ml at gmail.com (Emmanuel Blot)
Date: Thu, 23 Oct 2014 15:21:19 +0200
Subject: [CMake] Definiting output extension for cross-compilation
Message-ID: <CAKJJEPwMvmQVoMYaqib19_iXR0G59iyX+X1QdYcLYg7gyytdcg@mail.gmail.com>

Hi,

How to tell CMake to use '.o' output object file (instead of the
Windows' .obj forced alternative) when cross-compiling ?

SET (CMAKE_SYSTEM_NAME Generic)
...
SET (CMAKE_C_OUTPUT_EXTENSION .o)

has no effect from a project file.

forcing SET (UNIX 1) does work, but this is a terrible workaround

Thanks,
Manu

From domen.vrankar at gmail.com  Thu Oct 23 09:49:49 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 23 Oct 2014 15:49:49 +0200
Subject: [CMake]  Concatenating lists back to string
Message-ID: <CAKgx6BJje537AdC8m_D4wn8tEG1e45fVh6y-nZSjuijuqcx1PA@mail.gmail.com>

Hi,

I am trying to convert string to list and back with string(REPLACE) and it
doesn't work as expected (tested with cmake 2.8.12 on Ubuntu 14.04 and main
branch in git on Ubuntu 14.10).

cmake_minimum_required( VERSION 2.8.12 )
project(test_list)

set(str_1 "abc.def.ghi")
message("str_1: ${str_1}")
string(REPLACE "." ";" list_1 ${str_1})
message("list_1: ${list_1}")
string(REPLACE ";" "." str_2 ${list_1})
message("str_2: ${str_2}")


When I run cmake I get the following output:
str_1: abc.def.ghi
list_1: abc;def;ghi
str_2: abcdefghi

what I expected was that str_2 would be the same as str_1.

In case that semicolons are not used everything works as expected:

cmake_minimum_required( VERSION 2.8.12 )
project(test_list)

set(str_1 "abc.def.ghi")
message("str_1: ${str_1}")
string(REPLACE "." "'" list_1 ${str_1})
message("list_1: ${list_1}")
string(REPLACE "'" "." str_2 ${list_1})
message("str_2: ${str_2}")

Output:
str_1: abc.def.ghi
list_1: abc'def'ghi
str_2: abc.def.ghi

Is this a bug or is there a reason that ; is treated differently since it
represents lists?
Is there any other simpler option than to run foreach on the list and
convert it back to a string?

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141023/701e37a3/attachment.html>

From petr.kmoch at gmail.com  Thu Oct 23 10:05:12 2014
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 23 Oct 2014 16:05:12 +0200
Subject: [CMake] Concatenating lists back to string
In-Reply-To: <CAKgx6BJje537AdC8m_D4wn8tEG1e45fVh6y-nZSjuijuqcx1PA@mail.gmail.com>
References: <CAKgx6BJje537AdC8m_D4wn8tEG1e45fVh6y-nZSjuijuqcx1PA@mail.gmail.com>
Message-ID: <CAKohaZfm8m-e7iuC8jYxX=avhLaeU9vEQJED+Q4Zxnz+qMSANA@mail.gmail.com>

Hi Domen.

This is what helps me reason about it:

A string with a ';' in it is a list.
An unqouted ';' separates arguments to CMake commands.
string(REPLACE ...) simply concatenates all of its 'input' parameters.

So, when you expand ${list_1} in the last line, it will simply replace in
the concatenation of its elements - so there's no semicolon in them, of
course. What you want to do is treat the entire list_1 as a single string:

string(REPLACE ";" "." str_2 "${list_1}")

This should do what you expect.

Petr

On Thu, Oct 23, 2014 at 3:49 PM, Domen Vrankar <domen.vrankar at gmail.com>
wrote:

> Hi,
>
> I am trying to convert string to list and back with string(REPLACE) and it
> doesn't work as expected (tested with cmake 2.8.12 on Ubuntu 14.04 and main
> branch in git on Ubuntu 14.10).
>
> cmake_minimum_required( VERSION 2.8.12 )
> project(test_list)
>
> set(str_1 "abc.def.ghi")
> message("str_1: ${str_1}")
> string(REPLACE "." ";" list_1 ${str_1})
> message("list_1: ${list_1}")
> string(REPLACE ";" "." str_2 ${list_1})
> message("str_2: ${str_2}")
>
>
> When I run cmake I get the following output:
> str_1: abc.def.ghi
> list_1: abc;def;ghi
> str_2: abcdefghi
>
> what I expected was that str_2 would be the same as str_1.
>
> In case that semicolons are not used everything works as expected:
>
> cmake_minimum_required( VERSION 2.8.12 )
> project(test_list)
>
> set(str_1 "abc.def.ghi")
> message("str_1: ${str_1}")
> string(REPLACE "." "'" list_1 ${str_1})
> message("list_1: ${list_1}")
> string(REPLACE "'" "." str_2 ${list_1})
> message("str_2: ${str_2}")
>
> Output:
> str_1: abc.def.ghi
> list_1: abc'def'ghi
> str_2: abc.def.ghi
>
> Is this a bug or is there a reason that ; is treated differently since it
> represents lists?
> Is there any other simpler option than to run foreach on the list and
> convert it back to a string?
>
> Thanks,
> Domen
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141023/109ea362/attachment-0001.html>

From domen.vrankar at gmail.com  Thu Oct 23 10:25:26 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Thu, 23 Oct 2014 16:25:26 +0200
Subject: [CMake] Concatenating lists back to string
In-Reply-To: <CAKohaZfm8m-e7iuC8jYxX=avhLaeU9vEQJED+Q4Zxnz+qMSANA@mail.gmail.com>
References: <CAKgx6BJje537AdC8m_D4wn8tEG1e45fVh6y-nZSjuijuqcx1PA@mail.gmail.com>
 <CAKohaZfm8m-e7iuC8jYxX=avhLaeU9vEQJED+Q4Zxnz+qMSANA@mail.gmail.com>
Message-ID: <CAKgx6BJetpqkkaKrRQ+5AOXg4gh17TC8UmpNFPg5OobooxcJqw@mail.gmail.com>

2014-10-23 16:05 GMT+02:00 Petr Kmoch <petr.kmoch at gmail.com>:

> Hi Domen.
>
> This is what helps me reason about it:
>
> A string with a ';' in it is a list.
> An unqouted ';' separates arguments to CMake commands.
> string(REPLACE ...) simply concatenates all of its 'input' parameters.
>
> So, when you expand ${list_1} in the last line, it will simply replace in
> the concatenation of its elements - so there's no semicolon in them, of
> course. What you want to do is treat the entire list_1 as a single string:
>
> string(REPLACE ";" "." str_2 "${list_1}")
>
> This should do what you expect.
>

Haven't thought about that... Now it works :) Thanks!

Domen


>
> Petr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141023/8db8cf6b/attachment.html>

From Pere.Mato at cern.ch  Thu Oct 23 11:48:49 2014
From: Pere.Mato at cern.ch (Pere Mato Vila)
Date: Thu, 23 Oct 2014 15:48:49 +0000
Subject: [CMake] Controlling the verbosity in CTest scripts
Message-ID: <60EC831C-8D21-4EE7-AFFF-73C6B8ED5ABE@cern.ch>

Hi,

  I am running a CTest script in our continuous and nighty integration builds and tests scheduled by Jenkins. The test suit contains more than 1000 tests with a lot of output. Jenkins has a nice way to digest the test output and present it. What I would like to have is also the output of the build with the warnings and errors. If I launch the script with "ctest -VV" would do the trick, but it will also print the output of every test. Is there a way to be very verbose for the building and less verbose for the testing?
 Many thanks in advance,


Pere

    

From rcdailey.lists at gmail.com  Thu Oct 23 12:53:33 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 23 Oct 2014 11:53:33 -0500
Subject: [CMake] Is this the proper way to define a package config?
In-Reply-To: <1867592.YW9fbP6utO@ersa>
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
 <1867592.YW9fbP6utO@ersa>
Message-ID: <CAHd499AttEVRSmxLi02Dy5KX=YrCmRx-ViV_cd38XT=29aoLRQ@mail.gmail.com>

Thanks for the reply!

Basically the boost library I have is precompiled and in my own unique
structure. I do not plan to distribute the CMake scripts I write, they
are for personal / internal usage only.

You suggested a find module, but will this also generate a custom
target for boost? That's important so that when I do
target_link_libraries(), I can pass in "boost" and everything is
handled for me. I do not want to be working with libs & header files
directly in each executable or library I define that has a dependency
on boost.

Thanks again.

On Thu, Oct 23, 2014 at 4:59 AM, Johannes Zarl <johannes.zarl at jku.at> wrote:
> Hi,
>
> Assuming you are not a boost developer / your changes won't be upstreamed,
> then creating a BoostConfig.cmake file won't do you much good. If someone wants
> to use your project, he/she will have to patch the locally installed boost
> version to include a BoostConfig.cmake file.
>
> You might want to have a look into the FindBoost[1] module of cmake.
>
> XXXConfig.cmake files are intended to be written by the creator of a package,
> FindXXX.cmake packages are intended as a workaround when a package does not
> contain an XXXConfig.cmake file and are usually written by a consumer of a
> package.
>
> HTH,
>   Johannes
>
> [1] http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html
>
> On Friday 17 October 2014 00:18:34 Robert Dailey wrote:
>> I have a local package of boost built on Windows. It is always
>> relative to the root of my project at a consistent structure and
>> location. I wanted to define an import target for this and thought it
>> might be best to define a BoostConfig.cmake package config file at the
>> root of the boost lib directory. Is this the right approach? The code
>> is below.
>>
>> Note that I do not have this working just yet because I don't know how
>> to properly setup the interface link libraries. Could use some
>> guidance here too... thanks.
>>
>> add_library( Boost STATIC IMPORTED GLOBAL )
>>
>> file( GLOB boost_debug_libs ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib
>> ) file( GLOB boost_release_libs
>> ${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
>>
>> set_target_properties( Boost PROPERTIES
>>     IMPORTED_LOCATION_DEBUG lib/win32/debug
>>     IMPORTED_LOCATION_RELEASE lib/win32/release
>>     INTERFACE_INCLUDE_DIRECTORIES include
>>     INTERFACE_LINK_LIBRARIES
>>         $<$<CONFIG:Debug>:${boost_debug_libs}>
>>         $<$<CONFIG:Release>:${boost_release_libs}>
>> )
>>
>> set( Boost_INCLUDE_DIRS include )
>> set( Boost_LIBRARIES Boost )
>
> --
>
> 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

From norman-k-williams at uiowa.edu  Thu Oct 23 13:32:05 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Thu, 23 Oct 2014 17:32:05 +0000
Subject: [CMake] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on.
Message-ID: <D06EA5C3.C0C0%norman-k-williams@uiowa.edu>

A couple of years ago, with massive help from Brad King, I managed to get an embedded ExternalProject build of DCMTK embedded into ITK/Modules/ThirdParty.

This was workable, because the CMake dependencies were explicitly set up such that the DCMTK libraries depended on the ExternalProject DCMTK target, and the DCMTKImageIO module depended on the libraries.  When using the CMake with the Makefile generator, this hangs together, because the sub-make in Modules/IO/DCMTK won?t happen until the ExternalProject build in Modules/ThirdParty/DCMTK is complete.

Ninja, on the other hand, makes one flat megamake at the top level of ITK, and if you try and build with Module_ITKDCMTK/Module_ITKIODCMTK/Module_IOTransformDCMTK turned on, it fails immediately because the targets in Modules/IO/DCMTK depend on non-existent DCMTK libraries.

It?s a problem if we support all CMake generators except Ninja.  I like using Ninja because it shaves several seconds off build times, which is great when you?re in an edit/compile/test workflow.

I have no idea how this could be resolved, except to remove the internal DCMTK build and require USE_SYSTEM_DCMTK=ON.  Does anyone have a better idea.


________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141023/f836774f/attachment.html>

From bill.hoffman at kitware.com  Thu Oct 23 13:57:08 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Thu, 23 Oct 2014 13:57:08 -0400
Subject: [CMake] [ITK-dev] Can't build using NINJA with
 ITKDCMTK/ITKIODCMTK turned on.
In-Reply-To: <D06EA5C3.C0C0%norman-k-williams@uiowa.edu>
References: <D06EA5C3.C0C0%norman-k-williams@uiowa.edu>
Message-ID: <54494174.1080602@kitware.com>

On 10/23/2014 1:32 PM, Williams, Norman K wrote:
> I have no idea how this could be resolved, except to remove the internal
> DCMTK build and require USE_SYSTEM_DCMTK=ON.  Does anyone have a better
> idea.
>
The other option is to build this without external project and use 
add_subdirectory like we do with other 3rd party stuff (png, etc). 
Using ExternalProject does not work unless you build everything with 
external project as this case shows.   How hard would that be to do?

-Bill


From brad.king at kitware.com  Thu Oct 23 14:03:21 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 23 Oct 2014 14:03:21 -0400
Subject: [CMake] [ITK-dev] Can't build using NINJA with
 ITKDCMTK/ITKIODCMTK turned on.
In-Reply-To: <D06EA5C3.C0C0%norman-k-williams@uiowa.edu>
References: <D06EA5C3.C0C0%norman-k-williams@uiowa.edu>
Message-ID: <544942E9.40805@kitware.com>

On 10/23/2014 01:32 PM, Williams, Norman K wrote:
> it fails immediately because the targets in Modules/IO/DCMTK depend
> on non-existent DCMTK libraries.

This cannot be solved cleanly without addressing these issues:

 https://github.com/martine/ninja/issues/760#issuecomment-46540858
 http://www.cmake.org/Bug/view.php?id=14963#c36130

Currently the only way to build an ExternalProject cleanly
with Ninja is if the outer project contains nothing except
custom commands/targets, i.e. a superbuild that does both
DCMTK and ITK as external projects.

-Brad


From norman-k-williams at uiowa.edu  Thu Oct 23 15:04:14 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Thu, 23 Oct 2014 19:04:14 +0000
Subject: [CMake] [ITK-dev] Can't build using NINJA with
 ITKDCMTK/ITKIODCMTK turned on.
In-Reply-To: <544942E9.40805@kitware.com>
References: <D06EA5C3.C0C0%norman-k-williams@uiowa.edu>
 <544942E9.40805@kitware.com>
Message-ID: <D06EBACE.C0D5%norman-k-williams@uiowa.edu>

Yeah that?s the problem right there.  I would have no problem with
including DCMTK in the distro.


On 10/23/14, 1:03 PM, "Brad King" <brad.king at kitware.com> wrote:

>On 10/23/2014 01:32 PM, Williams, Norman K wrote:
>> it fails immediately because the targets in Modules/IO/DCMTK depend
>> on non-existent DCMTK libraries.
>
>This cannot be solved cleanly without addressing these issues:
>
> https://github.com/martine/ninja/issues/760#issuecomment-46540858
> http://www.cmake.org/Bug/view.php?id=14963#c36130
>
>Currently the only way to build an ExternalProject cleanly
>with Ninja is if the outer project contains nothing except
>custom commands/targets, i.e. a superbuild that does both
>DCMTK and ITK as external projects.
>
>-Brad
>



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________

From digitalriptide at gmail.com  Thu Oct 23 16:16:38 2014
From: digitalriptide at gmail.com (digitalriptide)
Date: Thu, 23 Oct 2014 14:16:38 -0600
Subject: [CMake] Pass on Unix Signals (ctrl+c)?
Message-ID: <CAJd=gO73pg4ckBAOdH8PXccm4qJo3VHV6TnL=QjOOsGEwN-xAw@mail.gmail.com>

I have a number of tests configured in my CMakeLists.txt file, a few
of which need to do some cleanup after running or if they are
interrupted  If I run make tests, and then send a signal (via ctrl+c,
for example), however, these signals are not passed on to the test. Is
it possible to configure CMake to pass signals on to the tests that
are run?

Cheers!

From digitalriptide at gmail.com  Thu Oct 23 16:19:05 2014
From: digitalriptide at gmail.com (digitalriptide)
Date: Thu, 23 Oct 2014 14:19:05 -0600
Subject: [CMake] CMake, Xcode, and Intel Fortran?
Message-ID: <CAJd=gO54nxBC4S6shJCdyZwj9rJn4HZmwvS1CawKEMUeEcSO=Q@mail.gmail.com>

In the past I was able to generate Xcode projects that contained
Fortran files via `cmake -gXcode ..` and CMake would pick up the Intel
Fortran compiler. This behavior seems to have changed recently,
however. Has anyone else experienced this problem and/or found a
workaround? Is this is an issue with CMake, Xcode, or the Intel suite?

Cheers!

From digitalriptide at gmail.com  Thu Oct 23 16:22:56 2014
From: digitalriptide at gmail.com (digitalriptide)
Date: Thu, 23 Oct 2014 14:22:56 -0600
Subject: [CMake] Pass on Unix Signals (ctrl+c)?
In-Reply-To: <CAJd=gO73pg4ckBAOdH8PXccm4qJo3VHV6TnL=QjOOsGEwN-xAw@mail.gmail.com>
References: <CAJd=gO73pg4ckBAOdH8PXccm4qJo3VHV6TnL=QjOOsGEwN-xAw@mail.gmail.com>
Message-ID: <CAJd=gO7JkUsRH6d-+_m63ujD=Z1KJeA4nOeyUoD8OufoM4rzqg@mail.gmail.com>

Alternatively, what signal does CMake use to halt tests?

Than you!

On Thu, Oct 23, 2014 at 2:16 PM, digitalriptide
<digitalriptide at gmail.com> wrote:
> I have a number of tests configured in my CMakeLists.txt file, a few
> of which need to do some cleanup after running or if they are
> interrupted  If I run make tests, and then send a signal (via ctrl+c,
> for example), however, these signals are not passed on to the test. Is
> it possible to configure CMake to pass signals on to the tests that
> are run?
>
> Cheers!

From DLRdave at aol.com  Thu Oct 23 20:23:06 2014
From: DLRdave at aol.com (David Cole)
Date: Thu, 23 Oct 2014 20:23:06 -0400
Subject: [CMake] The new cmake.org web site
Message-ID: <CAKME8fHa1OYWMhPR3Fgj9rO6B=j8_5eZcMSfAXg-v9aH9FwBJA@mail.gmail.com>

The new CMake web site looks fantastic! Even on my phone... Kudos to
everybody involved in making it look pretty after all these years of,
well, ahem, looking slightly less pretty.......

However, on this page:
http://www.cmake.org/developer-resources/

The "Dashboard" icon is a broken link. 404.

But, besides that, nice work!


Cheers,
David C.

From sahilsehgal1995 at gmail.com  Fri Oct 24 02:19:55 2014
From: sahilsehgal1995 at gmail.com (Sahil Sehgal)
Date: Fri, 24 Oct 2014 11:49:55 +0530
Subject: [CMake] Fwd: Error in compiling OKULAR using CMAKE
In-Reply-To: <CAEDFXffYtcHpESD8vTucFz_TXTxm8GqtpFjnqvr=GCHAjq5LFA@mail.gmail.com>
References: <CAEDFXffYtcHpESD8vTucFz_TXTxm8GqtpFjnqvr=GCHAjq5LFA@mail.gmail.com>
Message-ID: <CAEDFXffv5s_eeWW8FauLY15WvPgvfrg0GHFyOKzMRVsQ8aZtyA@mail.gmail.com>

Hello,

I was trying to build Okular (KDE application) in IDE (QT-creator and
Kdevelop both). I did the following steps:
1.) clonned the source code of Okular
2.) loaded the source code in IDE
3.) click on the build command.

I got the following error





















*/home/sahil/my/New Folder/prog/okular/build> /usr/bin/cmake
-DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug
'/home/sahil/my/New Folder/prog/okular/'-- Found Qt-Version 5.2.1 (using
/usr/bin/qmake)CMake Error: The following variables are used in this
project, but they are set to NOTFOUND.Please set them or make sure they are
set and tested correctly in the CMake files:QT_QT_INCLUDE_DIR   used as
include directory in directory /home/sahil/my/New
Folder/prog/okular/build/CMakeFiles/CMakeTmpCMake Error: Internal CMake
error, TryCompile configure of cmake failedCMake Error at
/usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1316 (message):
Unable to compile a basic Qt application.  Qt has not been found
correctly.Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (find_package)
CMakeLists.txt:3 (find_package)-- Configuring incomplete, errors
occurred!See also "/home/sahil/my/New
Folder/prog/okular/build/CMakeFiles/CMakeOutput.log".See also
"/home/sahil/my/New Folder/prog/okular/build/CMakeFiles/CMakeError.log".***
Failure: Exit code 1 ****

Please suggest the possible solution

Regards
Sahil Sehgal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/e8173598/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fee1.png
Type: image/png
Size: 213812 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/e8173598/attachment-0001.png>

From lfdominguez at estudiantes.uci.cu  Thu Oct 23 22:29:51 2014
From: lfdominguez at estudiantes.uci.cu (lfdominguez at estudiantes.uci.cu)
Date: Fri, 24 Oct 2014 02:29:51 +0000
Subject: [CMake] Fwd: Error in compiling OKULAR using CMAKE
In-Reply-To: <CAEDFXffv5s_eeWW8FauLY15WvPgvfrg0GHFyOKzMRVsQ8aZtyA@mail.gmail.com>
References: <CAEDFXffYtcHpESD8vTucFz_TXTxm8GqtpFjnqvr=GCHAjq5LFA@mail.gmail.com>
 <CAEDFXffv5s_eeWW8FauLY15WvPgvfrg0GHFyOKzMRVsQ8aZtyA@mail.gmail.com>
Message-ID: <2905201.UkD8Wta6Ld@envy>

On Friday 24 October 2014 11:49:55 AM Sahil Sehgal wrote:




Hello,



I was trying to build Okular (KDE application) in IDE (QT-creator and Kdevelop 
both). I did the following steps:


1.) clonned the source code of Okular


2.) loaded the source code in IDE


3.) click on the build command.



I got the following error



*/home/sahil/my/New Folder/prog/okular/build> /usr/bin/cmake -
DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug 
'/home/sahil/my/New Folder/prog/okular/'-- Found Qt-Version 5.2.1 (using 
/usr/bin/qmake)CMake Error: The following variables are used in this project, but 
they are set to NOTFOUND.Please set them or make sure they are set and tested 
correctly in the CMake files:QT_QT_INCLUDE_DIR   used as include directory in 
directory /home/sahil/my/New Folder/prog/okular/build/CMakeFiles/CMakeTmp

CMake Error: Internal CMake error, TryCompile configure of cmake failed

CMake Error at 
/usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1316 (message):  
Unable to compile a basic Qt application.  Qt has not been found correctly.Call 
Stack (most recent call first):  /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 
(find_package)  CMakeLists.txt:3 (find_package)


-- Configuring incomplete, errors occurred!See also "/home/sahil/my/New 
Folder/prog/okular/build/CMakeFiles/CMakeOutput.log".See also 
"/home/sahil/my/New Folder/prog/okular/build/CMakeFiles/CMakeError.log".*** 
Failure: Exit code 1 ***

*
Please suggest the possible solution



Regards 


Sahil Sehgal






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/b62f04c8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/b62f04c8/attachment.sig>

From robert.maynard at kitware.com  Fri Oct 24 08:01:52 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 24 Oct 2014 08:01:52 -0400
Subject: [CMake] The new cmake.org web site
In-Reply-To: <CAKME8fHa1OYWMhPR3Fgj9rO6B=j8_5eZcMSfAXg-v9aH9FwBJA@mail.gmail.com>
References: <CAKME8fHa1OYWMhPR3Fgj9rO6B=j8_5eZcMSfAXg-v9aH9FwBJA@mail.gmail.com>
Message-ID: <CAFzjYVooSBGPTk-xnJTVkhMwmvaRWY+an3x63+K9-qhFoycMgw@mail.gmail.com>

Thanks for finding the broken link, I have correct the url and everything
should be working now.

On Thu, Oct 23, 2014 at 8:23 PM, David Cole via CMake <cmake at cmake.org>
wrote:

> The new CMake web site looks fantastic! Even on my phone... Kudos to
> everybody involved in making it look pretty after all these years of,
> well, ahem, looking slightly less pretty.......
>
> However, on this page:
> http://www.cmake.org/developer-resources/
>
> The "Dashboard" icon is a broken link. 404.
>
> But, besides that, nice work!
>
>
> Cheers,
> David C.
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/18d7da53/attachment.html>

From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.0.1414164642.19642.cmake@cmake.org>

  // Now check and see if the value has been stored in the cache
  // already, if so use that value and don't look for the program
  std::string helpString = "Where can the ";
  helpString += args[1] + " library be found";
  const char* cacheValue
    = cmCacheManager::GetInstance()->GetCacheValue(args[0].c_str());
  if(cacheValue && strcmp(cacheValue, "NOTFOUND"))
   ...




From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.1.1414164643.19642.cmake@cmake.org>

../CMake/configure
make
Source/cmake ../CMake
vi CMakeCache.txt (change INSTALL location by hand)
make
make install
 
So I end up building cmake twice.  The first time is to get a cmake executable that I can build cmake
a second time using cmake.  Once I run cmake on cmake, then I can edit the cache to change the
install prefix.
 
Why doesn't cmake use
 
../CMake/configure --with-prefix=foo
 
Or has this been fixed?


Jim Miller 
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301

millerjv at crd.ge.com < mailto:millerjv at crd.ge.com <mailto:millerjv at crd.ge.com> >
(518) 387-4005, Dial Comm: 8*833-4005, 
Cell: (518) 505-7065, Fax: (518) 387-6981 


 

------_=_NextPart_001_01C10FBA.30948CE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=743004418-18072001><FONT size=2>What is the recommended 
procedure to install CMake in a directory other than /usr/local 
?</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>From a fresh checkout, I've 
been doing</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=743004418-18072001><FONT 
size=2>../CMake/configure</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>make</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>Source/cmake 
../CMake</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>vi CMakeCache.txt (change 
INSTALL location by hand)</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>make</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>make 
install</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>So I end up building cmake 
twice.&nbsp; The first time is to get a cmake executable that I can build cmake 
a second time&nbsp;using cmake.&nbsp; Once I run cmake on cmake, then I can edit 
the cache to change the install prefix.</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>Why doesn't cmake 
use</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>../CMake/configure 
--with-prefix=foo</FONT></SPAN></DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=743004418-18072001><FONT size=2>Or has this been 
fixed?</FONT></SPAN></DIV><BR>
<P><B><FONT face="Comic Sans MS" color=#000080>Jim Miller</FONT></B> 
<BR><B><I><FONT face=Arial color=#ff0000 
size=2>_____________________________________</FONT></I></B><I></I><BR><I></I><I><FONT 
face=Arial color=#000000 size=1>Visualization &amp; Computer Vision<BR>GE 
Corporate Research &amp; Development<BR>Bldg. KW, Room C218B<BR>P.O. Box 8, 
Schenectady NY 12301<BR><BR></FONT><U><FONT face=Arial color=#0000ff 
size=1>millerjv at crd.ge.com &lt;<A 
href="mailto:millerjv at crd.ge.com">mailto:millerjv at crd.ge.com</A>&gt;</FONT></U></I><BR><I><FONT 
face=Arial color=#000000 size=1>(518) 387-4005, Dial Comm: 8*833-4005, 
</FONT></I><BR><I><FONT face=Arial color=#000000 size=1>Cell: (518) 505-7065, 
Fax: (518) 387-6981</FONT></I> </P><BR>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C10FBA.30948CE0--

------_=_NextPart_000_01C10FBA.30948CE0
Content-Type: application/octet-stream;
	name="Miller, James V (CRD).vcf"
Content-Disposition: attachment;
	filename="Miller, James V (CRD).vcf"

BEGIN:VCARD
VERSION:2.1
N:Miller;James
FN:Miller, James V (CRD)
ORG:CRD;ESL
TITLE:Computer Scientist
TEL;WORK;VOICE:*833-4005
TEL;WORK;VOICE:1 518 387-4005
ADR;WORK:;KW-C218B;P.O. Box 8;Schenectady;New York;12301;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KW-C218B=0D=0AP.O. Box 8=0D=0ASchenectady, New York 12301=0D=0AUSA
EMAIL;PREF;INTERNET:millerjv at crd.ge.com
REV:20010420T140329Z
END:VCARD

------_=_NextPart_000_01C10FBA.30948CE0--



From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.2.1414164646.19642.cmake@cmake.org>


thanks in advance
regards
priya




"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."



From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.3.1414164647.19642.cmake@cmake.org>

but I cannot reset a cache entry to NOTFOUND.
 
My only recourse is to edit the CMakeCache.txt file by hand and set the value back to NOTFOUND.
However,
I know that editting the cache by hand opens me up for the wrathe of Kitware.
 
Can a method be added to the GUI to allow you to reset a parameter to its default?
 


Jim Miller 
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301

millerjv at crd.ge.com < mailto:millerjv at crd.ge.com <mailto:millerjv at crd.ge.com> >
(518) 387-4005, Dial Comm: 8*833-4005, 
Cell: (518) 505-7065, Fax: (518) 387-6981 


 

------_=_NextPart_001_01C1B0D2.7570FF9D
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=599594718-08022002><FONT size=2>Some software projects have 
configured CMake to search diligently for certain libraries on your system. 
</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>If it finds them, it uses them 
for in its build process. If they are not found, the build configures itself 
differently.</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>Here's my problem.&nbsp; One of 
these projects finds a tiff library in the directory structure of another 
one</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>of my projects (as opposed to 
inside a system directory).&nbsp; I don't want this second system to use the 
</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>version that it found in the 
first.&nbsp; In fact, I do not want it use one at all.</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>From CMakeSetup, I can point 
CMake to a different library or I can tell CMake to forget a cache entry but I 
cannot reset a cache entry to NOTFOUND.</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>My only recourse is to edit the 
CMakeCache.txt file by hand and set the value back to 
NOTFOUND.&nbsp;However,</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>I know that editting the cache 
by hand opens me up for the wrathe of Kitware.</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2>Can a method be added to the 
GUI to allow you to reset a parameter to its default?</FONT></SPAN></DIV>
<DIV><SPAN class=599594718-08022002><FONT size=2></FONT></SPAN>&nbsp;</DIV><BR>
<P><B><FONT face="Comic Sans MS" color=#000080>Jim Miller</FONT></B> 
<BR><B><I><FONT face=Arial color=#ff0000 
size=2>_____________________________________</FONT></I></B><I></I><BR><I></I><I><FONT 
face=Arial color=#000000 size=1>Visualization &amp; Computer Vision<BR>GE 
Corporate Research &amp; Development<BR>Bldg. KW, Room C218B<BR>P.O. Box 8, 
Schenectady NY 12301<BR><BR></FONT><U><FONT face=Arial color=#0000ff 
size=1>millerjv at crd.ge.com &lt;<A 
href="mailto:millerjv at crd.ge.com">mailto:millerjv at crd.ge.com</A>&gt;</FONT></U></I><BR><I><FONT 
face=Arial color=#000000 size=1>(518) 387-4005, Dial Comm: 8*833-4005, 
</FONT></I><BR><I><FONT face=Arial color=#000000 size=1>Cell: (518) 505-7065, 
Fax: (518) 387-6981</FONT></I> </P><BR>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C1B0D2.7570FF9D--

------_=_NextPart_000_01C1B0D2.7570FF9D
Content-Type: application/octet-stream;
	name="Miller, James V (CRD).vcf"
Content-Disposition: attachment;
	filename="Miller, James V (CRD).vcf"

BEGIN:VCARD
VERSION:2.1
N:Miller;James
FN:Miller, James V (CRD)
ORG:CRD;ESL
TITLE:Computer Scientist
TEL;WORK;VOICE:*833-4005
TEL;WORK;VOICE:1 518 387-4005
ADR;WORK:;KW-C218B;P.O. Box 8;Schenectady;New York;12301;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KW-C218B=0D=0AP.O. Box 8=0D=0ASchenectady, New York 12301=0D=0AUSA
EMAIL;PREF;INTERNET:millerjv at crd.ge.com
REV:20010420T140329Z
END:VCARD

------_=_NextPart_000_01C1B0D2.7570FF9D--


From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.4.1414164649.19642.cmake@cmake.org>

BPI 
BPI is an abbreviation for Bits Per Inch
BPL 
BPL is an abbreviation for Boston Public Library; Branch if PLus


That borland compiler is always adding new things... :)

Do you link in modules?   I thought modules were just for dynamic loading?
Anyway if you need it, you will have to add something like that.

It will mean changing cmNMakefileGenerator and cmBorlandMakefileGenerator and
possibly the cmUnixMakefileGenerator.


-Bill


At 03:40 PM 4/12/2002 +0100, John Biddiscombe wrote:
>If a target is XXX (SHARED  : extension = dll )
>and another target depends on XXX it adds XXX.lib to the depends because lib
>is the import library for a dll.
>
>I have a Target YYY (MODULE : extension = bpl)
>but another target depends on it - BUT a bpl has an import library of bpi.
>(not dll)
>
>Cmake keeps adding YYY.lib to the dependency lists, and I can't find the bit
>of code responsible for it. I'd like to tell it to add YYY.bpi insteead. Can
>anyone help?
>
>(I have a sneaking suspicion I'd need to use/add CMAKE_SHLIB_IMPORT_SUFFIX,
>CMAKE_MODULE_IMPORT_SUFFIX)
>
>Thanks
>
>JB
>
>
>_______________________________________________
>Cmake mailing list
>Cmake at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake 

--=====================_1536751652==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<b><a href="http://www.probertencyclopaedia.com/N2.HTM" eudora="autourl">http://www.probertencyclopaedia.com/N2.HTM</a><br>
<br>
</b>From The Probert Encyclopaedia Abbreviations :<br>
<br>
<b>BPI</b> <br>
BPI is an abbreviation for Bits Per Inch<br>
<b>BPL</b> <br>
BPL is an abbreviation for <font color="#0000FF"><u>Boston</u></font>
Public Library; Branch if PLus<br>
<br>
<br>
That borland compiler is always adding new things...  :)<br>
<br>
Do you link in modules?&nbsp;&nbsp; I thought modules were just for
dynamic loading?<br>
Anyway if you need it, you will have to add something like that.<br>
<br>
It will mean changing cmNMakefileGenerator and cmBorlandMakefileGenerator
and<br>
possibly the cmUnixMakefileGenerator.<br>
<br>
<br>
-Bill<br>
<br>
<br>
At 03:40 PM 4/12/2002 +0100, John Biddiscombe wrote:<br>
<blockquote type=cite class=cite cite>If a target is XXX (SHARED&nbsp; :
extension = dll )<br>
and another target depends on XXX it adds XXX.lib to the depends because
lib<br>
is the import library for a dll.<br>
<br>
I have a Target YYY (MODULE : extension = bpl)<br>
but another target depends on it - BUT a bpl has an import library of
bpi.<br>
(not dll)<br>
<br>
Cmake keeps adding YYY.lib to the dependency lists, and I can't find the
bit<br>
of code responsible for it. I'd like to tell it to add YYY.bpi insteead.
Can<br>
anyone help?<br>
<br>
(I have a sneaking suspicion I'd need to use/add
CMAKE_SHLIB_IMPORT_SUFFIX,<br>
CMAKE_MODULE_IMPORT_SUFFIX)<br>
<br>
Thanks<br>
<br>
JB<br>
<br>
<br>
_______________________________________________<br>
Cmake mailing list<br>
Cmake at public.kitware.com<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" eudora="autourl">http://public.kitware.com/mailman/listinfo/cmake</a>
</blockquote></html>

--=====================_1536751652==_.ALT--



From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.5.1414164650.19642.cmake@cmake.org>

  With the external instances method, all instances are placed within the template
  repository. The compiler ensures that exactly one consistent template instance exists;
  instances are neither undefined nor multiply defined. Templates are reinstantiated
  only when necessary.
  Template instances receive global linkage in the repository. Instances are referenced
  from the current compilation unit with external linkage.
  Specify external linkage with the -instances=extern option (the default option).
  Because instances are stored within the template repository, you must use the CC
  command to link C++ objects that use external instances into programs.
  If you wish to create a library that contains all template instances that it uses, use the
  CC command with the -xar option. Do not use the ar command.

Bill



From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.6.1414164664.19642.cmake@cmake.org>

Cygwin is a UNIX environment, developed by Red Hat, for Windows. It consists of two parts: A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing substantial UNIX API functionality. 
A collection of tools, ported from UNIX, which provide UNIX/Linux look and feel. 


-Bill




From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.7.1414164668.19642.cmake@cmake.org>

  "/cygdrive/c/Program Files/CMake/bin/cmake" -h

it claims to be version 1.4.  Is this right?  Wrong?  Expected?

I repeated this a couple of times, and once even wiped the old installation before reinstalling.

I think it would be nice of the windows installer exec had the version in their name, like
CMSetup147.exe, CMSetup160.exe, etc.

Thanks,
Fred Wheeler


From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.8.1414164671.19642.cmake@cmake.org>

machine to run the ccmake interface.

1) This works on Solaris
2) It used to work under Linux with V 1.46 of Cmake
3) I tried other terminal types (e.g. vt100) to no avail

cheers
Neil






From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.9.1414164673.19642.cmake@cmake.org>

The variables ${Document_SOURCE_DIR}, ${LATEX_COMPILE}, and
${Document_BINARY_DIR} are pre-defined.

ADD_CUSTOM_TARGET(LaTeXDocument ALL echo)
ADD_CUSTOM_COMMAND(
    SOURCE    ${Document_SOURCE_DIR}/TDocument.tex
    COMMAND   ${LATEX_COMPILE}
    ARGS      ${Document_SOURCE_DIR}/TDocument.tex
    TARGET    LaTeXDocument
    DEPENDS   ${Document_BINARY_DIR}/TDocument.tex
    OUTPUTS   ${Document_BINARY_DIR}/TDocument.dvi
)



I have many questions...   :-(


1) ADD_CUSTOM_TARGET(LaTeXDocument ALL echo)

What do the arguments mean ?  I assume "LaTeXDocument" is a new generic
target name made up here.  It is used below so I will defer further
questions until then.   WHat does "echo" do ?

The docs. say the syntax is

 ADD_CUSTOM_TARGET (Name [ALL] command arg arg arg...)

it describes the meaning of ALL.   But this suggests that I now
have a command "echo" and no arguments.  WHat does this do ?

I might have thought that this CMake command was going to describe
how to build a target of type  'LaTeXDocument' and that the 'command'
would be the one needed to compile a LaTeX document (e.g. a
CUSTOM_COMMAND) and that 'arg'  might be the arguments, but that does not
appear to be the case.

So I am left bemused by this example.



2)  ADD_CUSTOM_COMMAND

I though this would be the custom command  needed to process a target
of type LaTeXDocument, and it is, although I am not sure why.  This
custom command does not have a name, and so it can't be associated
via the 'command' argument of ADD_CUSTOM_TARGET (and it isn't).  The
only association appears to be the the line below

    TARGET    LaTeXDocument

does that mean this command is used to build CUSTOM_TARGETS of type
LateXDocument ?  If it does it seems pointless, because I don't
see how the ADD_CUSTOM_TARGET is then used in any way to add a specific
target.


ADD_CUSTOM_COMMAND(
    SOURCE    ${Document_SOURCE_DIR}/TDocument.tex

I assume this indicates that the input file should be found as specified.
In this example, the actual source file is included (TDocument.tex).  Does
that mean for every input source file I have to create a complete
ADD_CUSTOM_COMMAND like this ?  Again I was expecting the CUSTOM_COMMAND
to essentially be a macro, and ADD_CUSTOM_TARGET would invoke that
macro/command for each desired target.  It doesn't appear to be that way.

    COMMAND   ${LATEX_COMPILE}

ok this is the command to execute.  In this case, it would be 'latex'

    ARGS      ${Document_SOURCE_DIR}/TDocument.tex

These are the arguments for the command.  What is their relationship
to the arguments in ADD_CUSTOM_TARGET.  Why is the SOURCE file
repeated here ?  SUrely the arguments would be things that control
the functioning of latex, not the input and output becuase there exists
the SOURCE and OUTPUTS variables.

The only thought I have here is that for each command, you cannot guess
what order arguments might be required, and therefore you must put the
input/output on the arguments list here.  In that case, what is the
purpose oF SOURCE and OUTPUTS ?  I could underestand if they were
just directories but that is not how they are used in this example.

    TARGET    LaTeXDocument

WHat is the purpose of this line ? DOes it associate with
ADD_CUSTOM_TARGET in some way ?    If so, what is that association ?

    DEPENDS   ${Document_BINARY_DIR}/TDocument.tex

I assume this means that if this file changes, redo the output

    OUTPUTS   ${Document_BINARY_DIR}/TDocument.dvi

This is the output file ?
)




My coding of this for my project looks like:

SET (LATEX_COMPILE latex)
SET(DOC_ROOT ${MITK_SOURCE_DIR}/Documentation}

ADD_CUSTOM_TARGET (LaTeXDocument ALL echo)
ADD_CUSTOM_COMMAND(
    SOURCE    ${DOC_ROOT}/junk.tex
    COMMAND   ${LATEX_COMPILE}
    ARGS      ${DOC_ROOT}/junk.tex
    TARGET    LaTeXDocument
    DEPENDS   ${DOC_ROOT}/junk.tex
    OUTPUTS   ${MITK_BINARY_DIR}/junk.dvi
)


Well if I add these commands to my CMakeLists.txt file, the resultant
Makefile contains precisely nothing  regarding any latex commands etc. and
produces no output.

Admittedly, the docs. say that 'ADD_CUSTOM_TARGET : adds an extra target
that does not produce output', so it has certainly lived up to that
description, unhelpful though it is.




What I was expecting in all of this was something like

1) define a custom command

ADD_CUSTOM_COMMAND (
   NAME   MYCOMMAND
   COMMAND  latex
   ARGUMENTS
)


2) then I make a target and tell it which command to use, something like:

ADD_CUSTOM_TARGET (myDoc.dvi myDoc.tex MYCOMMAND)




Anyway, I am sure it works as it is, but I have no idea how !   I'd really
appreciate a clear description (please put in docs) and working example
(please update FAQ) of these  commands.   Sorry this email is so long.


regards
Neil




From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.10.1414164681.19642.cmake@cmake.org>

"pkg-config is a system for managing library compile/link flags that 
works with automake and autoconf (and now CMake ;)). It replaces the 
ubiquitous *-config scripts you may have seen with a single tool. There's 
nothing desktop-specific or desktop-related about pkg-config, despite it 
being on freedesktop.org."

http://www.freedesktop.org/Software/pkgconfig/

Fedora Core 1 includes pkg-config files for all the libraries used by 
GNOME 2.4, some Mozilla libraries, and a few other libraries like OpenSSL.
Quite a few library packges from freshrpms.net also include pkg-config 
files, such as the ALSA library. Furthermore, pkg-config was designed to 
work with Win32.

I implemented the interface to pkg-config as a macro that can check one 
library at a time.

Example:

INCLUDE( ${CMAKE_SOURCE_DIR}/FindPkgConfig.cmake )
PKGCONFIG("glib-2.0 >= 2.2.0")
IF(PKGCONFIG_FOUND)
  IF(CMAKE_PKGCONFIG_C_FLAGS)
    SET(CMAKE_C_FLAGS "${CMAKE_PKGCONFIG_C_FLAGS} ${CMAKE_C_FLAGS}")
    #do something with ${PKGCONFIG_LIBRARIES}
  ENDIF(CMAKE_PKGCONFIG_C_FLAGS)
ELSE(PKGCONFIG_FOUND)
  MESSAGE("Cannot find glib2 version 2.2.0 or above")
ENDIF(PKGCONFIG_FOUND)

Any comments or suggestions on improving this module would be appreciated.

Cheers,

Albert

P.S. The module is currently UNIX-specific, as I don't have Win32 build 
environment. If you're going to experiment with pkg-config on Win32, note 
that pkg-config has a --msvc-syntax switch for outputting the -l and -L 
flags in a format that MSVC understands.

--ReaqsoxgOBHFXBhH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="FindPkgConfig.cmake"

## FindPkgConfig.cmake
## by Albert Strasheim <http://students.ee.sun.ac.za/~albert/>
##
## This module finds packages using pkg-config, which retrieves
## information about packages from special metadata files.
##
## See http://www.freedesktop.org/Software/pkgconfig/
##
## -------------------------------------------------------------------
##
## Usage:
##
## INCLUDE( ${CMAKE_ROOT}/Modules/FindPkgConfig.cmake)
## PKGCONFIG("libxml-2.0 >= 1.3")
## IF(PKGCONFIG_FOUND)
##   # do something with CMAKE_PKGCONFIG_C_FLAGS
##   # do something with PKGCONFIG_LIBRARIES
## ELSE(PKGCONFIG_FOUND)
#    MESSAGE("Cannot find libxml2 version 1.3 or above")
## ENDIF(PKGCONFIG_FOUND)
##
## Notes:
## 
## You can set the PKG_CONFIG_PATH environment variable to tell
## pkg-config where to search for .pc files. See pkg-config(1) for
## more information.

#FIXME: IF(WIN32) pkg-config --msvc-syntax ENDIF(WIN32) ???

FIND_PROGRAM(CMAKE_PKGCONFIG_EXECUTABLE pkg-config)
MARK_AS_ADVANCED(CMAKE_PKGCONFIG_EXECUTABLE)

MACRO(PKGCONFIG LIBRARY)
  SET(PKGCONFIG_FOUND 0)

  MESSAGE("DEBUG: find library '${LIBRARY}'")
  
  IF(CMAKE_PKGCONFIG_EXECUTABLE)
    MESSAGE("DEBUG: pkg-config executable found")
    
    EXEC_PROGRAM(${CMAKE_PKGCONFIG_EXECUTABLE}
      ARGS "'${LIBRARY}'"
      OUTPUT_VARIABLE PKGCONFIG_OUTPUT
      RETURN_VALUE PKGCONFIG_RETURN)
    IF(NOT PKGCONFIG_RETURN)
      MESSAGE("DEBUG: packages found")
      
      # set C_FLAGS and CXX_FLAGS
      EXEC_PROGRAM(${CMAKE_PKGCONFIG_EXECUTABLE}
        ARGS "--cflags '${LIBRARY}'"
        OUTPUT_VARIABLE CMAKE_PKGCONFIG_C_FLAGS)
      SET(CMAKE_PKGCONFIG_CXX_FLAGS "${CMAKE_PKGCONFIG_C_FLAGS}")
      
      # set LIBRARIES
      EXEC_PROGRAM(${CMAKE_PKGCONFIG_EXECUTABLE}
        ARGS "--libs '${LIBRARY}'"
        OUTPUT_VARIABLE PKGCONFIG_LIBRARIES)
      
      SET(PKGCONFIG_FOUND 1)
    ELSE(NOT PKGCONFIG_RETURN)
      MESSAGE("DEBUG '${LIBRARY}' NOT FOUND by pkg-config")
      
      SET(CMAKE_PKGCONFIG_C_FLAGS "")
      SET(CMAKE_PKGCONFIG_CXX_FLAGS "")
      SET(PKGCONFIG_LIBRARIES "")
    ENDIF(NOT PKGCONFIG_RETURN)
  ELSE(CMAKE_PKGCONFIG_EXECUTABLE)
    MESSAGE("DEBUG: pkg-config executable NOT FOUND")
  ENDIF(CMAKE_PKGCONFIG_EXECUTABLE)

  MESSAGE("DEBUG: CMAKE_PKGCONFIG_C_FLAGS=${CMAKE_PKGCONFIG_C_FLAGS}")
  MESSAGE("DEBUG: PKGCONFIG_LIBRARIES=${PKGCONFIG_LIBRARIES}")
ENDMACRO(PKGCONFIG)

--ReaqsoxgOBHFXBhH--


From bogus@does.not.exist.com  Fri Oct 24 11:30:41 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 15:30:41 -0000
Subject: No subject
Message-ID: <mailman.11.1414164683.19642.cmake@cmake.org>

         INSTALL_FILES(<dir> regexp)

       Any files in the *current source directory* that match the regular
       expression will be installed.

(Emphasis mine.) My guess is that you can't do a regexp install files
outside the current source dir.

Amitha.


From bill at classdesign.com  Fri Oct 24 11:31:49 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 24 Oct 2014 16:31:49 +0100
Subject: [CMake] OS X Fortran flags
Message-ID: <544A70E5.3040807@classdesign.com>

Hi,

I am building some Fortran sources and on Mac I want to make the 
resulting executable portable back to 10.7.

So I have:

if (APPLE)
   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
   set (CMAKE_OSX_DEPLOYMENT_TARGET 10.7) # Earliest version we can 
support with C++11 & libc++
   set (CMAKE_OSX_SYSROOT 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk)
endif (APPLE)

in my CMakeLists.txt.

I am building on a 10.8 system with the 10.9 SDK installed.

This all works as expected with the C and C++ sources in the project but 
the Fortran compiles are not being passed the relevant options:

-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx_version_min=10.7

The Fortran compiler is the MacPorts gcc49 itself built from sources 
using the same options so that the distributable libraries reference the 
correct system library function versions.

So what am I missing? A brief scan of the CMake sources looks like it 
should be doing this right for GNU compilers as the compiler tests 
should check for those options being supported and supply them.

Do I have to add these options to the FFLAGS in my CMakeLists.txt?

Regards
Bill.

From bill at classdesign.com  Fri Oct 24 12:44:56 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 24 Oct 2014 17:44:56 +0100
Subject: [CMake] OS X Fortran flags
In-Reply-To: <544A70E5.3040807@classdesign.com>
References: <544A70E5.3040807@classdesign.com>
Message-ID: <544A8208.7030602@classdesign.com>

A small correction:

On 24/10/2014 16:31, Bill Somerville wrote:
> Hi,
>
> I am building some Fortran sources and on Mac I want to make the 
> resulting executable portable back to 10.7.
>
> So I have:
>
> if (APPLE)
>   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
>   set (CMAKE_OSX_DEPLOYMENT_TARGET 10.7) # Earliest version we can 
> support with C++11 & libc++
>   set (CMAKE_OSX_SYSROOT 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk)
> endif (APPLE)
>
> in my CMakeLists.txt.
>
> I am building on a 10.8 system with the 10.9 SDK installed.
>
> This all works as expected with the C and C++ sources in the project 
> but the Fortran compiles are not being passed the relevant options:
>
> -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
> -mmacosx_version_min=10.7
-mmacosx-version-min=10.7
>
> The Fortran compiler is the MacPorts gcc49 itself built from sources 
> using the same options so that the distributable libraries reference 
> the correct system library function versions.
>
> So what am I missing? A brief scan of the CMake sources looks like it 
> should be doing this right for GNU compilers as the compiler tests 
> should check for those options being supported and supply them.
>
> Do I have to add these options to the FFLAGS in my CMakeLists.txt?
>
> Regards
> Bill.


From zbeekman at gmail.com  Fri Oct 24 13:09:51 2014
From: zbeekman at gmail.com (Zaak Beekman)
Date: Fri, 24 Oct 2014 13:09:51 -0400
Subject: [CMake] CMake, Xcode, and Intel Fortran? (digitalriptide)
Message-ID: <CAAbnBwaQgr_8ixk=bHKQ0Kq3pM4zykkFWsy+t8KaayoOT9agQQ@mail.gmail.com>

I suspect an issue with Xcode/Intel compilers independent of CMake. Have
you tried creating and building a new Fortran project in Xcode?

If it doesn't work, have you upgraded Xcode recently? I have no experience
with Xcode, but I do know that Apple pushed out an Xcode update recently
and that the Intel Fortran compilers, IIRC, do not yet support the latest
Xcode. That having been said, I suspect if you follow the normal procedure
for dealing with Xcode upgrades and the Intel Compilers you should be able
to use it. Head over to the Intel forums/website for more info.

-Zaak

On Fri, Oct 24, 2014 at 2:19 AM, <cmake-request at cmake.org> wrote:

> Send CMake mailing list submissions to
>         cmake at cmake.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://public.kitware.com/mailman/listinfo/cmake
> or, via email, send a message with subject or body 'help' to
>         cmake-request at cmake.org
>
> You can reach the person managing the list at
>         cmake-owner at cmake.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CMake digest..."
>
>
> Today's Topics:
>
>    1. CMake, Xcode, and Intel Fortran? (digitalriptide)
>    2. Re: Pass on Unix Signals (ctrl+c)? (digitalriptide)
>    3. The new cmake.org web site (David Cole)
>    4. Fwd: Error in compiling OKULAR using CMAKE (Sahil Sehgal)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Oct 2014 14:19:05 -0600
> From: digitalriptide <digitalriptide at gmail.com>
> To: cmake at cmake.org
> Subject: [CMake] CMake, Xcode, and Intel Fortran?
> Message-ID:
>         <CAJd=gO54nxBC4S6shJCdyZwj9rJn4HZmwvS1CawKEMUeEcSO=
> Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> In the past I was able to generate Xcode projects that contained
> Fortran files via `cmake -gXcode ..` and CMake would pick up the Intel
> Fortran compiler. This behavior seems to have changed recently,
> however. Has anyone else experienced this problem and/or found a
> workaround? Is this is an issue with CMake, Xcode, or the Intel suite?
>
> Cheers!
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 23 Oct 2014 14:22:56 -0600
> From: digitalriptide <digitalriptide at gmail.com>
> To: cmake at cmake.org
> Subject: Re: [CMake] Pass on Unix Signals (ctrl+c)?
> Message-ID:
>         <CAJd=gO7JkUsRH6d-+_m63ujD=
> Z1KJeA4nOeyUoD8OufoM4rzqg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Alternatively, what signal does CMake use to halt tests?
>
> Than you!
>
> On Thu, Oct 23, 2014 at 2:16 PM, digitalriptide
> <digitalriptide at gmail.com> wrote:
> > I have a number of tests configured in my CMakeLists.txt file, a few
> > of which need to do some cleanup after running or if they are
> > interrupted  If I run make tests, and then send a signal (via ctrl+c,
> > for example), however, these signals are not passed on to the test. Is
> > it possible to configure CMake to pass signals on to the tests that
> > are run?
> >
> > Cheers!
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 23 Oct 2014 20:23:06 -0400
> From: David Cole <DLRdave at aol.com>
> To: "cmake at cmake.org" <cmake at cmake.org>
> Subject: [CMake] The new cmake.org web site
> Message-ID:
>         <CAKME8fHa1OYWMhPR3Fgj9rO6B=
> j8_5eZcMSfAXg-v9aH9FwBJA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> The new CMake web site looks fantastic! Even on my phone... Kudos to
> everybody involved in making it look pretty after all these years of,
> well, ahem, looking slightly less pretty.......
>
> However, on this page:
> http://www.cmake.org/developer-resources/
>
> The "Dashboard" icon is a broken link. 404.
>
> But, besides that, nice work!
>
>
> Cheers,
> David C.
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 24 Oct 2014 11:49:55 +0530
> From: Sahil Sehgal <sahilsehgal1995 at gmail.com>
> To: cmake at cmake.org
> Subject: [CMake] Fwd: Error in compiling OKULAR using CMAKE
> Message-ID:
>         <
> CAEDFXffv5s_eeWW8FauLY15WvPgvfrg0GHFyOKzMRVsQ8aZtyA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> I was trying to build Okular (KDE application) in IDE (QT-creator and
> Kdevelop both). I did the following steps:
> 1.) clonned the source code of Okular
> 2.) loaded the source code in IDE
> 3.) click on the build command.
>
> I got the following error
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> */home/sahil/my/New Folder/prog/okular/build> /usr/bin/cmake
> -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug
> '/home/sahil/my/New Folder/prog/okular/'-- Found Qt-Version 5.2.1 (using
> /usr/bin/qmake)CMake Error: The following variables are used in this
> project, but they are set to NOTFOUND.Please set them or make sure they are
> set and tested correctly in the CMake files:QT_QT_INCLUDE_DIR   used as
> include directory in directory /home/sahil/my/New
> Folder/prog/okular/build/CMakeFiles/CMakeTmpCMake Error: Internal CMake
> error, TryCompile configure of cmake failedCMake Error at
> /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1316 (message):
> Unable to compile a basic Qt application.  Qt has not been found
> correctly.Call Stack (most recent call first):
> /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (find_package)
> CMakeLists.txt:3 (find_package)-- Configuring incomplete, errors
> occurred!See also "/home/sahil/my/New
> Folder/prog/okular/build/CMakeFiles/CMakeOutput.log".See also
> "/home/sahil/my/New Folder/prog/okular/build/CMakeFiles/CMakeError.log".***
> Failure: Exit code 1 ****
>
> Please suggest the possible solution
>
> Regards
> Sahil Sehgal
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://public.kitware.com/pipermail/cmake/attachments/20141024/e8173598/attachment.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: fee1.png
> Type: image/png
> Size: 213812 bytes
> Desc: not available
> URL: <
> http://public.kitware.com/pipermail/cmake/attachments/20141024/e8173598/attachment.png
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
>
> 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
>
> ------------------------------
>
> End of CMake Digest, Vol 126, Issue 27
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/4af61397/attachment.html>

From zbeekman at gmail.com  Fri Oct 24 13:39:37 2014
From: zbeekman at gmail.com (Zaak Beekman)
Date: Fri, 24 Oct 2014 13:39:37 -0400
Subject: [CMake] OS X Fortran flags (Bill Somerville)
Message-ID: <CAAbnBwbBjFGDCiGUgiHC=SwD=AEO4N1awuokzxSKz5FLrvptBw@mail.gmail.com>

Hi Bill,
I feel your pain. I suspect a CMake bug is hidden away somewhere causing
this behavior, and have struggled with this quite a lot.

I *think* explicitly passing the relevant option to the linker fixes this,
although I have some other CMake/Fortran/Mac hackery happening in my
CMakeLists.txt and I can't remember the reasoning for everything. The
following is wrapped in something like if(APPLE), and annoyingly, a
slightly different form needs to be used if passing this flag to the linker
when using the Intel compilers:

if ( CMAKE_OSX_DEPLOYMENT_TARGET )
  set ( CMAKE_EXE_LINKER_FLAGS
    "${CMAKE_EXE_LINKER_FLAGS}
-mmacosx-version-min=${CMAKE_OSX_DEPLOYMENT_TARGET}" )
endif ( CMAKE_OSX_DEPLOYMENT_TARGET )

I *suspect* this work around will fix your problem.

Some more details:
I can't seem to follow my reasoning for exactly what hacks fixed what
problems; essentially I wanted to build a redistributable binary for Mac
using Fortran sources. Some of my hackery might be to allow for statically
linked builds, but here is my basic approach. First the main CMakeLists.txt
file:

cmake_minimum_required ( VERSION 2.8.11 FATAL_ERROR )
include ( checkOutOfSource.cmake )
include ( configurePlatform.cmake )
include ( configureBuilds.cmake )
enable_language ( C )
enable_language ( Fortran )
include ( compiler-specific-settings.cmake )
project ( myproj NONE )

add_subdirectory( ${CMAKE_CURRENT_SOURCE_DIR}/src )

Have found that the order of setting certain variables can make a big
difference, and that some are better set before the project command or
between the enable_language and project command. The other relevant
commands are in configurePlatform.cmake and
compiler-specific-settings.cmake.

In configurePlatform.cmake I have:

  if ( APPLE )
    set ( CMAKE_OSX_DEPLOYMENT_TARGET "10.6"
      CACHE STRING "Oldest OS X version to compile and link for." )
    set_property ( CACHE CMAKE_OSX_DEPLOYMENT_TARGET PROPERTY STRINGS
      "10.6" "10.7" "10.8" "10.9" )
...

and then in compiler specific settings I have the modification to the
linker flags given above.

I hope this fixes your issue, and that someone with more intimate knowledge
of CMake can work on Fortran support using different compilers on Mac.



Izaak Beekman
===================================
(301)244-9367
Princeton University Doctoral Candidate
Mechanical and Aerospace Engineering
ibeekman at princeton.edu

UMD-CP Visiting Graduate Student
Aerospace Engineering
ibeekman at umiacs.umd.edu
ibeekman at umd.edu

On Fri, Oct 24, 2014 at 12:45 PM, <cmake-request at cmake.org> wrote:

> Send CMake mailing list submissions to
>         cmake at cmake.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://public.kitware.com/mailman/listinfo/cmake
> or, via email, send a message with subject or body 'help' to
>         cmake-request at cmake.org
>
> You can reach the person managing the list at
>         cmake-owner at cmake.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CMake digest..."
>
>
> Today's Topics:
>
>    1. Re: Fwd: Error in compiling OKULAR using CMAKE
>       (lfdominguez at estudiantes.uci.cu)
>    2. Re: The new cmake.org web site (Robert Maynard)
>    3. OS X Fortran flags (Bill Somerville)
>    4. Re: OS X Fortran flags (Bill Somerville)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 24 Oct 2014 02:29:51 +0000
> From: lfdominguez at estudiantes.uci.cu
> To: cmake at cmake.org
> Subject: Re: [CMake] Fwd: Error in compiling OKULAR using CMAKE
> Message-ID: <2905201.UkD8Wta6Ld at envy>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Friday 24 October 2014 11:49:55 AM Sahil Sehgal wrote:
>
>
>
>
> Hello,
>
>
>
> I was trying to build Okular (KDE application) in IDE (QT-creator and
> Kdevelop
> both). I did the following steps:
>
>
> 1.) clonned the source code of Okular
>
>
> 2.) loaded the source code in IDE
>
>
> 3.) click on the build command.
>
>
>
> I got the following error
>
>
>
> */home/sahil/my/New Folder/prog/okular/build> /usr/bin/cmake -
> DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug
> '/home/sahil/my/New Folder/prog/okular/'-- Found Qt-Version 5.2.1 (using
> /usr/bin/qmake)CMake Error: The following variables are used in this
> project, but
> they are set to NOTFOUND.Please set them or make sure they are set and
> tested
> correctly in the CMake files:QT_QT_INCLUDE_DIR   used as include directory
> in
> directory /home/sahil/my/New Folder/prog/okular/build/CMakeFiles/CMakeTmp
>
> CMake Error: Internal CMake error, TryCompile configure of cmake failed
>
> CMake Error at
> /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1316 (message):
> Unable to compile a basic Qt application.  Qt has not been found
> correctly.Call
> Stack (most recent call first):
> /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95
> (find_package)  CMakeLists.txt:3 (find_package)
>
>
> -- Configuring incomplete, errors occurred!See also "/home/sahil/my/New
> Folder/prog/okular/build/CMakeFiles/CMakeOutput.log".See also
> "/home/sahil/my/New Folder/prog/okular/build/CMakeFiles/CMakeError.log".***
> Failure: Exit code 1 ***
>
> *
> Please suggest the possible solution
>
>
>
> Regards
>
>
> Sahil Sehgal
>
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://public.kitware.com/pipermail/cmake/attachments/20141024/b62f04c8/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: This is a digitally signed message part.
> URL: <
> http://public.kitware.com/pipermail/cmake/attachments/20141024/b62f04c8/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 24 Oct 2014 08:01:52 -0400
> From: Robert Maynard <robert.maynard at kitware.com>
> To: David Cole <DLRdave at aol.com>
> Cc: "cmake at cmake.org" <cmake at cmake.org>
> Subject: Re: [CMake] The new cmake.org web site
> Message-ID:
>         <
> CAFzjYVooSBGPTk-xnJTVkhMwmvaRWY+an3x63+K9-qhFoycMgw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for finding the broken link, I have correct the url and everything
> should be working now.
>
> On Thu, Oct 23, 2014 at 8:23 PM, David Cole via CMake <cmake at cmake.org>
> wrote:
>
> > The new CMake web site looks fantastic! Even on my phone... Kudos to
> > everybody involved in making it look pretty after all these years of,
> > well, ahem, looking slightly less pretty.......
> >
> > However, on this page:
> > http://www.cmake.org/developer-resources/
> >
> > The "Dashboard" icon is a broken link. 404.
> >
> > But, besides that, nice work!
> >
> >
> > Cheers,
> > David C.
> > --
> >
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://public.kitware.com/pipermail/cmake/attachments/20141024/18d7da53/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 24 Oct 2014 16:31:49 +0100
> From: Bill Somerville <bill at classdesign.com>
> To: CMake ML <cmake at cmake.org>
> Subject: [CMake] OS X Fortran flags
> Message-ID: <544A70E5.3040807 at classdesign.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> I am building some Fortran sources and on Mac I want to make the
> resulting executable portable back to 10.7.
>
> So I have:
>
> if (APPLE)
>    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
>    set (CMAKE_OSX_DEPLOYMENT_TARGET 10.7) # Earliest version we can
> support with C++11 & libc++
>    set (CMAKE_OSX_SYSROOT
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk)
> endif (APPLE)
>
> in my CMakeLists.txt.
>
> I am building on a 10.8 system with the 10.9 SDK installed.
>
> This all works as expected with the C and C++ sources in the project but
> the Fortran compiles are not being passed the relevant options:
>
> -isysroot
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
> -mmacosx_version_min=10.7
>
> The Fortran compiler is the MacPorts gcc49 itself built from sources
> using the same options so that the distributable libraries reference the
> correct system library function versions.
>
> So what am I missing? A brief scan of the CMake sources looks like it
> should be doing this right for GNU compilers as the compiler tests
> should check for those options being supported and supply them.
>
> Do I have to add these options to the FFLAGS in my CMakeLists.txt?
>
> Regards
> Bill.
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 24 Oct 2014 17:44:56 +0100
> From: Bill Somerville <bill at classdesign.com>
> To: cmake at cmake.org
> Subject: Re: [CMake] OS X Fortran flags
> Message-ID: <544A8208.7030602 at classdesign.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> A small correction:
>
> On 24/10/2014 16:31, Bill Somerville wrote:
> > Hi,
> >
> > I am building some Fortran sources and on Mac I want to make the
> > resulting executable portable back to 10.7.
> >
> > So I have:
> >
> > if (APPLE)
> >   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
> >   set (CMAKE_OSX_DEPLOYMENT_TARGET 10.7) # Earliest version we can
> > support with C++11 & libc++
> >   set (CMAKE_OSX_SYSROOT
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk)
> > endif (APPLE)
> >
> > in my CMakeLists.txt.
> >
> > I am building on a 10.8 system with the 10.9 SDK installed.
> >
> > This all works as expected with the C and C++ sources in the project
> > but the Fortran compiles are not being passed the relevant options:
> >
> > -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
> > -mmacosx_version_min=10.7
> -mmacosx-version-min=10.7
> >
> > The Fortran compiler is the MacPorts gcc49 itself built from sources
> > using the same options so that the distributable libraries reference
> > the correct system library function versions.
> >
> > So what am I missing? A brief scan of the CMake sources looks like it
> > should be doing this right for GNU compilers as the compiler tests
> > should check for those options being supported and supply them.
> >
> > Do I have to add these options to the FFLAGS in my CMakeLists.txt?
> >
> > Regards
> > Bill.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
>
> 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
>
> ------------------------------
>
> End of CMake Digest, Vol 126, Issue 28
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/109b8cd6/attachment-0001.html>

From bill at classdesign.com  Fri Oct 24 14:03:14 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 24 Oct 2014 19:03:14 +0100
Subject: [CMake] OS X Fortran flags (Bill Somerville)
In-Reply-To: <CAAbnBwbBjFGDCiGUgiHC=SwD=AEO4N1awuokzxSKz5FLrvptBw@mail.gmail.com>
References: <CAAbnBwbBjFGDCiGUgiHC=SwD=AEO4N1awuokzxSKz5FLrvptBw@mail.gmail.com>
Message-ID: <544A9462.7020601@classdesign.com>

On 24/10/2014 18:39, Zaak Beekman wrote:
> Hi Bill,
Hi Zaak,

thanks for the detailed suggestions, more comments in line below.

> I feel your pain. I suspect a CMake bug is hidden away somewhere 
> causing this behavior, and have struggled with this quite a lot.
I think you are correct.
>
> I *think* explicitly passing the relevant option to the linker fixes 
> this, although I have some other CMake/Fortran/Mac hackery happening 
> in my CMakeLists.txt and I can?t remember the reasoning for 
> everything. The following is wrapped in something like if(APPLE), and 
> annoyingly, a slightly different form needs to be used if passing this 
> flag to the linker when using the Intel compilers:
>
> if ( CMAKE_OSX_DEPLOYMENT_TARGET )
>  set ( CMAKE_EXE_LINKER_FLAGS
>  "${CMAKE_EXE_LINKER_FLAGS} 
> -mmacosx-version-min=${CMAKE_OSX_DEPLOYMENT_TARGET}" )
> endif ( CMAKE_OSX_DEPLOYMENT_TARGET )
>
> I *suspect* this work around will fix your problem.
Well in my case it is the compiler flags that need adding to.

I think what is happening is that the compiler is using an intrinsic 
system call __stret_sincos to optimize sin and cos calculations with the 
same arguments, this is only available on 10.9 so builds done on 10.9 
will not run on earlier versions of OS X unless 
-mmacosx-version-min=<version> is specified. This is exactly the reason 
for the whole deployment target switch.

I don't know ifort so don't know if it has similar options or even if it 
uses system calls that are that new. But for sure passing linker flags 
is only part of the solution.
>
> Some more details:
> I can?t seem to follow my reasoning for exactly what hacks fixed what 
> problems; essentially I wanted to build a redistributable binary for 
> Mac using Fortran sources. Some of my hackery might be to allow for 
> statically linked builds, but here is my basic approach. First the 
> main CMakeLists.txt file:
Steering clear of static builds for our project. We have a application 
bundle as out Mac deployable so we include any frameworks and extra 
support dylibs within that.
>
> cmake_minimum_required ( VERSION 2.8.11 FATAL_ERROR )
> include ( checkOutOfSource.cmake )
> include ( configurePlatform.cmake )
> include ( configureBuilds.cmake )
> enable_language ( C )
> enable_language ( Fortran )
> include ( compiler-specific-settings.cmake )
> project ( myproj NONE )
>
> add_subdirectory( ${CMAKE_CURRENT_SOURCE_DIR}/src )
>
> Have found that the order of setting certain variables can make a big 
> difference, and that some are better set before the project command or 
> between the enable_language and project command. The other relevant 
> commands are in configurePlatform.cmake and 
> compiler-specific-settings.cmake.
>
> In configurePlatform.cmake I have:
>
>   if ( APPLE )
>     set ( CMAKE_OSX_DEPLOYMENT_TARGET "10.6"
>       CACHE STRING "Oldest OS X version to compile and link for." )
>     set_property ( CACHE CMAKE_OSX_DEPLOYMENT_TARGET PROPERTY STRINGS
>       "10.6" "10.7" "10.8" "10.9" )
> ?
>
> and then in compiler specific settings I have the modification to the 
> linker flags given above.
>
> I hope this fixes your issue, and that someone with more intimate 
> knowledge of CMake can work on Fortran support using different 
> compilers on Mac.
I am rebuilding right now with manually set options. I agree better 
Fortran compiler support on Mac seems necessary.
>
>
>
> Izaak Beekman
> ===================================
> (301)244-9367
> Princeton University Doctoral Candidate
> Mechanical and Aerospace Engineering
> ibeekman at princeton.edu <mailto:ibeekman at princeton.edu>
>
> UMD-CP Visiting Graduate Student
> Aerospace Engineering
> ibeekman at umiacs.umd.edu <mailto:ibeekman at umiacs.umd.edu>
> ibeekman at umd.edu <mailto:ibeekman at umd.edu>
>
Regards
Bill.
>
>     Message: 3
>     Date: Fri, 24 Oct 2014 16:31:49 +0100
>     From: Bill Somerville <bill at classdesign.com
>     <mailto:bill at classdesign.com>>
>     To: CMake ML <cmake at cmake.org <mailto:cmake at cmake.org>>
>     Subject: [CMake] OS X Fortran flags
>     Message-ID: <544A70E5.3040807 at classdesign.com
>     <mailto:544A70E5.3040807 at classdesign.com>>
>     Content-Type: text/plain; charset=utf-8; format=flowed
>
>     Hi,
>
>     I am building some Fortran sources and on Mac I want to make the
>     resulting executable portable back to 10.7.
>
>     So I have:
>
>     if (APPLE)
>        set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
>        set (CMAKE_OSX_DEPLOYMENT_TARGET 10.7) # Earliest version we can
>     support with C++11 & libc++
>        set (CMAKE_OSX_SYSROOT
>     /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk)
>     endif (APPLE)
>
>     in my CMakeLists.txt.
>
>     I am building on a 10.8 system with the 10.9 SDK installed.
>
>     This all works as expected with the C and C++ sources in the
>     project but
>     the Fortran compiles are not being passed the relevant options:
>
>     -isysroot
>     /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
>     -mmacosx_version_min=10.7
>
>     The Fortran compiler is the MacPorts gcc49 itself built from sources
>     using the same options so that the distributable libraries
>     reference the
>     correct system library function versions.
>
>     So what am I missing? A brief scan of the CMake sources looks like it
>     should be doing this right for GNU compilers as the compiler tests
>     should check for those options being supported and supply them.
>
>     Do I have to add these options to the FFLAGS in my CMakeLists.txt?
>
>     Regards
>     Bill.
>
>
>     ------------------------------
>
>     Message: 4
>     Date: Fri, 24 Oct 2014 17:44:56 +0100
>     From: Bill Somerville <bill at classdesign.com
>     <mailto:bill at classdesign.com>>
>     To: cmake at cmake.org <mailto:cmake at cmake.org>
>     Subject: Re: [CMake] OS X Fortran flags
>     Message-ID: <544A8208.7030602 at classdesign.com
>     <mailto:544A8208.7030602 at classdesign.com>>
>     Content-Type: text/plain; charset=windows-1252; format=flowed
>
>     A small correction:
>
>     On 24/10/2014 16:31, Bill Somerville wrote:
>     > Hi,
>     >
>     > I am building some Fortran sources and on Mac I want to make the
>     > resulting executable portable back to 10.7.
>     >
>     > So I have:
>     >
>     > if (APPLE)
>     >   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
>     >   set (CMAKE_OSX_DEPLOYMENT_TARGET 10.7) # Earliest version we can
>     > support with C++11 & libc++
>     >   set (CMAKE_OSX_SYSROOT
>     >
>     /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk)
>     > endif (APPLE)
>     >
>     > in my CMakeLists.txt.
>     >
>     > I am building on a 10.8 system with the 10.9 SDK installed.
>     >
>     > This all works as expected with the C and C++ sources in the project
>     > but the Fortran compiles are not being passed the relevant options:
>     >
>     > -isysroot
>     >
>     /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
>     > -mmacosx_version_min=10.7
>     -mmacosx-version-min=10.7
>     >
>     > The Fortran compiler is the MacPorts gcc49 itself built from sources
>     > using the same options so that the distributable libraries reference
>     > the correct system library function versions.
>     >
>     > So what am I missing? A brief scan of the CMake sources looks
>     like it
>     > should be doing this right for GNU compilers as the compiler tests
>     > should check for those options being supported and supply them.
>     >
>     > Do I have to add these options to the FFLAGS in my CMakeLists.txt?
>     >
>     > Regards
>     > Bill.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/817774c7/attachment.html>

From brad.king at kitware.com  Fri Oct 24 14:11:28 2014
From: brad.king at kitware.com (Brad King)
Date: Fri, 24 Oct 2014 14:11:28 -0400
Subject: [CMake] OS X Fortran flags
In-Reply-To: <544A70E5.3040807@classdesign.com>
References: <544A70E5.3040807@classdesign.com>
Message-ID: <544A9650.20802@kitware.com>

On 10/24/2014 11:31 AM, Bill Somerville wrote:
> So what am I missing? A brief scan of the CMake sources looks like it 
> should be doing this right for GNU compilers as the compiler tests 
> should check for those options being supported and supply them.

It looks like a couple of lines are missing for Fortran.
Please try the patch below (untested).

Thanks,
-Brad


diff --git a/Modules/Platform/Darwin-GNU-Fortran.cmake b/Modules/Platform/Darwin-GNU-Fortran.cmake
index f4b509a..6724f9b 100644
--- a/Modules/Platform/Darwin-GNU-Fortran.cmake
+++ b/Modules/Platform/Darwin-GNU-Fortran.cmake
@@ -14,6 +14,8 @@

 include(Platform/Darwin-GNU)
 __darwin_compiler_gnu(Fortran)
+cmake_gnu_set_sysroot_flag(Fortran)
+cmake_gnu_set_osx_deployment_target_flag(Fortran)

 set(CMAKE_Fortran_OSX_COMPATIBILITY_VERSION_FLAG "-compatibility_version ")
 set(CMAKE_Fortran_OSX_CURRENT_VERSION_FLAG "-current_version ")


From bill at classdesign.com  Fri Oct 24 14:15:23 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 24 Oct 2014 19:15:23 +0100
Subject: [CMake] OS X Fortran flags
In-Reply-To: <544A9650.20802@kitware.com>
References: <544A70E5.3040807@classdesign.com> <544A9650.20802@kitware.com>
Message-ID: <544A973B.7090708@classdesign.com>

On 24/10/2014 19:11, Brad King wrote:
HI Brad,
> On 10/24/2014 11:31 AM, Bill Somerville wrote:
>> So what am I missing? A brief scan of the CMake sources looks like it
>> should be doing this right for GNU compilers as the compiler tests
>> should check for those options being supported and supply them.
> It looks like a couple of lines are missing for Fortran.
> Please try the patch below (untested).
Thanks for looking at this so quickly.

Can I just put the patched module in my project Modules directory or do 
I have to build the whole CMake project?
>
> Thanks,
> -Brad
Regards
Bill.
>
>
> diff --git a/Modules/Platform/Darwin-GNU-Fortran.cmake b/Modules/Platform/Darwin-GNU-Fortran.cmake
> index f4b509a..6724f9b 100644
> --- a/Modules/Platform/Darwin-GNU-Fortran.cmake
> +++ b/Modules/Platform/Darwin-GNU-Fortran.cmake
> @@ -14,6 +14,8 @@
>
>   include(Platform/Darwin-GNU)
>   __darwin_compiler_gnu(Fortran)
> +cmake_gnu_set_sysroot_flag(Fortran)
> +cmake_gnu_set_osx_deployment_target_flag(Fortran)
>
>   set(CMAKE_Fortran_OSX_COMPATIBILITY_VERSION_FLAG "-compatibility_version ")
>   set(CMAKE_Fortran_OSX_CURRENT_VERSION_FLAG "-current_version ")
>


From brad.king at kitware.com  Fri Oct 24 14:16:35 2014
From: brad.king at kitware.com (Brad King)
Date: Fri, 24 Oct 2014 14:16:35 -0400
Subject: [CMake] OS X Fortran flags
In-Reply-To: <544A973B.7090708@classdesign.com>
References: <544A70E5.3040807@classdesign.com> <544A9650.20802@kitware.com>
 <544A973B.7090708@classdesign.com>
Message-ID: <544A9783.50308@kitware.com>

On 10/24/2014 02:15 PM, Bill Somerville wrote:
> Can I just put the patched module in my project Modules directory or do 
> I have to build the whole CMake project?

No need to recompile.  You can just add the two lines directly in your
Modules directory.

-Brad


From jose.passes at gmx.com  Fri Oct 24 14:28:10 2014
From: jose.passes at gmx.com (=?UTF-8?B?WsOp?=)
Date: Fri, 24 Oct 2014 19:28:10 +0100
Subject: [CMake] CMake unit tests and the enable_testing() macro
Message-ID: <544A9A3A.4050606@gmx.com>

I'm test-driving CMake for a new project I've just started and I'm 
currently trying to set up a unit test framework.  The project is a 
dynamic library written in C++, the unit tests are based on Boost test, 
and the project tree is organized essentially as follows:

.
??? CMakeLists.txt
??? mylibrary
?   ??? CMakeLists.txt
?   ??? sample.c++
??? unit_tests
     ??? CMakeLists.txt
     ??? test_sample.c++



I believe that I've managed to get things up and running, but in the 
process I've stumbled on an issue.

Apparently, if I call the enable_testing() macro within 
${Project}/unit_tests/CMakeLists.txt, calling make test does nothing, 
and the following error message is shown:

     make: *** No rule to make target `test'.  Stop.


Yet, if enable_testing() is called from ${Project}/CMakeLists.txt, 
calling make test runs as expected.

Am I missing something?



Thanks

From nilsgladitz at gmail.com  Fri Oct 24 14:39:31 2014
From: nilsgladitz at gmail.com (Nils Gladitz)
Date: Fri, 24 Oct 2014 20:39:31 +0200
Subject: [CMake] CMake unit tests and the enable_testing() macro
In-Reply-To: <544A9A3A.4050606@gmx.com>
References: <544A9A3A.4050606@gmx.com>
Message-ID: <544A9CE3.2090901@gmail.com>

On 24.10.2014 20:28, Z? wrote:
> I'm test-driving CMake for a new project I've just started and I'm 
> currently trying to set up a unit test framework.  The project is a 
> dynamic library written in C++, the unit tests are based on Boost 
> test, and the project tree is organized essentially as follows:
>
> .
> ??? CMakeLists.txt
> ??? mylibrary
> ?   ??? CMakeLists.txt
> ?   ??? sample.c++
> ??? unit_tests
>     ??? CMakeLists.txt
>     ??? test_sample.c++
>
>
>
> I believe that I've managed to get things up and running, but in the 
> process I've stumbled on an issue.
>
> Apparently, if I call the enable_testing() macro within 
> ${Project}/unit_tests/CMakeLists.txt, calling make test does nothing, 
> and the following error message is shown:
>
>     make: *** No rule to make target `test'.  Stop.
>
>
> Yet, if enable_testing() is called from ${Project}/CMakeLists.txt, 
> calling make test runs as expected.
>
> Am I missing something?

"Enable testing for current directory and below."

For the Makefile generator this means that test targets are created for 
the build directory that corresponds to the current source directory and 
directories below.

If your only enable_testing() call is in <SOURCE_DIR>/unit_tests you 
should be able to run "make test" in the corresponding 
<BUILD_DIR>/unit_tests directory but not from <BUILD_DIR>.

In theory you can use this to run tests selectively depending on which 
directory they are in.

Nils

From robert.maynard at kitware.com  Fri Oct 24 15:43:17 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 24 Oct 2014 15:43:17 -0400
Subject: [CMake] Is this the proper way to define a package config?
In-Reply-To: <CAHd499AttEVRSmxLi02Dy5KX=YrCmRx-ViV_cd38XT=29aoLRQ@mail.gmail.com>
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
 <1867592.YW9fbP6utO@ersa>
 <CAHd499AttEVRSmxLi02Dy5KX=YrCmRx-ViV_cd38XT=29aoLRQ@mail.gmail.com>
Message-ID: <CAFzjYVpSZS+E20ozYS69+kg_u0AtwY0rpmcKrpsUksbOyUHgSg@mail.gmail.com>

As far as I am aware the Boost find module doesn't support writing out
import targets.

As far as setting up interface libraries for imported tagets you want to
use the
IMPORTED_LINK_INTERFACE_LIBRARIES and
IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG> properties.

Here is an example:

set_target_properties(Filters PROPERTIES
  IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG
"Common;/usr/local/lib/libzmq.3.dylib"
)

Note that Common in this example is another imported target.

On Thu, Oct 23, 2014 at 12:53 PM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> Thanks for the reply!
>
> Basically the boost library I have is precompiled and in my own unique
> structure. I do not plan to distribute the CMake scripts I write, they
> are for personal / internal usage only.
>
> You suggested a find module, but will this also generate a custom
> target for boost? That's important so that when I do
> target_link_libraries(), I can pass in "boost" and everything is
> handled for me. I do not want to be working with libs & header files
> directly in each executable or library I define that has a dependency
> on boost.
>
> Thanks again.
>
> On Thu, Oct 23, 2014 at 4:59 AM, Johannes Zarl <johannes.zarl at jku.at>
> wrote:
> > Hi,
> >
> > Assuming you are not a boost developer / your changes won't be
> upstreamed,
> > then creating a BoostConfig.cmake file won't do you much good. If
> someone wants
> > to use your project, he/she will have to patch the locally installed
> boost
> > version to include a BoostConfig.cmake file.
> >
> > You might want to have a look into the FindBoost[1] module of cmake.
> >
> > XXXConfig.cmake files are intended to be written by the creator of a
> package,
> > FindXXX.cmake packages are intended as a workaround when a package does
> not
> > contain an XXXConfig.cmake file and are usually written by a consumer of
> a
> > package.
> >
> > HTH,
> >   Johannes
> >
> > [1] http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html
> >
> > On Friday 17 October 2014 00:18:34 Robert Dailey wrote:
> >> I have a local package of boost built on Windows. It is always
> >> relative to the root of my project at a consistent structure and
> >> location. I wanted to define an import target for this and thought it
> >> might be best to define a BoostConfig.cmake package config file at the
> >> root of the boost lib directory. Is this the right approach? The code
> >> is below.
> >>
> >> Note that I do not have this working just yet because I don't know how
> >> to properly setup the interface link libraries. Could use some
> >> guidance here too... thanks.
> >>
> >> add_library( Boost STATIC IMPORTED GLOBAL )
> >>
> >> file( GLOB boost_debug_libs
> ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib
> >> ) file( GLOB boost_release_libs
> >> ${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
> >>
> >> set_target_properties( Boost PROPERTIES
> >>     IMPORTED_LOCATION_DEBUG lib/win32/debug
> >>     IMPORTED_LOCATION_RELEASE lib/win32/release
> >>     INTERFACE_INCLUDE_DIRECTORIES include
> >>     INTERFACE_LINK_LIBRARIES
> >>         $<$<CONFIG:Debug>:${boost_debug_libs}>
> >>         $<$<CONFIG:Release>:${boost_release_libs}>
> >> )
> >>
> >> set( Boost_INCLUDE_DIRS include )
> >> set( Boost_LIBRARIES Boost )
> >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/8307e89f/attachment.html>

From bill at classdesign.com  Fri Oct 24 16:29:32 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 24 Oct 2014 21:29:32 +0100
Subject: [CMake] OS X Fortran flags
In-Reply-To: <544A9783.50308@kitware.com>
References: <544A70E5.3040807@classdesign.com> <544A9650.20802@kitware.com>
 <544A973B.7090708@classdesign.com> <544A9783.50308@kitware.com>
Message-ID: <544AB6AC.5020305@classdesign.com>

On 24/10/2014 19:16, Brad King wrote:
Hi Brad,
> On 10/24/2014 02:15 PM, Bill Somerville wrote:
>> Can I just put the patched module in my project Modules directory or do
>> I have to build the whole CMake project?
> No need to recompile.  You can just add the two lines directly in your
> Modules directory.
Sorry, I am struggling with this. I have copied the 
Darwin-GNU-Fortran.cmake file into my project modules directory and 
patched it as you suggested. I have tried putting it into a subdirectory 
called Platform/ as well. I have added my local modules path to the 
CMAKE_MODULE_PATH before the default items. This is set before the 
project() command in the project CMakelists.txt but it is not being 
picked up. Is there something I am missing or do I need to do this a 
different way?

The good news is that it works when I patch the file in the actual CMake 
installation although there is an oddity, when I configure the project I 
see the messages from those two new function calls in the Fortran checks 
but strangely I don't see similar messages from the C and C++ compiler 
checks, yet they all seem to work adding the correct options.
>
> -Brad
>
Regards
Bill.

From a.neundorf-work at gmx.net  Fri Oct 24 16:37:47 2014
From: a.neundorf-work at gmx.net (Alexander Neundorf)
Date: Fri, 24 Oct 2014 22:37:47 +0200
Subject: [CMake] Fwd: Error in compiling OKULAR using CMAKE
In-Reply-To: <CAEDFXffv5s_eeWW8FauLY15WvPgvfrg0GHFyOKzMRVsQ8aZtyA@mail.gmail.com>
References: <CAEDFXffYtcHpESD8vTucFz_TXTxm8GqtpFjnqvr=GCHAjq5LFA@mail.gmail.com>
 <CAEDFXffv5s_eeWW8FauLY15WvPgvfrg0GHFyOKzMRVsQ8aZtyA@mail.gmail.com>
Message-ID: <7572765.I7qk8HULin@tuxedo.neundorf.net>

On Friday, October 24, 2014 11:49:55 Sahil Sehgal wrote:
> Hello,
> 
> I was trying to build Okular (KDE application) in IDE (QT-creator and
> Kdevelop both). I did the following steps:
> 1.) clonned the source code of Okular
> 2.) loaded the source code in IDE
> 3.) click on the build command.
> 
> I got the following error
> 
> 
> */home/sahil/my/New Folder/prog/okular/build> /usr/bin/cmake
> -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug
> '/home/sahil/my/New Folder/prog/okular/'-- Found Qt-Version 5.2.1 (using
> /usr/bin/qmake)CMake Error: The following variables are used in this
> project, but they are set to NOTFOUND.Please set them or make sure they are
> set and tested correctly in the CMake files:QT_QT_INCLUDE_DIR

the Qt include dir has not been found. Do you have the Qt development packages 
installed ?

Alex


From scott.bloom at onshorecs.com  Fri Oct 24 17:29:59 2014
From: scott.bloom at onshorecs.com (Scott Aron Bloom)
Date: Fri, 24 Oct 2014 21:29:59 +0000
Subject: [CMake] Qt5 + cmake 3.0
Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E3E4054@WIN-R92V03RFJ85.onshorecs.local>

So I may be taking on too much.. but I am migrating to Qt5 and Cmake 3.0 on my project (from Qt4.8 and CMake 2.8)

I have minimized the project to a simple testcase that will represent the problem, and it still exists.

My project, has multiple executables and multiple libraries for each exec.  For the test, it's a simple single exec with 1 library.

Since in real life, I have multiple libraries, each library includes the ${CMAKE_SOURCE_DIR}/project.cmake file, to setup the settings the projects share in common.

In this file, I previously called include( ${QT_USE_FILE} ) to make sure the necessary include paths were setup correctly
However, for Qt5, this has been replaced with modifying the target_link_libraries to include Qt5::Widgets (or the other necessary components)

And the qt5_use_modules( MyLibrary Core )

The problem, is then I would need to call this, inside every libraries CMake file, since its required to know the "current project"

Is there anyway around this issue? Where I could just add the necessary Qt 5 modules to current project?

Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141024/bd21c8a7/attachment-0001.html>

From rcdailey.lists at gmail.com  Fri Oct 24 20:45:54 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 24 Oct 2014 19:45:54 -0500
Subject: [CMake] Is this the proper way to define a package config?
In-Reply-To: <CAFzjYVpSZS+E20ozYS69+kg_u0AtwY0rpmcKrpsUksbOyUHgSg@mail.gmail.com>
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
 <1867592.YW9fbP6utO@ersa>
 <CAHd499AttEVRSmxLi02Dy5KX=YrCmRx-ViV_cd38XT=29aoLRQ@mail.gmail.com>
 <CAFzjYVpSZS+E20ozYS69+kg_u0AtwY0rpmcKrpsUksbOyUHgSg@mail.gmail.com>
Message-ID: <CAHd499De91XzWEG0kfeDK6N22=59zc0pOTAfc6O6QvFKBXui0Q@mail.gmail.com>

What is the "Filters" target here? How is it created? Would I just
create a target called Boost and configure it as needed?

On Fri, Oct 24, 2014 at 2:43 PM, Robert Maynard
<robert.maynard at kitware.com> wrote:
> As far as I am aware the Boost find module doesn't support writing out
> import targets.
>
> As far as setting up interface libraries for imported tagets you want to use
> the
> IMPORTED_LINK_INTERFACE_LIBRARIES and
> IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG> properties.
>
> Here is an example:
>
> set_target_properties(Filters PROPERTIES
>   IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG
> "Common;/usr/local/lib/libzmq.3.dylib"
> )
>
> Note that Common in this example is another imported target.
>
> On Thu, Oct 23, 2014 at 12:53 PM, Robert Dailey <rcdailey.lists at gmail.com>
> wrote:
>>
>> Thanks for the reply!
>>
>> Basically the boost library I have is precompiled and in my own unique
>> structure. I do not plan to distribute the CMake scripts I write, they
>> are for personal / internal usage only.
>>
>> You suggested a find module, but will this also generate a custom
>> target for boost? That's important so that when I do
>> target_link_libraries(), I can pass in "boost" and everything is
>> handled for me. I do not want to be working with libs & header files
>> directly in each executable or library I define that has a dependency
>> on boost.
>>
>> Thanks again.
>>
>> On Thu, Oct 23, 2014 at 4:59 AM, Johannes Zarl <johannes.zarl at jku.at>
>> wrote:
>> > Hi,
>> >
>> > Assuming you are not a boost developer / your changes won't be
>> > upstreamed,
>> > then creating a BoostConfig.cmake file won't do you much good. If
>> > someone wants
>> > to use your project, he/she will have to patch the locally installed
>> > boost
>> > version to include a BoostConfig.cmake file.
>> >
>> > You might want to have a look into the FindBoost[1] module of cmake.
>> >
>> > XXXConfig.cmake files are intended to be written by the creator of a
>> > package,
>> > FindXXX.cmake packages are intended as a workaround when a package does
>> > not
>> > contain an XXXConfig.cmake file and are usually written by a consumer of
>> > a
>> > package.
>> >
>> > HTH,
>> >   Johannes
>> >
>> > [1] http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html
>> >
>> > On Friday 17 October 2014 00:18:34 Robert Dailey wrote:
>> >> I have a local package of boost built on Windows. It is always
>> >> relative to the root of my project at a consistent structure and
>> >> location. I wanted to define an import target for this and thought it
>> >> might be best to define a BoostConfig.cmake package config file at the
>> >> root of the boost lib directory. Is this the right approach? The code
>> >> is below.
>> >>
>> >> Note that I do not have this working just yet because I don't know how
>> >> to properly setup the interface link libraries. Could use some
>> >> guidance here too... thanks.
>> >>
>> >> add_library( Boost STATIC IMPORTED GLOBAL )
>> >>
>> >> file( GLOB boost_debug_libs
>> >> ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib
>> >> ) file( GLOB boost_release_libs
>> >> ${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
>> >>
>> >> set_target_properties( Boost PROPERTIES
>> >>     IMPORTED_LOCATION_DEBUG lib/win32/debug
>> >>     IMPORTED_LOCATION_RELEASE lib/win32/release
>> >>     INTERFACE_INCLUDE_DIRECTORIES include
>> >>     INTERFACE_LINK_LIBRARIES
>> >>         $<$<CONFIG:Debug>:${boost_debug_libs}>
>> >>         $<$<CONFIG:Release>:${boost_release_libs}>
>> >> )
>> >>
>> >> set( Boost_INCLUDE_DIRS include )
>> >> set( Boost_LIBRARIES Boost )
>> >
>> > --
>> >
>> > 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
>
>

From steveire at gmail.com  Sat Oct 25 02:07:47 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 25 Oct 2014 08:07:47 +0200
Subject: [CMake] Qt5 + cmake 3.0
References: <6FD2E165340D9A429CF831C7A2D4F42E4E3E4054@WIN-R92V03RFJ85.onshorecs.local>
Message-ID: <m2fenj$v6h$1@ger.gmane.org>

Scott Aron Bloom wrote:

> I have minimized the project to a simple testcase that will represent the
> problem, and it still exists.

You didn't attach it, right?

> In this file, I previously called include( ${QT_USE_FILE} ) to make sure
> the necessary include paths were setup correctly However, for Qt5, this
> has been replaced with modifying the target_link_libraries to include
> Qt5::Widgets (or the other necessary components)

Everything that works with Qt 5 works with Qt 4. You could use more 
intermediate steps to understand whatever problem it is you're hitting.
 
> And the qt5_use_modules( MyLibrary Core )

According to the Qt 5 documentation, you shouldn't use this after CMake 
2.8.11.

> 
> The problem, is then I would need to call this, inside every libraries
> CMake file, since its required to know the "current project"
> 
> Is there anyway around this issue? Where I could just add the necessary Qt
> 5 modules to current project?

I don't understand the problem. Do you just need to add a find_package?

Thanks,

Steve.



From steveire at gmail.com  Sat Oct 25 02:08:40 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 25 Oct 2014 08:08:40 +0200
Subject: [CMake] Is this the proper way to define a package config?
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
 <1867592.YW9fbP6utO@ersa>
 <CAHd499AttEVRSmxLi02Dy5KX=YrCmRx-ViV_cd38XT=29aoLRQ@mail.gmail.com>
 <CAFzjYVpSZS+E20ozYS69+kg_u0AtwY0rpmcKrpsUksbOyUHgSg@mail.gmail.com>
 <CAHd499De91XzWEG0kfeDK6N22=59zc0pOTAfc6O6QvFKBXui0Q@mail.gmail.com>
Message-ID: <m2fep8$v6h$2@ger.gmane.org>

Robert Dailey wrote:

> What is the "Filters" target here? How is it created? Would I just
> create a target called Boost and configure it as needed?

You've read  

 http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages

right?

Thanks,

Steve.



From jose.passes at gmx.com  Sat Oct 25 08:11:58 2014
From: jose.passes at gmx.com (=?ISO-8859-1?Q?Z=E9?=)
Date: Sat, 25 Oct 2014 13:11:58 +0100
Subject: [CMake] How to store function definitions?
Message-ID: <544B938E.3030606@gmx.com>

I've defined a small function that helps add unit test definitions in a 
concise manner.  I would like to store this function on a dedicated file 
to decluter the CMakeLists.txt file where that function is currently 
defined.  Can anyone tell me what's the best way to store custom 
function definitions within a project tree?


Thanks,

From eric.noulard at gmail.com  Sat Oct 25 11:38:31 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Sat, 25 Oct 2014 17:38:31 +0200
Subject: [CMake] How to store function definitions?
In-Reply-To: <544B938E.3030606@gmx.com>
References: <544B938E.3030606@gmx.com>
Message-ID: <CAPASGLoCq8O-4xaKQSRGkUXPjU+C=M-ZZVhO_BQj4SXcKeLrcw@mail.gmail.com>

2014-10-25 14:11 GMT+02:00 Z? <jose.passes at gmx.com>:

> I've defined a small function that helps add unit test definitions in a
> concise manner.  I would like to store this function on a dedicated file to
> decluter the CMakeLists.txt file where that function is currently defined.
> Can anyone tell me what's the best way to store custom function definitions
> within a project tree?
>

I don't know whether if there is "THE" best way but my habit is the
following:

put all custom cmake scripts into a project subdir call
<PROJECT_ROOT>/cmake/ or sometimes <PROJECT_ROOT>/devel-scripts because I
put there other development oriented scripts written in
CMake, shell, python etc...

Then in my main CMakeLists.txt I add the dir to the CMake module path:

# Add project source dir as module path
list(APPEND CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/devel-scripts)

then when I need the macros defined in say "MyTestTools.cmake" I do:

include(MyTestTools.cmake)


I don't really know if it's the best way, but it works ok and makes it easy
to add more custom macro files when needed.


-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141025/11d58f9f/attachment.html>

From rcdailey.lists at gmail.com  Sat Oct 25 13:21:31 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Sat, 25 Oct 2014 12:21:31 -0500
Subject: [CMake] Is this the proper way to define a package config?
In-Reply-To: <m2fep8$v6h$2@ger.gmane.org>
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
 <1867592.YW9fbP6utO@ersa>
 <CAHd499AttEVRSmxLi02Dy5KX=YrCmRx-ViV_cd38XT=29aoLRQ@mail.gmail.com>
 <CAFzjYVpSZS+E20ozYS69+kg_u0AtwY0rpmcKrpsUksbOyUHgSg@mail.gmail.com>
 <CAHd499De91XzWEG0kfeDK6N22=59zc0pOTAfc6O6QvFKBXui0Q@mail.gmail.com>
 <m2fep8$v6h$2@ger.gmane.org>
Message-ID: <CAHd499DJYQBPmnPZF0jL8oPx1wcy-KEu=d5xtDUYj0m_-TwSxw@mail.gmail.com>

I've skimmed over it, but I haven't seen anything useful in that
section. Maybe you can point out what exactly I'm supposed to use from
that?

Someone has already stated that I should use a find module and not
define a package config since I'm not the maintainer of boost, I only
need to use it. Are you suggesting the opposite, that I should define
a package config as a downstream consumer?

On Sat, Oct 25, 2014 at 1:08 AM, Stephen Kelly <steveire at gmail.com> wrote:
> Robert Dailey wrote:
>
>> What is the "Filters" target here? How is it created? Would I just
>> create a target called Boost and configure it as needed?
>
> You've read
>
>  http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
>
> right?
>
> Thanks,
>
> Steve.
>
>
> --
>
> 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

From Colony.Three at protonmail.ch  Sat Oct 25 14:33:37 2014
From: Colony.Three at protonmail.ch (Colony.Three)
Date: Sat, 25 Oct 2014 14:33:37 -0400
Subject: [CMake] App Crash on Any Action in Context Menu
Message-ID: <617e990dc447407d0bc25ce4cd14c9a0@protonmail.ch>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141025/1e78a579/attachment-0001.html>

From Colony.Three at protonmail.ch  Sat Oct 25 14:31:06 2014
From: Colony.Three at protonmail.ch (Colony.Three)
Date: Sat, 25 Oct 2014 14:31:06 -0400
Subject: [CMake] App Crash on Any Action in Context Menu
Message-ID: <5922c933ad7c2a77dad3c74c576f7a2d@protonmail.ch>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141025/0577f595/attachment-0001.html>

From DLRdave at aol.com  Sat Oct 25 16:49:48 2014
From: DLRdave at aol.com (David Cole)
Date: Sat, 25 Oct 2014 16:49:48 -0400
Subject: [CMake] App Crash on Any Action in Context Menu
In-Reply-To: <617e990dc447407d0bc25ce4cd14c9a0@protonmail.ch>
References: <617e990dc447407d0bc25ce4cd14c9a0@protonmail.ch>
Message-ID: <CAKME8fGjAX+N6BTx6b3+q2c6XK-E4xaXN4UhQoys8MHqHHTUbQ@mail.gmail.com>

Not sure there's a CMake question in here....... Do you have a CMake
question, or did you mean to send these emails to another mailing
list?

Confused,
David C.


On Sat, Oct 25, 2014 at 2:33 PM, Colony.Three
<Colony.Three at protonmail.ch> wrote:
> -------- Original Message --------
> Subject: App Crash on Any Action in Context Menu
> Time (GMT): Oct 25 2014 18:31:06
> From: Colony.Three at protonmail.ch
> To: cmake at cmake.org
>
> I am trying to resurrect an old app, but it has a problem and my every
> attempt to debug has failed.
>
>
> Oh, and the source is over here:
> https://quantum-equities.com/knet.bz2
>
>
> --
>
> 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

From Colony.Three at protonmail.ch  Sat Oct 25 19:38:04 2014
From: Colony.Three at protonmail.ch (Colony.Three)
Date: Sat, 25 Oct 2014 19:38:04 -0400
Subject: [CMake] App Crash on Any Action in Context Menu
Message-ID: <45a0ac89ea70bf11c5059b93c7e23c90@protonmail.ch>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141025/7970d591/attachment.html>

From steveire at gmail.com  Sun Oct 26 11:55:44 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 26 Oct 2014 16:55:44 +0100
Subject: [CMake] Is this the proper way to define a package config?
References: <CAHd499B_=dZBVhcJUsUVyQD=XEm+oePRSyTkqpyT+VhK79sg0w@mail.gmail.com>
 <1867592.YW9fbP6utO@ersa>
 <CAHd499AttEVRSmxLi02Dy5KX=YrCmRx-ViV_cd38XT=29aoLRQ@mail.gmail.com>
 <CAFzjYVpSZS+E20ozYS69+kg_u0AtwY0rpmcKrpsUksbOyUHgSg@mail.gmail.com>
 <CAHd499De91XzWEG0kfeDK6N22=59zc0pOTAfc6O6QvFKBXui0Q@mail.gmail.com>
 <m2fep8$v6h$2@ger.gmane.org>
 <CAHd499DJYQBPmnPZF0jL8oPx1wcy-KEu=d5xtDUYj0m_-TwSxw@mail.gmail.com>
Message-ID: <m2j5i0$pa$1@ger.gmane.org>

Robert Dailey wrote:

> I've skimmed over it, but I haven't seen anything useful in that
> section. Maybe you can point out what exactly I'm supposed to use from
> that?
> 
> Someone has already stated that I should use a find module and not
> define a package config since I'm not the maintainer of boost, I only
> need to use it. Are you suggesting the opposite, that I should define
> a package config as a downstream consumer?
> 

Sorry, I guess that link was not so relevant.

This has relevant information:

 http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#modules

You might be interested in picking up the effort here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10332/focus=10337

Thanks,

Steve.



From brad.king at kitware.com  Mon Oct 27 09:17:19 2014
From: brad.king at kitware.com (Brad King)
Date: Mon, 27 Oct 2014 09:17:19 -0400
Subject: [CMake] OS X Fortran flags
In-Reply-To: <544AB6AC.5020305@classdesign.com>
References: <544A70E5.3040807@classdesign.com> <544A9650.20802@kitware.com>
 <544A973B.7090708@classdesign.com> <544A9783.50308@kitware.com>
 <544AB6AC.5020305@classdesign.com>
Message-ID: <544E45DF.6030908@kitware.com>

On 10/24/2014 04:29 PM, Bill Somerville wrote:
> Sorry, I am struggling with this. I have copied the 
> Darwin-GNU-Fortran.cmake file into my project modules directory and 
> patched it as you suggested.

Sorry, I meant the Modules directory of your CMake installation.

> The good news is that it works when I patch the file in the actual CMake 
> installation

Great.  I've applied the patch here:

 OS X: Detect deployment target flags from GNU Fortran compilers
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4fc3367f

> although there is an oddity, when I configure the project I 
> see the messages from those two new function calls in the Fortran checks 
> but strangely I don't see similar messages from the C and C++ compiler 
> checks, yet they all seem to work adding the correct options.

The messages will only appear the first time CMake runs in a given
build tree.  After that the result is stored in a persistent location
to be re-used on future runs.  The C and C++ ones were probably already
cached.

-Brad


From bill at classdesign.com  Mon Oct 27 09:24:42 2014
From: bill at classdesign.com (Bill Somerville)
Date: Mon, 27 Oct 2014 13:24:42 +0000
Subject: [CMake] OS X Fortran flags
In-Reply-To: <544E45DF.6030908@kitware.com>
References: <544A70E5.3040807@classdesign.com> <544A9650.20802@kitware.com>
 <544A973B.7090708@classdesign.com> <544A9783.50308@kitware.com>
 <544AB6AC.5020305@classdesign.com> <544E45DF.6030908@kitware.com>
Message-ID: <544E479A.80503@classdesign.com>

On 27/10/2014 13:17, Brad King wrote:
Hi Brad,
> On 10/24/2014 04:29 PM, Bill Somerville wrote:
>> Sorry, I am struggling with this. I have copied the
>> Darwin-GNU-Fortran.cmake file into my project modules directory and
>> patched it as you suggested.
> Sorry, I meant the Modules directory of your CMake installation.
>
>> The good news is that it works when I patch the file in the actual CMake
>> installation
> Great.  I've applied the patch here:
>
>   OS X: Detect deployment target flags from GNU Fortran compilers
>   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4fc3367f
>
>> although there is an oddity, when I configure the project I
>> see the messages from those two new function calls in the Fortran checks
>> but strangely I don't see similar messages from the C and C++ compiler
>> checks, yet they all seem to work adding the correct options.
> The messages will only appear the first time CMake runs in a given
> build tree.  After that the result is stored in a persistent location
> to be re-used on future runs.  The C and C++ ones were probably already
> cached.
Nope, just checked again with a fresh build directory. The C & C++ 
compilers are clang so I am guessing that whatever does the compiler 
tests for them doesn't print message about version & SDK choices.

No problem, it all seems to work fine with those changes.

Thanks again for the quick response.
>
> -Brad
>
Regards
Bill.

From gerhard.olsson at volvo.com  Mon Oct 27 10:01:56 2014
From: gerhard.olsson at volvo.com (Olsson Gerhard)
Date: Mon, 27 Oct 2014 14:01:56 +0000
Subject: [CMake] CMake, armcc and Ninja workarounds and problems
Message-ID: <289541F89243ED47BC4BAE6C83560E9E471C6428@SEGOTNC5181-N1.vcn.ds.volvo.net>

A summary of limitations with (mostly) armcc and Cmake, primarly using Ninja generator.
(Note that this is referring to two emails and add a new problem.)
The workarounds where applicable are listed, as well as possible corrections/enhancements in CMake. I will probably open issues later, maybe patches too, but there may be other solutions.


Setup:
CMake 3.0.2 with Ninja 1.5.1 on Windows. Unix Makefiles was previously used in Windows and is still used in Linux (Linux is used for speedup compilation).
WindRiver Diab (DCC) and ARM DS-5 armcc (RVDS) cross compiling.



1.       No append to log file for armcc
(see original email)
Workaround is to patch generated files, replacing a token with a temp file that is later concatenated.

A proper solution could be custom variables.
For example (set in user part of configuration)
ADD_DEFINITIONS( --errors= logs/<SOURCE_FILE_NAME>.log)
<SOURCE_FILE_NAME> would be a new expand variable, i.e. "SourceFileName.c" in SOURCE path/to/SourceFileName.c
The configuratione



2.       Cannot control name of dependfile set in Ninja

Ninja generator sets the name to objectpath.d
            cmGlobalNinjaGenerator::EncodeDepfileSpace(objectFileName + ".d");

WindRiver sets the dep file name to objectDir/SourceName.d, so the ".obj" in "DEP_FILE = path/BaseName.c.obj.d" must be removed
Armcc just uses base name in the same directory as the command runs, "BaseName.d".  -depend_dir= can be used to control the directory for C but not asm.

The workaround is to patch the generated build.ninja

A proper solution is using new variables similar to above. (Just examples, not figured out <ARCH> etc)

WindRiver (not added to CMake):
SET (CMAKE_<LANG>_<COMPILER_ID>_DEPFILE_PATTERN <OBJECT_DIR>/<SOURCE_FILE_NAME>.d )

Armcc (RVDS patch exists for CMake):
SET (CMAKE_DEPFILE_FLAGS_C -depend_dir=<OBJECT_FULL_DIR> --depend_format=unix)
SET (CMAKE_C_ARMCC_DEPFILE_PATTERN <OBJECT_FULL_DIR>/<SOURCE_BASE_NAME>.d )
SET (CMAKE_DEPFILE_FLAGS_ASM --depend_format=unix)
SET (CMAKE_ASM_ARMCC_DEPFILE_PATTERN <SOURCE_BASE_NAME>.d )

Note: <OBJECT> is replaced in CMAKE_C_ARMCC_DEPFILE_PATTERN (but adding a semicolon), but not <OBJECT_DIR> (as that is evaluated after FLAGS/DEFINES) so it is a little more than just add new variables.
The workaround for armcc could therefore not use CMAKE_DEPFILE_FLAGS_C, the -depend_dir flag was added to normal FLAGS



3.       CMake adds CMD /C  for both LINKER and prelink/postbuild
PRE_LINK and POST_BUILD is executed as part of linking, so extra CMD is an error (at least the quotes)
CMake adds CMD /C for linker, but also for  PRE_LINK and POST_BUILD.CMD /C is added twice.

rule C_EXECUTABLE_LINKER_RSP_FILE
  command = cmd.exe /C "$PRE_LINK && C:\PROGRA~1\DS-5\bin\armcc.exe  $FLAGS  $LINK_FLAGS --via=$RSP_FILE  -o $out  && $POST_BUILD"

The first workaround was to patch build.ninja. Not really needed after the second workaround that removed the need for PRE_LINK/POST_BUILD, stll included in the patches below.
Setup separate targets for a few ASM files (not compiling in PRE_LINK), move out POST_BUILD to separate targets included in ALL.
This works fine here (better if full armcc/WindRiver support was added of course)

I believe the solution is to remove CMD /C for PRE_LINK/POSTBUILD. There are command length complications though.



4.       Commands can be longer than 8000 bytes in Windows

a.       The Ninja generator may need to use RSP_FILE also when compiling.

b.      PRE_LINK/POSTBUILD can give long lines

The workaround for a. is to decrease the include paths, for b. to not use PRE_LINK.

The solution for a. is to evaluate using  RSP_FILE if needed in Ninja. I believe the Unix Makefiles generator handles this better.
For b. I have no good proposal.


/Gerhard

--

Rough workaround
Build is invoked from make (CMAKE_MAKEFILE is set to path to build.ninja):

${CMAKE_MAKEFILE}: ${CMAKELISTS} ${CMAKE_TOOLCHAIN} | ${CMAKE_BUILD_DIR}
                             @${ECHO}
                             $(CMD_V)cd ${CMAKE_BUILD_DIR} && ${CMAKE_MPC5516E} $(CMAKE_FLAGS_MPC5516E) ${CMAKELISTS_OSDIR}

ifeq ($(CMAKE_GENERATOR),${CMAKE_NINJA})
                             @#CMake Ninja uses cmd, quotes incorrectly
                             @perl -pi -e 's%^(\s*(POST_BUILD|PRE_LINK)\s*=\s*)cmd.exe\s(/C)?\s*"(.*)"%$$1$$4%i; ' $@
ifneq ($(COMPILE_DEPEND_DIR),)
                             @#no path for armcc, use --depend_dir=depend to avoid have all in root (asm go there)
                             @perl -pi -e 'BEGIN{$$c="$(COMPILE_DEPEND_DIR)";} s%^(\s*DEP_FILE\s*=\s*).*/(.*).c\.obj\.d\s*$$%$$1$$c/$$2.d\n%;' $@
                             @$(MKDIR) -p $(dir ${CMAKE_MAKEFILE})depend
else
                             @#unexpected suffix (probably other ways to do this)
                             @perl -pi -e 's%^(\s*DEP_FILE\s*=\s*.*)\.obj\.d\s*$$%$$1.d\n%;' $@
endif
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             @perl -pi -e 'BEGIN{$$c="$(COMPILE_LOG_NO_APPEND)"; $$n="unknown"; $$i=1;}if(m%^build .*?([\w\.]+):%){$$n=$$1;} if (s%(--errors)=$$c%$$1=logs/$$n.$$i%){$$i++; $$n="unknown";}' $@
                             @$(MKDIR) -p $(dir ${CMAKE_MAKEFILE})logs
endif

compile_target: ${CMAKE_MAKEFILE} | $(INFO_BUILD_DIR) ${BUILD_RESULT_DIR}
                             @${ECHO}
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             @$(ECHO) " Note: If compile fails: \"make copy_log\""
endif
                             $(CMAKE_MAKE) install
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             @$(MAKE) copy_logs
endif

copy_logs:
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             $(CMD_V)$(CAT) $(CMAKE_BUILD_DIR)/logs/* > ${INFO_BUILD_DIR}/error.txt
                             $(CMD_V)$(RM) $(CMAKE_BUILD_DIR)/logs/*
endif

From: Olsson Gerhard
Sent: den 8 september 2014 7:46
To: 'cmake at cmake.org'
Subject: Compilation logs: Workaround for no appendfile

ARM DS-5 compiler (armcc compiler 5.04)
Platform: Windows and Linux

Armcc (as well as arasm, armlink etc) has option '-errors=file 'to log compilation messages (warnings and errors) to a logfile instead of stdout.
There is no possibility from what I have found out to append to a log file, all output overwrites the log.

Background:
We cannot change some 3rd party code and cannot suppress all compilation warnings. The workaround is to parse the logs.
If printed to the console, the messages are mixed up with progress and license messages.
Other compilers has the possibility to append to logs, but not armcc what I can find.

A workaround would be to CMake to save stdout to a logfile. May be possible, but I am not sure that is a good solution.
Another is to log to unique logname, include the compiled file in the logname. I am not sure how that can be done in CMake.

Any hints how to do this?

/Gerhard



From: Olsson Gerhard
Sent: den 1 oktober 2014 7:46
To: 'cmake at cmake.org'
Subject: Ninja: CMD /C, quoting added for PRE_LINK/POST_BUILD

The commands for PRE_LINK/POST_BUILD is not correctly quoted for Ninja in Windows. 'CMD /C "<command>"' is added to the command, just as Ninja itself does.
(this was maybe different in earlier Ninja versions, but has been around for a couple of years)
(The quoting in the working command is strange, but works.)

A workaround that is not so bad, is to patch build.ninja
Is there a better way?

Note: The lines  LINK_FLAGS ,POST_BUILD ,  PRE_LINK , TARGET_PDB are duplicated in build.ninja. Does not make a difference.

ARM DS-5 compiler (armcc compiler 5.04)
Platform: Windows (Linux used too, but with Unix Makefiles)
CMake 3.0.2
Ninja 1.5.1

/Gerhard


CmakeLists.txt excerpt:

ADD_CUSTOM_COMMAND(
    TARGET ECU
    PRE_LINK
    COMMAND "C:/Program Files/DS-5/bin/armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o ${CMAKE_CURRENT_BINARY_DIR}/osekasm.o c:/Os/osekasm.s VERBATIM
  )

  #Generate hex, copy to view
  add_custom_command(TARGET ECU POST_BUILD
    COMMAND "C:/Program Files/DS-5/bin/fromelf.exe" --m32combined --output=${CMAKE_CURRENT_BINARY_DIR}/ECU.hex ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf VERBATIM
    COMMAND "C:/cygwin/bin/objcopy" -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf ${CMAKE_CURRENT_BINARY_DIR}/parameter_section.hex VERBATIM
  )


Generated in build.ninja:

  LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o
  POST_BUILD = cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex"
  PRE_LINK = cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build"
  TARGET_PDB = ECU.elf.dbg


Console output:

[106/107] Linking C executable ECU.elf
FAILED: cmd.exe /C "cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build" && C:\PROGRA~1\DS-5\bin\armcc.exe    --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o --via=CMakeFiles/ECU.rsp  -o ECU.elf  && cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex""
'cmd.exe' is not recognized as an internal or external command,
operable program or batch file.
ninja: build stopped: subcommand failed.


Patched (in Makefile):

${CMAKE_MAKEFILE}: ${CMAKELISTS} ${CMAKE_TOOLCHAIN} | ${CMAKE_BUILD_DIR}
                             @#CMake Ninja uses cmd incorrectly
                             @perl -pi -e 's%^(\s*(POST_BUILD|PRE_LINK)\s*=\s*)cmd.exe\s(/C)?\s*"(.*)"%$$1$$4%i; ' $@



Rules patched OK:

  LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o
  POST_BUILD = cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex
  PRE_LINK = cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build
  TARGET_PDB = ECU.elf.dbg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/dd16c3a9/attachment-0001.html>

From scott.bloom at onshorecs.com  Mon Oct 27 13:38:51 2014
From: scott.bloom at onshorecs.com (Scott Aron Bloom)
Date: Mon, 27 Oct 2014 17:38:51 +0000
Subject: [CMake] CMP0020 warning
Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E3E7E8F@WIN-R92V03RFJ85.onshorecs.local>

The warning message for CMP0020 seems to be completely random as to where you actually have to set the policy.

Im not getting the warning on my main executables, but cant seem to get rid of it on any of my Qt based unittests (using gmock/gtest )

I have the following line, in various places in the system,
        cmake_policy(SET CMP0020 NEW)

but is there any documentation on where it MUST be set???

Scott



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/46149c88/attachment.html>

From pgquiles at elpauer.org  Mon Oct 27 15:54:53 2014
From: pgquiles at elpauer.org (Pau Garcia i Quiles)
Date: Mon, 27 Oct 2014 20:54:53 +0100
Subject: [CMake] FOSDEM 2015 Desktops DevRoom Call for Talks
Message-ID: <CAKcBoktc7wtGRsAkOZ51boO_HsZW6hrp+gMnJLcpXzYK_fpojw@mail.gmail.com>

 Hello,

--8<---

FOSDEM <http://www.fosdem.org> is one of the largest gatherings of Free
Software contributors in the world and happens each February in Brussels
(Belgium). 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: Enlightenment, Gnome, KDE,
Unity, XFCE, LXQt, Windows, Mac OS X, software development for the desktop,
general desktop matters, applications that enhance desktops and web (when
related to desktop).

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 2014 schedule
<https://archive.fosdem.org/2014/schedule/track/desktops/> might give you
some inspiration.

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 250 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.

The deadline for submissions is December 7th 2014. FOSDEM will be held on
the weekend of January 31st-February 1st 2015 and the Desktops DevRoom will
take place on Sunday, February 1st 2015. Please use the following website
to submit your proposals: https://penta.fosdem.org/submission/FOSDEM15 (you
do not need to create a new Pentabarf account if you already have one from
past years).

You can also join the devroom?s mailing list, which is the official
communication channel for the DevRoom: desktops-devroom at lists.fosdem.org
<https://lists.fosdem.org/private/desktops-devroom/> (subscription page
<https://lists.fosdem.org/listinfo/desktops-devroom> for the mailing list)

? The Desktops DevRoom 2015 Organization Team
--8<---

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/c3586d40/attachment.html>

From rcdailey.lists at gmail.com  Mon Oct 27 20:10:39 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 27 Oct 2014 19:10:39 -0500
Subject: [CMake] Refer to all debug or release targets with generator
	expressions
Message-ID: <CAHd499DX4rSQ=-+Kuquex6D0T=wuGa62m-SAP3Cp+QBgLsDGqg@mail.gmail.com>

I know that when defining link libraries, I can do this:

$<$<CONFIG:Debug>:${my_debug_libs}>

The debug libraries will be the same for all debug targets. Likewise
with Release targets. Is there a way to refer to *all* release targets
using generator expressions? There are 3 release configurations that
ship with CMake by default for IDEs like Visual Studio. It would be
redundant for me to specify a generator expression for each and every
configuration. It'd be simpler to somehow map my release libs to all
release configurations somehow since they do not differ.

Any ideas on how to do this?

From rcdailey.lists at gmail.com  Mon Oct 27 20:12:10 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 27 Oct 2014 19:12:10 -0500
Subject: [CMake] Refer to all debug or release targets with generator
	expressions
In-Reply-To: <CAHd499DX4rSQ=-+Kuquex6D0T=wuGa62m-SAP3Cp+QBgLsDGqg@mail.gmail.com>
References: <CAHd499DX4rSQ=-+Kuquex6D0T=wuGa62m-SAP3Cp+QBgLsDGqg@mail.gmail.com>
Message-ID: <CAHd499D+DifS=hLTosHSuNUwVWxm_qfYM2UBi=WDMt3HX0mu=w@mail.gmail.com>

I forgot to give a more concrete example. Consider this:

    add_library( Foo INTERFACE )
    target_link_libraries( Foo INTERFACE
        $<$<CONFIG:Debug>:${lib_debug}>
        $<$<CONFIG:Release>:${lib_release}>
        $<$<CONFIG:RelWithDebInfo>:${lib_release}>
        $<$<CONFIG:MinSizeRel>:${lib_release}>
    )

Must I do it like this for each and every configuration?

On Mon, Oct 27, 2014 at 7:10 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> I know that when defining link libraries, I can do this:
>
> $<$<CONFIG:Debug>:${my_debug_libs}>
>
> The debug libraries will be the same for all debug targets. Likewise
> with Release targets. Is there a way to refer to *all* release targets
> using generator expressions? There are 3 release configurations that
> ship with CMake by default for IDEs like Visual Studio. It would be
> redundant for me to specify a generator expression for each and every
> configuration. It'd be simpler to somehow map my release libs to all
> release configurations somehow since they do not differ.
>
> Any ideas on how to do this?

From dschepler at scalable-networks.com  Mon Oct 27 20:14:24 2014
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Tue, 28 Oct 2014 00:14:24 +0000
Subject: [CMake] Refer to all debug or release targets with
	generator	expressions
In-Reply-To: <CAHd499D+DifS=hLTosHSuNUwVWxm_qfYM2UBi=WDMt3HX0mu=w@mail.gmail.com>
References: <CAHd499DX4rSQ=-+Kuquex6D0T=wuGa62m-SAP3Cp+QBgLsDGqg@mail.gmail.com>
 <CAHd499D+DifS=hLTosHSuNUwVWxm_qfYM2UBi=WDMt3HX0mu=w@mail.gmail.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D1A4E@SNTMAIL01.snt.loc>

I think this should work:

$<$<NOT:$<CONFIG:Debug>>:${my_release_libs}>
-- 
Daniel

-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey
Sent: Monday, October 27, 2014 5:12 PM
To: CMake
Subject: Re: [CMake] Refer to all debug or release targets with generator expressions

I forgot to give a more concrete example. Consider this:

    add_library( Foo INTERFACE )
    target_link_libraries( Foo INTERFACE
        $<$<CONFIG:Debug>:${lib_debug}>
        $<$<CONFIG:Release>:${lib_release}>
        $<$<CONFIG:RelWithDebInfo>:${lib_release}>
        $<$<CONFIG:MinSizeRel>:${lib_release}>
    )

Must I do it like this for each and every configuration?

On Mon, Oct 27, 2014 at 7:10 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> I know that when defining link libraries, I can do this:
>
> $<$<CONFIG:Debug>:${my_debug_libs}>
>
> The debug libraries will be the same for all debug targets. Likewise 
> with Release targets. Is there a way to refer to *all* release targets 
> using generator expressions? There are 3 release configurations that 
> ship with CMake by default for IDEs like Visual Studio. It would be 
> redundant for me to specify a generator expression for each and every 
> configuration. It'd be simpler to somehow map my release libs to all 
> release configurations somehow since they do not differ.
>
> Any ideas on how to do this?
-- 

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


From fungos at gmail.com  Mon Oct 27 21:36:13 2014
From: fungos at gmail.com (fungos)
Date: Mon, 27 Oct 2014 21:36:13 -0400
Subject: [CMake] Adding a new language for a multiple language project -
	CMAKE_AR problem(?)
Message-ID: <CAJ7Kbx=b49qZHY-j1-4qpGQyLJh301h2RX1WJF7_=fDfH3EQMg@mail.gmail.com>

Hello,

I'm trying to create a simple exercise, a definition for a virtual language
"X" that will be used side-by-side with C and C++.
There are some restrictions on the level of compatibility with C/C++. For
instance, the objects of this language aren't directly compatible with C
and C++ but then there is a virtual application "X linker/librarian" that
is capable of converting X objects into C objects generating a standard C
lib (note the absence of a temporary objects in the C format, this is
important).

Now, the project is composed of a subproject of type language X, that
generate a lib, another subproject that generate another lib (a C one) and
then the base project that should link libc with libx to create an
executable.

proj/libx/CMakeLists.txt -> define: project(libx X) -> generate prefixlibx.a
proj/libc/CMakeLists.txt -> define: project(libc C) -> generate libc.a
proj/app/CMakeLists.txt -> define: project(app C) -> generate exec.elf that
links libc.a and prefixlibx.a

Everything _almost_ work the way I want, with exception of the
librarian/linker.
If I force in CMakeDetermineXCompiler.cmake the CMAKE_AR to "xar" and
"xranlib", it will use then to do the libx AND libc.
If I do not force CMAKE_AR and let find_program determine, it will use "ar"
for both libc AND libx.

Why can't I use CMAKE_AR as "xar" inside a X project that is inside a C
project?

I think that if something like CMAKE_<LANG>_AR and others existed, we would
be able to do more complex things for example (enabling the use of < >
variables).

All this is only hypothetical and I'm using this to understand better CMake
and try to map how I can _implement_ _new_ languages and toolsets to use
with our custom tools.

Here is a link to my repository where I added this cmake test:
https://github.com/fungos/cmake_langx

Thank you
Danny Grein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/56a3e926/attachment.html>

From rcdailey.lists at gmail.com  Mon Oct 27 21:55:08 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 27 Oct 2014 20:55:08 -0500
Subject: [CMake] Copying DLLs to output directory
Message-ID: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>

This actually used to be a very difficult problem to solve. However,
to debug in visual studio it's essential.

If I have DLLs located in third party directories OR from targets that
I depend on, those must all be copied to the directory of the
executable I'm debugging in order for those DLLs to be found and
loaded.

Using CMake 3.0.2, I hope this task is simpler, especially with the
introduction of a nice suite of generator expressions. Can anyone
recommend a good way to do this?

From rcdailey.lists at gmail.com  Mon Oct 27 22:01:12 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 27 Oct 2014 21:01:12 -0500
Subject: [CMake] Refer to all debug or release targets with generator
	expressions
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D1A4E@SNTMAIL01.snt.loc>
References: <CAHd499DX4rSQ=-+Kuquex6D0T=wuGa62m-SAP3Cp+QBgLsDGqg@mail.gmail.com>
 <CAHd499D+DifS=hLTosHSuNUwVWxm_qfYM2UBi=WDMt3HX0mu=w@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D1A4E@SNTMAIL01.snt.loc>
Message-ID: <CAHd499ACw=fXyA+rN++8J92+xo3Pb+ULmVvwNpPVnaqDpVEtrw@mail.gmail.com>

That's a cute solution. Never thought of it. Generator expressions are
really advanced & handy now. I like it.

On Mon, Oct 27, 2014 at 7:14 PM, Daniel Schepler
<dschepler at scalable-networks.com> wrote:
> I think this should work:
>
> $<$<NOT:$<CONFIG:Debug>>:${my_release_libs}>
> --
> Daniel
>
> -----Original Message-----
> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey
> Sent: Monday, October 27, 2014 5:12 PM
> To: CMake
> Subject: Re: [CMake] Refer to all debug or release targets with generator expressions
>
> I forgot to give a more concrete example. Consider this:
>
>     add_library( Foo INTERFACE )
>     target_link_libraries( Foo INTERFACE
>         $<$<CONFIG:Debug>:${lib_debug}>
>         $<$<CONFIG:Release>:${lib_release}>
>         $<$<CONFIG:RelWithDebInfo>:${lib_release}>
>         $<$<CONFIG:MinSizeRel>:${lib_release}>
>     )
>
> Must I do it like this for each and every configuration?
>
> On Mon, Oct 27, 2014 at 7:10 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>> I know that when defining link libraries, I can do this:
>>
>> $<$<CONFIG:Debug>:${my_debug_libs}>
>>
>> The debug libraries will be the same for all debug targets. Likewise
>> with Release targets. Is there a way to refer to *all* release targets
>> using generator expressions? There are 3 release configurations that
>> ship with CMake by default for IDEs like Visual Studio. It would be
>> redundant for me to specify a generator expression for each and every
>> configuration. It'd be simpler to somehow map my release libs to all
>> release configurations somehow since they do not differ.
>>
>> Any ideas on how to do this?
> --
>
> 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
>

From d3ck0r at gmail.com  Mon Oct 27 22:12:41 2014
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 27 Oct 2014 19:12:41 -0700
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
Message-ID: <CAA2GJqVF0Q=tt6ySaVyFOW=fEBj+QrzcE0MG_Lpdn5g=pGXNcQ@mail.gmail.com>

If you add install rules, you can get a runnable package... and kill having
to configure things to package in one step.
Install can just target 'output' or some relative directory to the build
directory, it doesn't have to be the final install target.


On Mon, Oct 27, 2014 at 6:55 PM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> This actually used to be a very difficult problem to solve. However,
> to debug in visual studio it's essential.
>
> If I have DLLs located in third party directories OR from targets that
> I depend on, those must all be copied to the directory of the
> executable I'm debugging in order for those DLLs to be found and
> loaded.
>
> Using CMake 3.0.2, I hope this task is simpler, especially with the
> introduction of a nice suite of generator expressions. Can anyone
> recommend a good way to do this?
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/bf5b4b91/attachment.html>

From mike.jackson at bluequartz.net  Mon Oct 27 22:51:12 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Mon, 27 Oct 2014 22:51:12 -0400
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
Message-ID: <F7C8FD34-CB11-4FF0-8AF9-88EA780BE7DA@bluequartz.net>

I use a copy rule for the DLLs during the build which finds the DLL and then copies it to the Debug or Release directory. You are welcome to the macro that we use for our project. If there is an easier way with Cmake 3.0.x I would love to hear about it.

Thanks
Mike Jackson


On Oct 27, 2014, at 9:55 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:

> This actually used to be a very difficult problem to solve. However,
> to debug in visual studio it's essential.
> 
> If I have DLLs located in third party directories OR from targets that
> I depend on, those must all be copied to the directory of the
> executable I'm debugging in order for those DLLs to be found and
> loaded.
> 
> Using CMake 3.0.2, I hope this task is simpler, especially with the
> introduction of a nice suite of generator expressions. Can anyone
> recommend a good way to do this?
> -- 
> 
> 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


From d3ck0r at gmail.com  Mon Oct 27 23:17:57 2014
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 27 Oct 2014 20:17:57 -0700
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <F7C8FD34-CB11-4FF0-8AF9-88EA780BE7DA@bluequartz.net>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <F7C8FD34-CB11-4FF0-8AF9-88EA780BE7DA@bluequartz.net>
Message-ID: <CAA2GJqV_21FTopmRw1oDR+E1r6V4tVSELvM-UZwjc++6z=T1AA@mail.gmail.com>

how does that work with say openwatcom?

On Mon, Oct 27, 2014 at 7:51 PM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> I use a copy rule for the DLLs during the build which finds the DLL and
> then copies it to the Debug or Release directory. You are welcome to the
> macro that we use for our project. If there is an easier way with Cmake
> 3.0.x I would love to hear about it.
>
> Thanks
> Mike Jackson
>
>
> On Oct 27, 2014, at 9:55 PM, Robert Dailey <rcdailey.lists at gmail.com>
> wrote:
>
> > This actually used to be a very difficult problem to solve. However,
> > to debug in visual studio it's essential.
> >
> > If I have DLLs located in third party directories OR from targets that
> > I depend on, those must all be copied to the directory of the
> > executable I'm debugging in order for those DLLs to be found and
> > loaded.
> >
> > Using CMake 3.0.2, I hope this task is simpler, especially with the
> > introduction of a nice suite of generator expressions. Can anyone
> > recommend a good way to do this?
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/236024f9/attachment.html>

From mike.jackson at bluequartz.net  Mon Oct 27 23:27:51 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Mon, 27 Oct 2014 23:27:51 -0400
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAA2GJqV_21FTopmRw1oDR+E1r6V4tVSELvM-UZwjc++6z=T1AA@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <F7C8FD34-CB11-4FF0-8AF9-88EA780BE7DA@bluequartz.net>
 <CAA2GJqV_21FTopmRw1oDR+E1r6V4tVSELvM-UZwjc++6z=T1AA@mail.gmail.com>
Message-ID: <0156A673-55C2-4AFF-BE0D-264405A860D9@bluequartz.net>

Well basically, if you are on windows cmake can find the .lib file but then I wrote some code for each 3rd party library that attempts to find the .dll files. Once those files are found I create the copy files targets for each DLL.

Mike Jackson

On Oct 27, 2014, at 11:17 PM, J Decker <d3ck0r at gmail.com> wrote:

> how does that work with say openwatcom?
> 
> On Mon, Oct 27, 2014 at 7:51 PM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
> I use a copy rule for the DLLs during the build which finds the DLL and then copies it to the Debug or Release directory. You are welcome to the macro that we use for our project. If there is an easier way with Cmake 3.0.x I would love to hear about it.
> 
> Thanks
> Mike Jackson
> 
> 
> On Oct 27, 2014, at 9:55 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> 
> > This actually used to be a very difficult problem to solve. However,
> > to debug in visual studio it's essential.
> >
> > If I have DLLs located in third party directories OR from targets that
> > I depend on, those must all be copied to the directory of the
> > executable I'm debugging in order for those DLLs to be found and
> > loaded.
> >
> > Using CMake 3.0.2, I hope this task is simpler, especially with the
> > introduction of a nice suite of generator expressions. Can anyone
> > recommend a good way to do this?
> > --
> >
> > 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/5f719694/attachment-0001.html>

From j.fisher at digipen.edu  Tue Oct 28 00:13:06 2014
From: j.fisher at digipen.edu (Joshua T. Fisher)
Date: Mon, 27 Oct 2014 21:13:06 -0700
Subject: [CMake] Is anyone working on a FASTBuild Generator?
Message-ID: <CAHC2tLq2uc7y38ySX3xkEX9e5MbaHwefAZ51V0Z=za-c7LH1UA@mail.gmail.com>

And if not, is there any information on how an outside developer might
begin work on a custom generator? I'm just a student, so I'm not sure how
much time I have to dedicate to something like this, but I am interested in
seeing what's involved.

Link to FASTBuild:
http://www.fastbuild.org/docs/home.html

Link to Nicolas Fleury's talk where he talks about FASTBuild:
https://www.youtube.com/watch?v=qYN6eduU06s#t=436
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141027/e4bdae40/attachment.html>

From post at hendrik-sattler.de  Tue Oct 28 01:21:49 2014
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Tue, 28 Oct 2014 06:21:49 +0100
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
Message-ID: <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>

Hi,

you can use generator expression in a post build rule to copy the dll file to the same target dir as the target you link it with. The easiest way to do this is to properly define all 3rd party libraries as imported targets that contains both, the lib and the dll file.
Sadly, the FindQt4 on Windows doesn't do this and thus make life harder than needed. CMake configuration files should always do this right.

OTOH, you could also write a wrapper batch file or change VS properties to modify PATH to include all libraries before the regular path.

HS


Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey <rcdailey.lists at gmail.com>:
>This actually used to be a very difficult problem to solve. However,
>to debug in visual studio it's essential.
>
>If I have DLLs located in third party directories OR from targets that
>I depend on, those must all be copied to the directory of the
>executable I'm debugging in order for those DLLs to be found and
>loaded.
>
>Using CMake 3.0.2, I hope this task is simpler, especially with the
>introduction of a nice suite of generator expressions. Can anyone
>recommend a good way to do this?


From george.ryan at gmail.com  Tue Oct 28 06:23:48 2014
From: george.ryan at gmail.com (George)
Date: Tue, 28 Oct 2014 07:23:48 -0300
Subject: [CMake] FIND_PATH() search custom path first
Message-ID: <CAM+az=+XO4mW39mdNw3YXcniVqQaUjoc3gzxqJ+PxR_u1NdxKQ@mail.gmail.com>

Hi,

I have a situation where I need to prefer a custom-build of a library over
any system-installed versions. I understand that the paths in the HINTS
variable will be searched before the system ones, but the documentation
discourages its use with hard-coded paths.

If I do hard-code a HINTed path, what problems would that cause?

Thank you,
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/d804e298/attachment.html>

From eblot.ml at gmail.com  Tue Oct 28 06:59:55 2014
From: eblot.ml at gmail.com (Emmanuel Blot)
Date: Tue, 28 Oct 2014 11:59:55 +0100
Subject: [CMake] Is there really no way in CMake to retrieve the objects
	file for a target?
Message-ID: <CAKJJEPz9a7-wDkKt0TLth0DWJrkykuCcLrGktcb-hmmF2_tLuQ@mail.gmail.com>

Hi,

I need to tweak object files for a target before linking them to the
final executable.

I'm striving for retrieving the file object paths for a target:

ADD_LIBRARY(tgt OBJECT file1.c file2.S)

1. $<TARGET_OBJECTS:tgt> is not available from
ADD_CUSTOM_COMMAND/ADD_CUSTOM_TARGET

2. Actual object paths could be deduced from the source file name, but
it seems difficult to predict the actual path when source files are
relative to the current directory: ".." is replaced with "__" for
example.

3. GET_TARGET_PROPERTY(var tgt SOURCES) provides absolute source
paths, which makes source to object file path computation impossible,
because of the ".." to "__" automatic replacement

This seems so convoluted that I guess I'm missing the proper way to
properly add an intermediate step between the compilation and link
stages, but I keep failing to find any useful advice from Google and
the mailing list.

Thanks,
Manu.

From george.ryan at gmail.com  Tue Oct 28 08:42:23 2014
From: george.ryan at gmail.com (George)
Date: Tue, 28 Oct 2014 09:42:23 -0300
Subject: [CMake] FIND_PATH() search custom path first
In-Reply-To: <8420daa09a3747bfb0cd37a3023f401d@DBXPR03MB478.eurprd03.prod.outlook.com>
References: <CAM+az=+XO4mW39mdNw3YXcniVqQaUjoc3gzxqJ+PxR_u1NdxKQ@mail.gmail.com>
 <8420daa09a3747bfb0cd37a3023f401d@DBXPR03MB478.eurprd03.prod.outlook.com>
Message-ID: <CAM+az=Lq1a6ciGaPwh3FuTwvNMvW9n3Mfe_7coNq9GrXUometw@mail.gmail.com>

On 28 October 2014 09:34, Jakub Zakrzewski <jzakrzewski at e2e.ch> wrote:

>   > I have a situation where I need to prefer a custom-build of a library
> over any system-installed versions. I understand that the paths in the
> HINTS variable will be searched before the > system ones, but the
> documentation discourages its use with hard-coded paths.
>
> > If I do hard-code a HINTed path, what problems would that cause?
>
>  It's "just" a best practise. Someone smarter has come up with the right
> order and it looks sensible to me. I'd suggest, that you do your search in
> two steps:
>
>
>
> find_path( MY_FILE
>
>   NAMES "my_file.txt"
>
>   PATHS
>
>   "/the/file/is/here"
>
> "/or/maybe/here"
>
>   NO_DEFAULT_PATH
>
>   NO_CMAKE_ENVIRONMENT_PATH
>
>   NO_CMAKE_PATH
>
>   NO_SYSTEM_ENVIRONMENT_PATH
>
>   NO_CMAKE_SYSTEM_PATH
>
>   NO_CMAKE_FIND_ROOT_PATH
>
> )
>
>
>
> find_path( MY_FILE
>
>   NAMES "my_file.txt"
>
> )
>
>
>
> If the file is found wit the first call, then CMake won't try to find it
> again. Otherwise it'll proceed with standard search (second call).
>
>
>
> --
>
> Gruesse,
>
> Jakub
>
>
>
>
>
I would very much like to know the actual technical reason behind the
practice. On the surface, it appears there is no reason for having two
searches if HINTS works in the way that it says.  This posting

http://mail.kde.org/pipermail/kde-buildsystem/2008-June/004762.html

appears to indicate that HINTS was created for exactly the purpose I need:

HINTS ${SOMEPLACE_I_WANT_TO_LOOK_FIRST}

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/a27930b4/attachment.html>

From jzakrzewski at e2e.ch  Tue Oct 28 08:34:40 2014
From: jzakrzewski at e2e.ch (Jakub Zakrzewski)
Date: Tue, 28 Oct 2014 12:34:40 +0000
Subject: [CMake] FIND_PATH() search custom path first
In-Reply-To: <CAM+az=+XO4mW39mdNw3YXcniVqQaUjoc3gzxqJ+PxR_u1NdxKQ@mail.gmail.com>
References: <CAM+az=+XO4mW39mdNw3YXcniVqQaUjoc3gzxqJ+PxR_u1NdxKQ@mail.gmail.com>
Message-ID: <8420daa09a3747bfb0cd37a3023f401d@DBXPR03MB478.eurprd03.prod.outlook.com>

> I have a situation where I need to prefer a custom-build of a library over any system-installed versions. I understand that the paths in the HINTS variable will be searched before the > system ones, but the documentation discourages its use with hard-coded paths.
> If I do hard-code a HINTed path, what problems would that cause?

It's "just" a best practise. Someone smarter has come up with the right order and it looks sensible to me. I'd suggest, that you do your search in two steps:

find_path( MY_FILE
  NAMES "my_file.txt"
  PATHS
  "/the/file/is/here"
"/or/maybe/here"
  NO_DEFAULT_PATH
  NO_CMAKE_ENVIRONMENT_PATH
  NO_CMAKE_PATH
  NO_SYSTEM_ENVIRONMENT_PATH
  NO_CMAKE_SYSTEM_PATH
  NO_CMAKE_FIND_ROOT_PATH
)

find_path( MY_FILE
  NAMES "my_file.txt"
)

If the file is found wit the first call, then CMake won't try to find it again. Otherwise it'll proceed with standard search (second call).

--
Gruesse,
Jakub


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/545d9030/attachment-0001.html>

From jzakrzewski at e2e.ch  Tue Oct 28 08:57:54 2014
From: jzakrzewski at e2e.ch (Jakub Zakrzewski)
Date: Tue, 28 Oct 2014 12:57:54 +0000
Subject: [CMake] FIND_PATH() search custom path first
In-Reply-To: <CAM+az=Lq1a6ciGaPwh3FuTwvNMvW9n3Mfe_7coNq9GrXUometw@mail.gmail.com>
References: <CAM+az=+XO4mW39mdNw3YXcniVqQaUjoc3gzxqJ+PxR_u1NdxKQ@mail.gmail.com>
 <8420daa09a3747bfb0cd37a3023f401d@DBXPR03MB478.eurprd03.prod.outlook.com>
 <CAM+az=Lq1a6ciGaPwh3FuTwvNMvW9n3Mfe_7coNq9GrXUometw@mail.gmail.com>
Message-ID: <132edb0d4e0e499798c1b13b7701d8f0@DBXPR03MB478.eurprd03.prod.outlook.com>



From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of George
Sent: Dienstag, 28. Oktober 2014 13:42
To: cmake at cmake.org
Subject: Re: [CMake] FIND_PATH() search custom path first



On 28 October 2014 09:34, Jakub Zakrzewski <jzakrzewski at e2e.ch<mailto:jzakrzewski at e2e.ch>> wrote:
> I have a situation where I need to prefer a custom-build of a library over any system-installed versions. I understand that the paths in the HINTS variable will be searched before the > system ones, but the documentation discourages its use with hard-coded paths.
> If I do hard-code a HINTed path, what problems would that cause?
It's "just" a best practise. Someone smarter has come up with the right order and it looks sensible to me. I'd suggest, that you do your search in two steps:

find_path( MY_FILE
  NAMES "my_file.txt"
  PATHS
  "/the/file/is/here"
"/or/maybe/here"
  NO_DEFAULT_PATH
  NO_CMAKE_ENVIRONMENT_PATH
  NO_CMAKE_PATH
  NO_SYSTEM_ENVIRONMENT_PATH
  NO_CMAKE_SYSTEM_PATH
  NO_CMAKE_FIND_ROOT_PATH
)

find_path( MY_FILE
  NAMES "my_file.txt"
)

If the file is found wit the first call, then CMake won't try to find it again. Otherwise it'll proceed with standard search (second call).

--
Gruesse,
Jakub


I would very much like to know the actual technical reason behind the practice. On the surface, it appears there is no reason for having two searches if HINTS works in the way that it says.  This posting

http://mail.kde.org/pipermail/kde-buildsystem/2008-June/004762.html
appears to indicate that HINTS was created for exactly the purpose I need:
HINTS ${SOMEPLACE_I_WANT_TO_LOOK_FIRST}
George


As I said - it's best practise. HINTS *should* be computed by system introspection and are prefferred over system paths (but not CMake paths). If you know in advance, where your files are, you should probably use one of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_FRAMEWORK_PATH and let CMake find your files by itself.

--
Gruesse,
Jakub


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/0606f436/attachment.html>

From gerhard.olsson at volvo.com  Tue Oct 28 10:55:49 2014
From: gerhard.olsson at volvo.com (Olsson Gerhard)
Date: Tue, 28 Oct 2014 14:55:49 +0000
Subject: [CMake] CMake, armcc and Ninja workarounds and problems
Message-ID: <289541F89243ED47BC4BAE6C83560E9E471CA81F@SEGOTNC5181-N1.vcn.ds.volvo.net>

Update:


1.       Append to logfile
Just resolving <OBJECT> would be an improvement, but that may require changes to all generators, no global resolution what I see.
Should be changed in armcc, dropping for CMake.


2.       Dependfile
This can be done in armcc:
    SET( CMAKE_DEPFILE_FLAGS_C "--depend=<OBJECT>.d --depend_format=unix" )
Similar for ARM, but untested.

WindRiver:
    SET( CMAKE_DEPFILE_FLAGS_C "-Xmake-dependency=6 -Xmake-dependency-savefile=<OBJECT>.d" )
(not possible for asm)

So this should be working as intended



3.       Ninja PRE_LINK/POST_BUILD adds cmd.exe
Need to be changed in cmNormalNinjaTargetGenerator.cxx to not add twice.

vars["PRE_LINK"] =
    this->GetLocalGenerator()->BuildCommandLine(preLinkCmdLines);
(cmLocalNinjaGenerator::BuildCommandLine)

/Gerhard

From: Olsson Gerhard
Sent: den 27 oktober 2014 3:02
To: 'cmake at cmake.org'
Subject: CMake, armcc and Ninja workarounds and problems

A summary of limitations with (mostly) armcc and Cmake, primarly using Ninja generator.
(Note that this is referring to two emails and add a new problem.)
The workarounds where applicable are listed, as well as possible corrections/enhancements in CMake. I will probably open issues later, maybe patches too, but there may be other solutions.


Setup:
CMake 3.0.2 with Ninja 1.5.1 on Windows. Unix Makefiles was previously used in Windows and is still used in Linux (Linux is used for speedup compilation).
WindRiver Diab (DCC) and ARM DS-5 armcc (RVDS) cross compiling.



1.       No append to log file for armcc
(see original email)
Workaround is to patch generated files, replacing a token with a temp file that is later concatenated.

A proper solution could be custom variables.
For example (set in user part of configuration)
ADD_DEFINITIONS( --errors= logs/<SOURCE_FILE_NAME>.log)
<SOURCE_FILE_NAME> would be a new expand variable, i.e. "SourceFileName.c" in SOURCE path/to/SourceFileName.c
The configuratione



2.       Cannot control name of dependfile set in Ninja

Ninja generator sets the name to objectpath.d
            cmGlobalNinjaGenerator::EncodeDepfileSpace(objectFileName + ".d");

WindRiver sets the dep file name to objectDir/SourceName.d, so the ".obj" in "DEP_FILE = path/BaseName.c.obj.d" must be removed
Armcc just uses base name in the same directory as the command runs, "BaseName.d".  -depend_dir= can be used to control the directory for C but not asm.

The workaround is to patch the generated build.ninja

A proper solution is using new variables similar to above. (Just examples, not figured out <ARCH> etc)

WindRiver (not added to CMake):
SET (CMAKE_<LANG>_<COMPILER_ID>_DEPFILE_PATTERN <OBJECT_DIR>/<SOURCE_FILE_NAME>.d )

Armcc (RVDS patch exists for CMake):
SET (CMAKE_DEPFILE_FLAGS_C -depend_dir=<OBJECT_FULL_DIR> --depend_format=unix)
SET (CMAKE_C_ARMCC_DEPFILE_PATTERN <OBJECT_FULL_DIR>/<SOURCE_BASE_NAME>.d )
SET (CMAKE_DEPFILE_FLAGS_ASM --depend_format=unix)
SET (CMAKE_ASM_ARMCC_DEPFILE_PATTERN <SOURCE_BASE_NAME>.d )

Note: <OBJECT> is replaced in CMAKE_C_ARMCC_DEPFILE_PATTERN (but adding a semicolon), but not <OBJECT_DIR> (as that is evaluated after FLAGS/DEFINES) so it is a little more than just add new variables.
The workaround for armcc could therefore not use CMAKE_DEPFILE_FLAGS_C, the -depend_dir flag was added to normal FLAGS



3.       CMake adds CMD /C  for both LINKER and prelink/postbuild
PRE_LINK and POST_BUILD is executed as part of linking, so extra CMD is an error (at least the quotes)
CMake adds CMD /C for linker, but also for  PRE_LINK and POST_BUILD.CMD /C is added twice.

rule C_EXECUTABLE_LINKER_RSP_FILE
  command = cmd.exe /C "$PRE_LINK && C:\PROGRA~1\DS-5\bin\armcc.exe  $FLAGS  $LINK_FLAGS --via=$RSP_FILE  -o $out  && $POST_BUILD"

The first workaround was to patch build.ninja. Not really needed after the second workaround that removed the need for PRE_LINK/POST_BUILD, stll included in the patches below.
Setup separate targets for a few ASM files (not compiling in PRE_LINK), move out POST_BUILD to separate targets included in ALL.
This works fine here (better if full armcc/WindRiver support was added of course)

I believe the solution is to remove CMD /C for PRE_LINK/POSTBUILD. There are command length complications though.



4.       Commands can be longer than 8000 bytes in Windows

a.       The Ninja generator may need to use RSP_FILE also when compiling.

b.      PRE_LINK/POSTBUILD can give long lines

The workaround for a. is to decrease the include paths, for b. to not use PRE_LINK.

The solution for a. is to evaluate using  RSP_FILE if needed in Ninja. I believe the Unix Makefiles generator handles this better.
For b. I have no good proposal.


/Gerhard

--

Rough workaround
Build is invoked from make (CMAKE_MAKEFILE is set to path to build.ninja):

${CMAKE_MAKEFILE}: ${CMAKELISTS} ${CMAKE_TOOLCHAIN} | ${CMAKE_BUILD_DIR}
                             @${ECHO}
                             $(CMD_V)cd ${CMAKE_BUILD_DIR} && ${CMAKE_MPC5516E} $(CMAKE_FLAGS_MPC5516E) ${CMAKELISTS_OSDIR}

ifeq ($(CMAKE_GENERATOR),${CMAKE_NINJA})
                             @#CMake Ninja uses cmd, quotes incorrectly
                             @perl -pi -e 's%^(\s*(POST_BUILD|PRE_LINK)\s*=\s*)cmd.exe\s(/C)?\s*"(.*)"%$$1$$4%i; ' $@
ifneq ($(COMPILE_DEPEND_DIR),)
                             @#no path for armcc, use --depend_dir=depend to avoid have all in root (asm go there)
                             @perl -pi -e 'BEGIN{$$c="$(COMPILE_DEPEND_DIR)";} s%^(\s*DEP_FILE\s*=\s*).*/(.*).c\.obj\.d\s*$$%$$1$$c/$$2.d\n%;' $@
                             @$(MKDIR) -p $(dir ${CMAKE_MAKEFILE})depend
else
                             @#unexpected suffix (probably other ways to do this)
                             @perl -pi -e 's%^(\s*DEP_FILE\s*=\s*.*)\.obj\.d\s*$$%$$1.d\n%;' $@
endif
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             @perl -pi -e 'BEGIN{$$c="$(COMPILE_LOG_NO_APPEND)"; $$n="unknown"; $$i=1;}if(m%^build .*?([\w\.]+):%){$$n=$$1;} if (s%(--errors)=$$c%$$1=logs/$$n.$$i%){$$i++; $$n="unknown";}' $@
                             @$(MKDIR) -p $(dir ${CMAKE_MAKEFILE})logs
endif

compile_target: ${CMAKE_MAKEFILE} | $(INFO_BUILD_DIR) ${BUILD_RESULT_DIR}
                             @${ECHO}
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             @$(ECHO) " Note: If compile fails: \"make copy_log\""
endif
                             $(CMAKE_MAKE) install
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             @$(MAKE) copy_logs
endif

copy_logs:
ifneq ($(COMPILE_LOG_NO_APPEND),)
                             $(CMD_V)$(CAT) $(CMAKE_BUILD_DIR)/logs/* > ${INFO_BUILD_DIR}/error.txt
                             $(CMD_V)$(RM) $(CMAKE_BUILD_DIR)/logs/*
endif

From: Olsson Gerhard
Sent: den 8 september 2014 7:46
To: 'cmake at cmake.org'
Subject: Compilation logs: Workaround for no appendfile

ARM DS-5 compiler (armcc compiler 5.04)
Platform: Windows and Linux

Armcc (as well as arasm, armlink etc) has option '-errors=file 'to log compilation messages (warnings and errors) to a logfile instead of stdout.
There is no possibility from what I have found out to append to a log file, all output overwrites the log.

Background:
We cannot change some 3rd party code and cannot suppress all compilation warnings. The workaround is to parse the logs.
If printed to the console, the messages are mixed up with progress and license messages.
Other compilers has the possibility to append to logs, but not armcc what I can find.

A workaround would be to CMake to save stdout to a logfile. May be possible, but I am not sure that is a good solution.
Another is to log to unique logname, include the compiled file in the logname. I am not sure how that can be done in CMake.

Any hints how to do this?

/Gerhard



From: Olsson Gerhard
Sent: den 1 oktober 2014 7:46
To: 'cmake at cmake.org'
Subject: Ninja: CMD /C, quoting added for PRE_LINK/POST_BUILD

The commands for PRE_LINK/POST_BUILD is not correctly quoted for Ninja in Windows. 'CMD /C "<command>"' is added to the command, just as Ninja itself does.
(this was maybe different in earlier Ninja versions, but has been around for a couple of years)
(The quoting in the working command is strange, but works.)

A workaround that is not so bad, is to patch build.ninja
Is there a better way?

Note: The lines  LINK_FLAGS ,POST_BUILD ,  PRE_LINK , TARGET_PDB are duplicated in build.ninja. Does not make a difference.

ARM DS-5 compiler (armcc compiler 5.04)
Platform: Windows (Linux used too, but with Unix Makefiles)
CMake 3.0.2
Ninja 1.5.1

/Gerhard


CmakeLists.txt excerpt:

ADD_CUSTOM_COMMAND(
    TARGET ECU
    PRE_LINK
    COMMAND "C:/Program Files/DS-5/bin/armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o ${CMAKE_CURRENT_BINARY_DIR}/osekasm.o c:/Os/osekasm.s VERBATIM
  )

  #Generate hex, copy to view
  add_custom_command(TARGET ECU POST_BUILD
    COMMAND "C:/Program Files/DS-5/bin/fromelf.exe" --m32combined --output=${CMAKE_CURRENT_BINARY_DIR}/ECU.hex ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf VERBATIM
    COMMAND "C:/cygwin/bin/objcopy" -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf ${CMAKE_CURRENT_BINARY_DIR}/parameter_section.hex VERBATIM
  )


Generated in build.ninja:

  LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o
  POST_BUILD = cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex"
  PRE_LINK = cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build"
  TARGET_PDB = ECU.elf.dbg


Console output:

[106/107] Linking C executable ECU.elf
FAILED: cmd.exe /C "cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build" && C:\PROGRA~1\DS-5\bin\armcc.exe    --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o --via=CMakeFiles/ECU.rsp  -o ECU.elf  && cmd.exe /C "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex""
'cmd.exe' is not recognized as an internal or external command,
operable program or batch file.
ninja: build stopped: subcommand failed.


Patched (in Makefile):

${CMAKE_MAKEFILE}: ${CMAKELISTS} ${CMAKE_TOOLCHAIN} | ${CMAKE_BUILD_DIR}
                             @#CMake Ninja uses cmd incorrectly
                             @perl -pi -e 's%^(\s*(POST_BUILD|PRE_LINK)\s*=\s*)cmd.exe\s(/C)?\s*"(.*)"%$$1$$4%i; ' $@



Rules patched OK:

  LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers C:/Temp/build/osekasm.o
  POST_BUILD = cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex
  PRE_LINK = cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build
  TARGET_PDB = ECU.elf.dbg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/d028278c/attachment-0001.html>

From fungos at gmail.com  Tue Oct 28 11:39:57 2014
From: fungos at gmail.com (fungos)
Date: Tue, 28 Oct 2014 11:39:57 -0400
Subject: [CMake] CMake, armcc and Ninja workarounds and problems
In-Reply-To: <289541F89243ED47BC4BAE6C83560E9E471CA81F@SEGOTNC5181-N1.vcn.ds.volvo.net>
References: <289541F89243ED47BC4BAE6C83560E9E471CA81F@SEGOTNC5181-N1.vcn.ds.volvo.net>
Message-ID: <CAJ7KbxkqNv+hiracRMJkJqCqXns850kQQALT7PKSrRW594oPkA@mail.gmail.com>

I agree with your review and I agree that there are plenty of problems to
be able to get everything working correctly.

I would like to warn you and point to an issue about the use of
--depend_format=unix:

https://github.com/martine/ninja/issues/794

Also, I've got around the .obj.d problem patching CMake generator adding a
flag: set(CMAKE_NINJA_DEPFILE_REMOVE_OBJECT_EXT TRUE)

I currently use this:

set(CMAKE_DEPFILE_FLAGS_C "--md --no_depend_system_headers
--depend_format=unix --depend_single_line --depend=<OBJECT>.d")

The sad is that these are simple things to solve but require patches and
maintaining a "fork".

On Tue, Oct 28, 2014 at 10:55 AM, Olsson Gerhard <gerhard.olsson at volvo.com>
wrote:

>  Update:
>
>
>
> 1.       Append to logfile
>
> Just resolving <OBJECT> would be an improvement, but that may require
> changes to all generators, no global resolution what I see.
>
> Should be changed in armcc, dropping for CMake.
>
>
>
> 2.       Dependfile
>
> This can be done in armcc:
>
>     SET( CMAKE_DEPFILE_FLAGS_C "--depend=<OBJECT>.d --depend_format=unix" )
>
> Similar for ARM, but untested.
>
>
>
> WindRiver:
>
>     SET( CMAKE_DEPFILE_FLAGS_C "-Xmake-dependency=6
> -Xmake-dependency-savefile=<OBJECT>.d" )
>
> (not possible for asm)
>
>
>
> So this should be working as intended
>
>
>
>
>
> 3.       Ninja PRE_LINK/POST_BUILD adds cmd.exe
>
> Need to be changed in cmNormalNinjaTargetGenerator.cxx to not add twice.
>
>
>
> vars["PRE_LINK"] =
>
>     this->GetLocalGenerator()->BuildCommandLine(preLinkCmdLines);
>
> (cmLocalNinjaGenerator::BuildCommandLine)
>
>
>
> /Gerhard
>
>
>
> *From:* Olsson Gerhard
> *Sent:* den 27 oktober 2014 3:02
> *To:* 'cmake at cmake.org'
> *Subject:* CMake, armcc and Ninja workarounds and problems
>
>
>
> A summary of limitations with (mostly) armcc and Cmake, primarly using
> Ninja generator.
>
> (Note that this is referring to two emails and add a new problem.)
>
> The workarounds where applicable are listed, as well as possible
> corrections/enhancements in CMake. I will probably open issues later, maybe
> patches too, but there may be other solutions.
>
>
>
>
>
> Setup:
>
> CMake 3.0.2 with Ninja 1.5.1 on Windows. Unix Makefiles was previously
> used in Windows and is still used in Linux (Linux is used for speedup
> compilation).
>
> WindRiver Diab (DCC) and ARM DS-5 armcc (RVDS) cross compiling.
>
>
>
>
>
> 1.       No append to log file for armcc
>
> (see original email)
>
> Workaround is to patch generated files, replacing a token with a temp file
> that is later concatenated.
>
>
>
> A proper solution could be custom variables.
>
> For example (set in user part of configuration)
>
> ADD_DEFINITIONS( --errors= logs/<SOURCE_FILE_NAME>.log)
>
> <SOURCE_FILE_NAME> would be a new expand variable, i.e. ?SourceFileName.c?
> in SOURCE path/to/SourceFileName.c
>
> The configuratione
>
>
>
>
>
> 2.       Cannot control name of dependfile set in Ninja
>
>
>
> Ninja generator sets the name to objectpath.d
>
>             cmGlobalNinjaGenerator::EncodeDepfileSpace(objectFileName +
> ".d");
>
>
>
> WindRiver sets the dep file name to objectDir/SourceName.d, so the ?.obj?
> in ?DEP_FILE = path/BaseName.c.obj.d? must be removed
>
> Armcc just uses base name in the same directory as the command runs,
> ?BaseName.d?.  ?depend_dir= can be used to control the directory for C but
> not asm.
>
>
>
> The workaround is to patch the generated build.ninja
>
>
>
> A proper solution is using new variables similar to above. (Just examples,
> not figured out <ARCH> etc)
>
>
>
> WindRiver (not added to CMake):
>
> SET (CMAKE_<LANG>_<COMPILER_ID>_DEPFILE_PATTERN
> <OBJECT_DIR>/<SOURCE_FILE_NAME>.d )
>
>
>
> Armcc (RVDS patch exists for CMake):
>
> SET (CMAKE_DEPFILE_FLAGS_C ?depend_dir=<OBJECT_FULL_DIR>
> --depend_format=unix)
>
> SET (CMAKE_C_ARMCC_DEPFILE_PATTERN <OBJECT_FULL_DIR>/<SOURCE_BASE_NAME>.d )
>
> SET (CMAKE_DEPFILE_FLAGS_ASM --depend_format=unix)
>
> SET (CMAKE_ASM_ARMCC_DEPFILE_PATTERN <SOURCE_BASE_NAME>.d )
>
>
>
> Note: <OBJECT> is replaced in CMAKE_C_ARMCC_DEPFILE_PATTERN (but adding a
> semicolon), but not <OBJECT_DIR> (as that is evaluated after FLAGS/DEFINES)
> so it is a little more than just add new variables.
>
> The workaround for armcc could therefore not use CMAKE_DEPFILE_FLAGS_C,
> the ?depend_dir flag was added to normal FLAGS
>
>
>
>
>
> 3.       CMake adds CMD /C  for both LINKER and prelink/postbuild
>
> PRE_LINK and POST_BUILD is executed as part of linking, so extra CMD is an
> error (at least the quotes)
>
> CMake adds CMD /C for linker, but also for  PRE_LINK and POST_BUILD.CMD /C
> is added twice.
>
>
>
> rule C_EXECUTABLE_LINKER_RSP_FILE
>
>   command = cmd.exe /C "$PRE_LINK && C:\PROGRA~1\DS-5\bin\armcc.exe
> $FLAGS  $LINK_FLAGS --via=$RSP_FILE  -o $out  && $POST_BUILD"
>
>
>
> The first workaround was to patch build.ninja. Not really needed after the
> second workaround that removed the need for PRE_LINK/POST_BUILD, stll
> included in the patches below.
>
> Setup separate targets for a few ASM files (not compiling in PRE_LINK),
> move out POST_BUILD to separate targets included in ALL.
>
> This works fine here (better if full armcc/WindRiver support was added of
> course)
>
>
>
> I believe the solution is to remove CMD /C for PRE_LINK/POSTBUILD. There
> are command length complications though.
>
>
>
>
>
> 4.       Commands can be longer than 8000 bytes in Windows
>
> a.       The Ninja generator may need to use RSP_FILE also when compiling.
>
> b.      PRE_LINK/POSTBUILD can give long lines
>
>
>
> The workaround for a. is to decrease the include paths, for b. to not use
> PRE_LINK.
>
>
>
> The solution for a. is to evaluate using  RSP_FILE if needed in Ninja. I
> believe the Unix Makefiles generator handles this better.
>
> For b. I have no good proposal.
>
>
>
>
>
> /Gerhard
>
>
>
> --
>
>
>
> Rough workaround
>
> Build is invoked from make (CMAKE_MAKEFILE is set to path to build.ninja):
>
>
>
> ${CMAKE_MAKEFILE}: ${CMAKELISTS} ${CMAKE_TOOLCHAIN} | ${CMAKE_BUILD_DIR}
>
>                              @${ECHO}
>
>                              $(CMD_V)cd ${CMAKE_BUILD_DIR} &&
> ${CMAKE_MPC5516E} $(CMAKE_FLAGS_MPC5516E) ${CMAKELISTS_OSDIR}
>
>
>
> ifeq ($(CMAKE_GENERATOR),${CMAKE_NINJA})
>
>                              @#CMake Ninja uses cmd, quotes incorrectly
>
>                              @perl -pi -e
> 's%^(\s*(POST_BUILD|PRE_LINK)\s*=\s*)cmd.exe\s(/C)?\s*"(.*)"%$$1$$4%i; ' $@
>
> ifneq ($(COMPILE_DEPEND_DIR),)
>
>                              @#no path for armcc, use --depend_dir=depend
> to avoid have all in root (asm go there)
>
>                              @perl -pi -e
> 'BEGIN{$$c="$(COMPILE_DEPEND_DIR)";}
> s%^(\s*DEP_FILE\s*=\s*).*/(.*).c\.obj\.d\s*$$%$$1$$c/$$2.d\n%;' $@
>
>                              @$(MKDIR) -p $(dir ${CMAKE_MAKEFILE})depend
>
> else
>
>                              @#unexpected suffix (probably other ways to
> do this)
>
>                              @perl -pi -e
> 's%^(\s*DEP_FILE\s*=\s*.*)\.obj\.d\s*$$%$$1.d\n%;' $@
>
> endif
>
> ifneq ($(COMPILE_LOG_NO_APPEND),)
>
>                              @perl -pi -e
> 'BEGIN{$$c="$(COMPILE_LOG_NO_APPEND)"; $$n="unknown"; $$i=1;}if(m%^build
> .*?([\w\.]+):%){$$n=$$1;} if (s%(--errors)=$$c%$$1=logs/$$n.$$i%){$$i++;
> $$n="unknown";}' $@
>
>                              @$(MKDIR) -p $(dir ${CMAKE_MAKEFILE})logs
>
> endif
>
>
>
> compile_target: ${CMAKE_MAKEFILE} | $(INFO_BUILD_DIR) ${BUILD_RESULT_DIR}
>
>                              @${ECHO}
>
> ifneq ($(COMPILE_LOG_NO_APPEND),)
>
>                              @$(ECHO) " Note: If compile fails: \"make
> copy_log\""
>
> endif
>
>                              $(CMAKE_MAKE) install
>
> ifneq ($(COMPILE_LOG_NO_APPEND),)
>
>                              @$(MAKE) copy_logs
>
> endif
>
>
>
> copy_logs:
>
> ifneq ($(COMPILE_LOG_NO_APPEND),)
>
>                              $(CMD_V)$(CAT) $(CMAKE_BUILD_DIR)/logs/* >
> ${INFO_BUILD_DIR}/error.txt
>
>                              $(CMD_V)$(RM) $(CMAKE_BUILD_DIR)/logs/*
>
> endif
>
>
>
> *From:* Olsson Gerhard
> *Sent:* den 8 september 2014 7:46
> *To:* 'cmake at cmake.org'
> *Subject:* Compilation logs: Workaround for no appendfile
>
>
>
> ARM DS-5 compiler (armcc compiler 5.04)
>
> Platform: Windows and Linux
>
>
>
> Armcc (as well as arasm, armlink etc) has option ??errors=file ?to log
> compilation messages (warnings and errors) to a logfile instead of stdout.
>
> There is no possibility from what I have found out to append to a log
> file, all output overwrites the log.
>
>
>
> Background:
>
> We cannot change some 3rd party code and cannot suppress all compilation
> warnings. The workaround is to parse the logs.
>
> If printed to the console, the messages are mixed up with progress and
> license messages.
>
> Other compilers has the possibility to append to logs, but not armcc what
> I can find.
>
>
>
> A workaround would be to CMake to save stdout to a logfile. May be
> possible, but I am not sure that is a good solution.
>
> Another is to log to unique logname, include the compiled file in the
> logname. I am not sure how that can be done in CMake.
>
>
>
> Any hints how to do this?
>
>
>
> /Gerhard
>
>
>
>
>
>
>
> *From:* Olsson Gerhard
> *Sent:* den 1 oktober 2014 7:46
> *To:* 'cmake at cmake.org'
> *Subject:* Ninja: CMD /C, quoting added for PRE_LINK/POST_BUILD
>
>
>
> The commands for PRE_LINK/POST_BUILD is not correctly quoted for Ninja in
> Windows. ?CMD /C ?<command>?? is added to the command, just as Ninja itself
> does.
>
> (this was maybe different in earlier Ninja versions, but has been around
> for a couple of years)
>
> (The quoting in the working command is strange, but works.)
>
>
>
> A workaround that is not so bad, is to patch build.ninja
>
> Is there a better way?
>
>
>
> Note: The lines  LINK_FLAGS ,POST_BUILD ,  PRE_LINK , TARGET_PDB are
> duplicated in build.ninja. Does not make a difference.
>
>
>
> ARM DS-5 compiler (armcc compiler 5.04)
>
> Platform: Windows (Linux used too, but with Unix Makefiles)
>
> CMake 3.0.2
>
> Ninja 1.5.1
>
>
>
> /Gerhard
>
>
>
>
>
> CmakeLists.txt excerpt:
>
>
>
> ADD_CUSTOM_COMMAND(
>
>     TARGET ECU
>
>     PRE_LINK
>
>     COMMAND "C:/Program Files/DS-5/bin/armasm.exe" --cpu=Cortex-A9 -g
> --cpreproc --apcs=interwork --arm --no_unaligned_access --pd "__EVAL SETA
> 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o
> ${CMAKE_CURRENT_BINARY_DIR}/osekasm.o c:/Os/osekasm.s VERBATIM
>
>   )
>
>
>
>   #Generate hex, copy to view
>
>   add_custom_command(TARGET ECU POST_BUILD
>
>     COMMAND "C:/Program Files/DS-5/bin/fromelf.exe" --m32combined
> --output=${CMAKE_CURRENT_BINARY_DIR}/ECU.hex
> ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf VERBATIM
>
>     COMMAND "C:/cygwin/bin/objcopy" -I elf32-big -O srec --srec-len=32
> --srec-forceS3 -j .securityLevel ${CMAKE_CURRENT_BINARY_DIR}/ECU.elf
> ${CMAKE_CURRENT_BINARY_DIR}/parameter_section.hex VERBATIM
>
>   )
>
>
>
>
>
> Generated in build.ninja:
>
>
>
>   LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a
> -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map
> -L--no_remove -L--symbols
> -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers
> C:/Temp/build/osekasm.o
>
>   POST_BUILD = cmd.exe /C "cd /D C:\Temp\build && "C:\Program
> Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex
> C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec
> --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf
> C:/Temp/build/parameter_section.hex"
>
>   PRE_LINK = cmd.exe /C "cd /D C:\Temp\build && "C:\Program
> Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork
> --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1"
> -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd
> C:\Temp\build"
>
>   TARGET_PDB = ECU.elf.dbg
>
>
>
>
>
> Console output:
>
>
>
> [106/107] Linking C executable ECU.elf
>
> FAILED: cmd.exe /C "cmd.exe /C "cd /D C:\Temp\build && "C:\Program
> Files\DS-5\bin\armasm.exe" --cpu=Cortex-A9 -g --cpreproc --apcs=interwork
> --arm --no_unaligned_access --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1"
> -Ic:/Temp/includes -o C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd
> C:\Temp\build" && C:\PROGRA~1\DS-5\bin\armcc.exe    --cpu=Cortex-A9
> c:/Temp/includes/SecModLib.a  -L--list=c:/Temp/build/ECU.map
> -L--scatter=c:/Zynq7000/scatter.txt  -L--map -L--no_remove -L--symbols
> -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers
> C:/Temp/build/osekasm.o --via=CMakeFiles/ECU.rsp  -o ECU.elf  && cmd.exe /C
> "cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\fromelf.exe"
> --m32combined --output=C:/Temp/build/ECU.hex C:/Temp/build/ECU.elf &&
> C:\cygwin\bin\objcopy -I elf32-big -O srec --srec-len=32 --srec-forceS3 -j
> .securityLevel C:/Temp/build/ECU.elf C:/Temp/build/parameter_section.hex""
>
> 'cmd.exe' is not recognized as an internal or external command,
>
> operable program or batch file.
>
> ninja: build stopped: subcommand failed.
>
>
>
>
>
> Patched (in Makefile):
>
>
>
> ${CMAKE_MAKEFILE}: ${CMAKELISTS} ${CMAKE_TOOLCHAIN} | ${CMAKE_BUILD_DIR}
>
>                              @#CMake Ninja uses cmd incorrectly
>
>                              @perl -pi -e
> 's%^(\s*(POST_BUILD|PRE_LINK)\s*=\s*)cmd.exe\s(/C)?\s*"(.*)"%$$1$$4%i; ' $@
>
>
>
>
>
>
>
> Rules patched OK:
>
>
>
>   LINK_FLAGS = --cpu=Cortex-A9  c:/Temp/includes/SecModLib.a
> -L--list=c:/Temp/build/ECU.map -L--scatter=c:/Zynq7000/scatter.txt  -L--map
> -L--no_remove -L--symbols
> -L--info=common,summarysizes,summarystack,sizes,totals,unused,unusedsymbols,veneers
> C:/Temp/build/osekasm.o
>
>   POST_BUILD = cd /D C:\Temp\build && "C:\Program
> Files\DS-5\bin\fromelf.exe" --m32combined --output=C:/Temp/build/ECU.hex
> C:/Temp/build/ECU.elf && C:\cygwin\bin\objcopy -I elf32-big -O srec
> --srec-len=32 --srec-forceS3 -j .securityLevel C:/Temp/build/ECU.elf
> C:/Temp/build/parameter_section.hex
>
>   PRE_LINK = cd /D C:\Temp\build && "C:\Program Files\DS-5\bin\armasm.exe"
> --cpu=Cortex-A9 -g --cpreproc --apcs=interwork --arm --no_unaligned_access
> --pd "__EVAL SETA 1" --pd "__MICROLIB SETA 1" -Ic:/Temp/includes -o
> C:/Temp/build/osekasm.o c:/Temp/Os/osekasm.s && cd C:\Temp\build
>
>   TARGET_PDB = ECU.elf.dbg
>
>
>
> --
>
> 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
>



-- 
Animal Liberation Front
http://www.animal-liberation.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/c561d39a/attachment-0001.html>

From fungos at gmail.com  Tue Oct 28 12:05:01 2014
From: fungos at gmail.com (fungos)
Date: Tue, 28 Oct 2014 12:05:01 -0400
Subject: [CMake] Is anyone working on a FASTBuild Generator?
In-Reply-To: <CAHC2tLq2uc7y38ySX3xkEX9e5MbaHwefAZ51V0Z=za-c7LH1UA@mail.gmail.com>
References: <CAHC2tLq2uc7y38ySX3xkEX9e5MbaHwefAZ51V0Z=za-c7LH1UA@mail.gmail.com>
Message-ID: <CAJ7Kbxn2oiSHhexHjf+e5VN=Bjxjq29f1jwxkQHhgK_qZ7r43g@mail.gmail.com>

Yes, some weeks ago I was interested in this too, I've contacted the author
and proposed to do some work on this, but then I got blocked for other
reasons and had to go with Ninja+SN-DBS. Anyway, this talk may help me with
politics here and maybe I can regain traction on FASTBuild.

Otherwise, I've just one thing to say about FASTBuild: Amazing good, MUST
HAVE.

On Tue, Oct 28, 2014 at 12:13 AM, Joshua T. Fisher <j.fisher at digipen.edu>
wrote:

> And if not, is there any information on how an outside developer might
> begin work on a custom generator? I'm just a student, so I'm not sure how
> much time I have to dedicate to something like this, but I am interested in
> seeing what's involved.
>
> Link to FASTBuild:
> http://www.fastbuild.org/docs/home.html
>
> Link to Nicolas Fleury's talk where he talks about FASTBuild:
> https://www.youtube.com/watch?v=qYN6eduU06s#t=436
>
> --
>
> 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
>



-- 
Animal Liberation Front
http://www.animal-liberation.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/4abc2807/attachment.html>

From rcdailey.lists at gmail.com  Tue Oct 28 13:25:26 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 28 Oct 2014 12:25:26 -0500
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
Message-ID: <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>

I have a third party library like OpenSSL prebuilt for each platform
and in my own structure in version control. I have a CMake script that
creates an INTERFACE library target for it. I setup the include
directories and link targets. However, I don't see a way to configure
DLLs in the interface library target. How would you do this, and what
would CMake do to these targets to make sure they are copied to the
output directory of the executable I run from Visual Studio for
debugging?

On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
<post at hendrik-sattler.de> wrote:
> Hi,
>
> you can use generator expression in a post build rule to copy the dll file to the same target dir as the target you link it with. The easiest way to do this is to properly define all 3rd party libraries as imported targets that contains both, the lib and the dll file.
> Sadly, the FindQt4 on Windows doesn't do this and thus make life harder than needed. CMake configuration files should always do this right.
>
> OTOH, you could also write a wrapper batch file or change VS properties to modify PATH to include all libraries before the regular path.
>
> HS
>
>
> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey <rcdailey.lists at gmail.com>:
>>This actually used to be a very difficult problem to solve. However,
>>to debug in visual studio it's essential.
>>
>>If I have DLLs located in third party directories OR from targets that
>>I depend on, those must all be copied to the directory of the
>>executable I'm debugging in order for those DLLs to be found and
>>loaded.
>>
>>Using CMake 3.0.2, I hope this task is simpler, especially with the
>>introduction of a nice suite of generator expressions. Can anyone
>>recommend a good way to do this?
>

From george.ryan at gmail.com  Tue Oct 28 14:16:05 2014
From: george.ryan at gmail.com (George)
Date: Tue, 28 Oct 2014 15:16:05 -0300
Subject: [CMake] find_package_handle_standard_args VERSION_VAR
Message-ID: <CAM+az=Kp-uwRmrncEoH3DT-Y_H7=N5TO+FzrV=jiNJxM_nshzQ@mail.gmail.com>

Hello,

I am using cmake version 2.8.12.2. I am trying to force an exact version
number match in a custom finder, and the VERSION_VAR parameter does not
seem to be working the way I am using it.

I have the following simple example:

file: FindHello.cmake
-------------------------------------
include(FindPackageHandleStandardArgs)
set( VV "1.5.0" )
set( RV "Hello" )
find_package_handle_standard_args(Hello REQUIRED_VARS RV VERSION_VAR ${VV} )

if(HELLO_FOUND)
  message( "yes" )
else()
  message( "no" )
endif()
----------------------------------------------

file: CMakeLists.txt
----------------------------------------------
cmake_minimum_required(VERSION 2.6)
project( hello )
set( CMAKE_MODULE_PATH
${CMAKE_CURRENT_SOURCE_DIR}/finder )
find_package( Hello 6.0.0 EXACT )
----------------------------------------------

No matter what I pass in to the find_package( Hello ) call in terms of
version numbers and modifiers, the finder always prints out "yes" as though
the VERSION_VAR parameter wasn't working.

Any suggestions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/ba79e0ec/attachment.html>

From robert.maynard at kitware.com  Tue Oct 28 14:16:58 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 28 Oct 2014 14:16:58 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
Message-ID: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>

I am proud to announce that CMake 3.1 has entered the release candidate stage.

Sources and binaries are available at:
  http://www.cmake.org/files/v3.1/?C=M;O=D

Documentation is available at:
  http://www.cmake.org/cmake/help/v3.1

Release notes appear below and are also published at
  http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html

Some of the more significant features of CMake 3.1 are:

* Windows Phone and Windows Store support has been added to  Visual Studio 11
  (2012) and above Generators.

* NVIDIA Nsight Tegra support has been added to  Visual Studio 10 (2010) and
  above Generators.

* New "target_compile_features" command allows populating target based compile
  features. CMake uses this information to ensure that the compiler in use is
  capable of building the target, and to add any necessary compile flags
  such as -std=gnu++11 to support language features.
  More information on this is found at:
  - http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html

* The syntax for *Variable References* and *Escape Sequences* was simplified in
  order to allow a much faster implementation. See policy "CMP0053".

* The "if" command no longer automatically dereferences variables named in
  quoted or bracket arguments.  See policy "CMP0054".

* The target property "SOURCES" now generally supports "Generator Expressions".
  The generator expressions may be used in the "add_library" and
  "add_executable" commands.

* It is now possible to write and append to the target property "SOURCES".
  The variable "CMAKE_DEBUG_TARGET_PROPERTIES" can be used to trace the
  origin of sources.

* CPack gained "7Z" and "TXZ" generators supporting lzma-compressed archives.

* The ExternalProject module has learned to support lzma-compressed
  source tarballs with ".7z", ".tar.xz", and ".txz" extensions.

* The ExternalProject module ExternalProject_Add command learned a new
  BUILD_ALWAYS option to cause the external project build step to run every
  time the host project is built.

* The ctest_coverage command learned to support Intel coverage files with the
  "codecov" tool.

* The ctest_memcheck command learned to support sanitizer modes, including
  "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and
  "UndefinedBehaviorSanitizer".

Deprecated and Removed Features:

* In CMake 3.0 the "target_link_libraries" command accidentally began allowing
  unquoted arguments to use Generator Expressions containing a semicolon
  separated list within them. For example:

    set(libs B C)
    target_link_libraries(A PUBLIC $<BUILD_INTERFACE:${libs}>)

  This is equivalent to writing:

    target_link_libraries(A PUBLIC $<BUILD_INTERFACE:B C>)

  and was never intended to work. It did not work in CMake 2.8.12.
  Such generator expressions should be in quoted arguments:

    set(libs B C)
    target_link_libraries(A PUBLIC "$<BUILD_INTERFACE:${libs}>")

  CMake 3.1 again requires the quotes for this to work correctly.


CMake 3.1.0 Release Notes
*************************

Changes made since CMake 3.0.0 include the following.


Documentation Changes
=====================

* A new "cmake-compile-features(7)" manual was added.


New Features
============


Generators
----------

* A "Visual Studio 14" generator was added.


Windows Phone and Windows Store
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Generators for Visual Studio 11 (2012) and above learned to
  generate projects for Windows Phone and Windows Store.  One may set
  the "CMAKE_SYSTEM_NAME" variable to "WindowsPhone" or "WindowsStore"
  on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to
  activate these platforms. Also set "CMAKE_SYSTEM_VERSION" to "8.0"
  or "8.1" to specify the version of Windows to be targeted.


NVIDIA Nsight Tegra
~~~~~~~~~~~~~~~~~~~

* Generators for Visual Studio 10 (2010) and above learned to
  generate projects for NVIDIA Nsight Tegra Visual Studio Edition.
  One may set the "CMAKE_SYSTEM_NAME" variable to "Android" on the
  "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate
  this platform.


Syntax
------

* The "cmake-language(7)" syntax for *Variable References* and
  *Escape Sequences* was simplified in order to allow a much faster
  implementation.  See policy "CMP0053".

* The "if()" command no longer automatically dereferences variables
  named in quoted or bracket arguments.  See policy "CMP0054".


Commands
--------

* The "add_custom_command()" command learned to interpret "cmake-
  generator-expressions(7)" in arguments to "DEPENDS".

* The "export(PACKAGE)" command learned to check the
  "CMAKE_EXPORT_NO_PACKAGE_REGISTRY" variable to skip exporting the
  package.

* The "file(STRINGS)" command gained a new "ENCODING" option to
  enable extraction of "UTF-8" strings.

* The "find_package()" command learned to check the
  "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" and
  "CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY" variables to skip
  searching the package registries.

* The "install()" command learned a "MESSAGE_NEVER" option to avoid
  output during installation.

* The "string()" command learned a new "GENEX_STRIP" subcommand
  which removes "generator expression".

* The "string()" command learned a new "UUID" subcommand to generate
  a univerally unique identifier.

* New "target_compile_features()" command allows populating the
  "COMPILE_FEATURES" target property, just like any other build
  variable.

* The "target_sources()" command was added to add to the "SOURCES"
  target property.


Variables
---------

* The Visual Studio generators for versions 8 (2005) and above
  learned to read the target platform name from a new
  "CMAKE_GENERATOR_PLATFORM" variable when it is not specified as part
  of the generator name.  The platform name may be specified on the
  "cmake(1)" command line with the "-A" option, e.g. "-G "Visual
  Studio 12 2013" -A x64".

* The "CMAKE_GENERATOR_TOOLSET" variable may now be initialized in a
  toolchain file specified by the "CMAKE_TOOLCHAIN_FILE" variable.
  This is useful when cross-compiling with the Xcode or Visual Studio
  generators.

* The "CMAKE_INSTALL_MESSAGE" variable was introduced to optionally
  reduce output installation.


Properties
----------

* New "CXX_STANDARD" and "CXX_EXTENSIONS" target properties may
  specify values which CMake uses to compute required compile options
  such as "-std=c++11" or "-std=gnu++11". The "CMAKE_CXX_STANDARD" and
  "CMAKE_CXX_EXTENSIONS" variables may be set to initialize the target
  properties.

* New "C_STANDARD" and "C_EXTENSIONS" target properties may specify
  values which CMake uses to compute required compile options such as
  "-std=c11" or "-std=gnu11". The "CMAKE_C_STANDARD" and
  "CMAKE_C_EXTENSIONS" variables may be set to initialize the target
  properties.

* New "COMPILE_FEATURES" target property may contain a list of
  features required to compile a target.  CMake uses this information
  to ensure that the compiler in use is capable of building the
  target, and to add any necessary compile flags to support language
  features.

* New "COMPILE_PDB_NAME" and "COMPILE_PDB_OUTPUT_DIRECTORY" target
  properties were introduced to specify the MSVC compiler program
  database file location ("cl /Fd").  This complements the existing
  "PDB_NAME" and "PDB_OUTPUT_DIRECTORY" target properties that specify
  the linker program database file location ("link /pdb").

* The "INTERFACE_LINK_LIBRARIES" target property now supports a
  "$<LINK_ONLY:...>" "generator expression".

* A new "INTERFACE_SOURCES" target property was introduced. This is
  consumed by dependent targets, which compile and link the listed
  sources.

* The "SOURCES" target property now contains "generator expression"
  such as "TARGET_OBJECTS" when read at configure time, if policy
  "CMP0051" is "NEW".

* The "SOURCES" target property now generally supports "generator
  expression".  The generator expressions may be used in the
  "add_library()" and "add_executable()" commands.

* It is now possible to write and append to the "SOURCES" target
  property.  The "CMAKE_DEBUG_TARGET_PROPERTIES" variable may be used
  to trace the origin of sources.

* A "VS_DEPLOYMENT_CONTENT" source file property was added to tell
  the Visual Studio generators to mark content for deployment in
  Windows Phone and Windows Store projects.

* The "VS_WINRT_COMPONENT" target property was created to tell
  Visual Studio generators to compile a shared library as a Windows
  Runtime (WinRT) component.

* The "Xcode" generator learned to check source file properties
  "XCODE_EXPLICIT_FILE_TYPE" and "XCODE_LAST_KNOWN_FILE_TYPE" for a
  custom Xcode file reference type.


Modules
-------

* The "BundleUtilities" module learned to resolve and replace
  "@rpath" placeholders on OS X to correctly bundle applications using
  them.

* The "CMakePackageConfigHelpers" module
  "configure_package_config_file()" command learned a new
  "INSTALL_PREFIX" option to generate package configuration files
  meant for a prefix other than "CMAKE_INSTALL_PREFIX".

* The "CheckFortranSourceCompiles" module was added to provide a
  "CHECK_Fortran_SOURCE_COMPILES" macro.

* The "ExternalData" module learned to tolerate a "DATA{}" reference
  to a missing source file with a warning instead of rejecting it with
  an error.  This helps developers write new "DATA{}" references to
  test reference outputs that have not yet been created.

* The "ExternalProject" module learned to support lzma-compressed
  source tarballs with ".7z", ".tar.xz", and ".txz" extensions.

* The "ExternalProject" module "ExternalProject_Add" command learned
  a new "BUILD_ALWAYS" option to cause the external project build step
  to run every time the host project is built.

* The "ExternalProject" module "ExternalProject_Add" command learned
  a new "EXCLUDE_FROM_ALL" option to cause the external project target
  to have the "EXCLUDE_FROM_ALL" target property set.

* The "ExternalProject" module "ExternalProject_Add_Step" command
  learned a new "EXCLUDE_FROM_MAIN" option to cause the step to not be
  a direct dependency of the main external project target.

* The "ExternalProject" module "ExternalProject_Add" command learned
  a new "DOWNLOAD_NO_PROGRESS" option to disable progress output while
  downloading the source tarball.

* The "FeatureSummary" module "feature_summary" API learned to
  accept multiple values for the "WHAT" option and combine them
  appropriately.

* The "FindCUDA" module learned to support "fatbin" and "cubin"
  modules.

* The "FindGTest" module "gtest_add_tests" macro learned a new
  "AUTO" option to automatically read the "SOURCES" target property of
  the test executable and scan the source files for tests to be added.

* The "FindGLEW" module now provides imported targets.

* The "FindGLUT" module now provides imported targets.

* The "FindHg" module gained a new "Hg_WC_INFO" macro to help run
  "hg" to extract information about a Mercurial work copy.

* The "FindOpenCL" module was introduced.

* The "FindOpenGL" module now provides imported targets "OpenGL::GL"
  and "OpenGL::GLU" when the libraries are found.

* The "FindOpenMP" module learned to support Fortran.

* The "FindPkgConfig" module learned to use the "PKG_CONFIG"
  environment variable value as the "pkg-config" executable, if set.

* The "FindVTK" module dropped support for finding VTK 4.0. It is
  now a thin-wrapper around "find_package(VTK ... NO_MODULE)". This
  produces much clearer error messages when VTK is not found.

* The "FindZLIB" module now provides imported targets.

* The "GenerateExportHeader" module "generate_export_header"
  function learned to allow use with *Object Libraries*.

* The "InstallRequiredSystemLibraries" module gained a new
  "CMAKE_INSTALL_OPENMP_LIBRARIES" option to install MSVC OpenMP
  runtime libraries.

* The "UseSWIG" module learned to detect the module name from ".i"
  source files if possible to avoid the need to set the
  "SWIG_MODULE_NAME" source file property explicitly.

* The "WriteCompilerDetectionHeader" module was added to allow
  creation of a portable header file for compiler optional feature
  detection.


Generator Expressions
---------------------

* New "COMPILE_FEATURES" "generator expression" allows setting build
  properties based on available compiler features.


CTest
-----

* The "ctest_coverage()" command learned to read variable
  "CTEST_COVERAGE_EXTRA_FLAGS" to set "CoverageExtraFlags".

* The "ctest_coverage()" command learned to support Intel coverage
  files with the "codecov" tool.

* The "ctest_memcheck()" command learned to support sanitizer modes,
  including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer",
  and "UndefinedBehaviorSanitizer". Options may be set using the new
  "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable.


CPack
-----

* "cpack(1)" gained an "IFW" generator to package using Qt Framework
  Installer tools.  See the "CPackIFW" module.

* "cpack(1)" gained "7Z" and "TXZ" generators supporting lzma-
  compressed archives.

* The "CPackDeb" module learned a new
  "CPACK_DEBIAN_COMPRESSION_TYPE" variable to set the tarball
  compression type.

* The "cpack(1)" "WiX" generator learned to support a
  "CPACK_WIX_ACL" installed file property to specify an Access Control
  List.


Other
-----

* The "cmake(1)" "-E" option learned a new "env" command.

* The "cmake(1)" "-E tar" command learned to support lzma-compressed
  files.

* *Object Libraries* may now have extra sources that do not compile
  to object files so long as they would not affect linking of a normal
  library (e.g. ".dat" is okay but not ".def").

* Visual Studio generators for VS 8 and later learned to support the
  "ASM_MASM" language.

* The Visual Studio generators learned to treat ".hlsl" source files
  as High Level Shading Language sources (using "FXCompile" in
  ".vcxproj" files).  A "VS_SHADER_TYPE" source file property was
  added to specify the Shader Type.


New Diagnostics
===============

* Policy "CMP0052" introduced to control directories in the
  "INTERFACE_INCLUDE_DIRECTORIES" of exported targets.


Deprecated and Removed Features
===============================

* In CMake 3.0 the "target_link_libraries()" command accidentally
  began allowing unquoted arguments to use "generator expressions"
  containing a (";" separated) list within them.  For example:

     set(libs B C)
     target_link_libraries(A PUBLIC $<BUILD_INTERFACE:${libs}>)

  This is equivalent to writing:

     target_link_libraries(A PUBLIC $<BUILD_INTERFACE:B C>)

  and was never intended to work.  It did not work in CMake 2.8.12.
  Such generator expressions should be in quoted arguments:

     set(libs B C)
     target_link_libraries(A PUBLIC "$<BUILD_INTERFACE:${libs}>")

  CMake 3.1 again requires the quotes for this to work correctly.

* Callbacks established by the "variable_watch()" command will no
  longer receive the "ALLOWED_UNKNOWN_READ_ACCESS" access type when
  the undocumented "CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS" variable
  is set.  Uninitialized variable accesses will always be reported as
  "UNKNOWN_READ_ACCESS".

* The "CMakeDetermineVSServicePack" module now warns that it is
  deprecated and should not longer be used.  Use the
  "CMAKE_<LANG>_COMPILER_VERSION" variable instead.


Other Changes
=============

* The "cmake-gui(1)" learned to capture output from child processes
  started by the "execute_process()" command and display it in the
  output window.

* The "cmake-language(7)" internal implementation of generator
  expression and list expansion parsers have been optimized and shows
  non-trivial speedup on large projects.

* The Makefile generators learned to use response files with GNU
  tools on Windows to pass library directories and names to the
  linker.

* When generating linker command-lines, CMake now avoids repeating
  items corresponding to SHARED library targets.

* Support for the Open Watcom compiler has been overhauled. The
  "CMAKE_<LANG>_COMPILER_ID" is now "OpenWatcom", and the
  "CMAKE_<LANG>_COMPILER_VERSION" now uses the Open Watcom external
  version numbering.  The external version numbers are lower than the
  internal version number by 11.

From eike at sf-mail.de  Tue Oct 28 15:29:34 2014
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 28 Oct 2014 20:29:34 +0100
Subject: [CMake] find_package_handle_standard_args VERSION_VAR
In-Reply-To: <CAM+az=Kp-uwRmrncEoH3DT-Y_H7=N5TO+FzrV=jiNJxM_nshzQ@mail.gmail.com>
References: <CAM+az=Kp-uwRmrncEoH3DT-Y_H7=N5TO+FzrV=jiNJxM_nshzQ@mail.gmail.com>
Message-ID: <1560392.CVfXGRzGnK@caliban.sf-tec.de>

Am Dienstag, 28. Oktober 2014, 15:16:05 schrieb George:
> Hello,
> 
> I am using cmake version 2.8.12.2. I am trying to force an exact version
> number match in a custom finder, and the VERSION_VAR parameter does not
> seem to be working the way I am using it.
> 
> I have the following simple example:
> 
> file: FindHello.cmake
> -------------------------------------
> include(FindPackageHandleStandardArgs)
> set( VV "1.5.0" )
> set( RV "Hello" )
> find_package_handle_standard_args(Hello REQUIRED_VARS RV VERSION_VAR ${VV} )

find_package_handle_standard_args(Hello REQUIRED_VARS RV VERSION_VAR VV )

You want to pass the variable name to FPHSA, not it's content.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/d9ee2d29/attachment.sig>

From steveire at gmail.com  Tue Oct 28 17:29:11 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 28 Oct 2014 22:29:11 +0100
Subject: [CMake] CMP0020 warning
References: <6FD2E165340D9A429CF831C7A2D4F42E4E3E7E8F@WIN-R92V03RFJ85.onshorecs.local>
Message-ID: <m2p1r5$rp3$1@ger.gmane.org>

Scott Aron Bloom wrote:

> The warning message for CMP0020 seems to be completely random as to where
> you actually have to set the policy.
> 
> Im not getting the warning on my main executables, but cant seem to get
> rid of it on any of my Qt based unittests (using gmock/gtest )
> 
> I have the following line, in various places in the system,
>         cmake_policy(SET CMP0020 NEW)
> 
> but is there any documentation on where it MUST be set???

Anywhere should do. Note that policies are cleared by the 
cmake_minimum_required command. If you use that multiple times, you probably 
shouldn't.

If the problem persists, feel free to provide an example.

Thanks,

Steve.



From steveire at gmail.com  Tue Oct 28 18:00:49 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 28 Oct 2014 23:00:49 +0100
Subject: [CMake] Is there really no way in CMake to retrieve the objects
	file for a target?
References: <CAKJJEPz9a7-wDkKt0TLth0DWJrkykuCcLrGktcb-hmmF2_tLuQ@mail.gmail.com>
Message-ID: <m2p3mf$a15$1@ger.gmane.org>

Emmanuel Blot wrote:

> This seems so convoluted that I guess I'm missing the proper way to
> properly add an intermediate step between the compilation and link
> stages, but I keep failing to find any useful advice from Google and
> the mailing list.

It's probably not possible cleanly.

Generator expressions can give you the list of object files in the makefile 
generators, but limitations in how the IDE generators work make it hard to 
implement.

 http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5de63265
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9705/focus=9722

I added a bug report to track this missing feature:

 http://public.kitware.com/Bug/view.php?id=15226

However, this is all just for information. I don't know that you'd be able 
to manipulate the files between compilation and linking without messing up 
the dependency logic.

Thanks,

Steve.



From post at hendrik-sattler.de  Wed Oct 29 11:45:15 2014
From: post at hendrik-sattler.de (Hendrk Sattler)
Date: Wed, 29 Oct 2014 16:45:15 +0100
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
Message-ID: <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>

Am 2014-10-28 18:25, schrieb Robert Dailey:
> I have a third party library like OpenSSL prebuilt for each platform
> and in my own structure in version control. I have a CMake script that
> creates an INTERFACE library target for it. I setup the include
> directories and link targets. However, I don't see a way to configure
> DLLs in the interface library target. How would you do this, and what
> would CMake do to these targets to make sure they are copied to the
> output directory of the executable I run from Visual Studio for
> debugging?

I have this for ZLib:
if ( ZLIB_FOUND )
   if ( WIN32 )
     get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
     get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE )
     get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
     find_file ( ZLIB_DLL 
"${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
       HINTS
         "${ZLIB_LIBDIR_BASE}"
       PATH_SUFFIXES
         bin
       NO_DEFAULT_PATH
     )
     mark_as_advanced ( ZLIB_DLL )
     if ( ZLIB_DLL )
       add_library ( zlib SHARED IMPORTED GLOBAL )
       set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB 
"${ZLIB_LIBRARY}" )
       set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION 
"${ZLIB_DLL}" )
     else ( ZLIB_DLL )
       add_library ( zlib STATIC IMPORTED GLOBAL )
       set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION 
"${ZLIB_LIBRARY}" )
     endif ( ZLIB_DLL )
   else( WIN32 )
     add_library ( zlib UNKNOWN IMPORTED GLOBAL )
     set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION 
"${ZLIB_LIBRARY}" )
   endif( WIN32 )
   set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
     "${ZLIB_INCLUDE_DIR}"
   )

   set ( ZLIB_LIBRARIES zlib )
   set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
endif ( ZLIB_FOUND )

The .lib goes into IMPORTED_IMPLIB and the .dll goes into 
IMPORTED_LOCATION.
The way to find the .dll from the location of the .lib might differ for 
different libraries.
For ZLib, the base name is the same.

Later, you can use this imported target:
   add_custom_command ( TARGET myTarget POST_BUILD
     COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib> 
$<TARGET_FILE_DIR:myTarget>
   )
Now, zlib.dll is in the same directory as myTarget.dll.

HS

> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
> <post at hendrik-sattler.de> wrote:
>> Hi,
>> 
>> you can use generator expression in a post build rule to copy the dll 
>> file to the same target dir as the target you link it with. The 
>> easiest way to do this is to properly define all 3rd party libraries 
>> as imported targets that contains both, the lib and the dll file.
>> Sadly, the FindQt4 on Windows doesn't do this and thus make life 
>> harder than needed. CMake configuration files should always do this 
>> right.
>> 
>> OTOH, you could also write a wrapper batch file or change VS 
>> properties to modify PATH to include all libraries before the regular 
>> path.
>> 
>> HS
>> 
>> 
>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey 
>> <rcdailey.lists at gmail.com>:
>>> This actually used to be a very difficult problem to solve. However,
>>> to debug in visual studio it's essential.
>>> 
>>> If I have DLLs located in third party directories OR from targets 
>>> that
>>> I depend on, those must all be copied to the directory of the
>>> executable I'm debugging in order for those DLLs to be found and
>>> loaded.
>>> 
>>> Using CMake 3.0.2, I hope this task is simpler, especially with the
>>> introduction of a nice suite of generator expressions. Can anyone
>>> recommend a good way to do this?
>> 
> --
> 
> 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

From post at hendrik-sattler.de  Wed Oct 29 12:04:41 2014
From: post at hendrik-sattler.de (Hendrk Sattler)
Date: Wed, 29 Oct 2014 17:04:41 +0100
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
In-Reply-To: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
Message-ID: <e6d07fe8e645ca70f6a418628d811322@mail.hendrik-sattler.de>

Am 2014-10-28 19:16, schrieb Robert Maynard:
> * The "FindZLIB" module now provides imported targets.

Either the provided modules go the whole way for imported target or they 
just don't provide them.
However:
113 if(ZLIB_FOUND)
114     set(ZLIB_INCLUDE_DIRS ${ZLIB_INCLUDE_DIR})
115     set(ZLIB_LIBRARIES ${ZLIB_LIBRARY})
116
117     if(NOT TARGET ZLIB::ZLIB)
118       add_library(ZLIB::ZLIB UNKNOWN IMPORTED)
119       set_target_properties(ZLIB::ZLIB PROPERTIES
120         IMPORTED_LOCATION "${ZLIB_LIBRARY}"
121         INTERFACE_INCLUDE_DIRECTORIES "${ZLIB_INCLUDE_DIRS}")
122     endif()
123 endif()

This is not quite the solution anybody dreamed of.
This is only usable on e.g. Linux. And there, the advantage of an 
imported target is minimal because the zlib include is 99,99% in the 
standard include path, anyway.

Where is the .dll on Windows here?
Why is IMPORTED_IMPLIB not used properly?

Same probably goes for most (all?) imported target from standard CMake 
find modules, e.g. FindQt4 also gets this wrong.

Additionally, I might want to have an imported target available 
globally. How do I do this with targets from find modules?
Why do I need that: To get a list of linked libraries from a target and 
obtain the runtime library (.dll on Windows) from that list.

:-(

HS


From dschepler at scalable-networks.com  Wed Oct 29 12:58:28 2014
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Wed, 29 Oct 2014 16:58:28 +0000
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
In-Reply-To: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>

Where would I find the list of available C++ language features?  For instance, I would suppose there's one for "auto", one for move constructors/assignment operators, and one for "= delete" of default constructors/destructors et al.  These are probably the ones we'd be most interested in here, for the moment.  (Though with our requirements to support older C++ compilers, we might not actually be able to use auto, as the fallback would need the full type anyway.)  Also, is there a portability macro provided for the "= delete" feature?

Also, how would I mark a target so that it activates C++11 features if available, but falls back to old C++ if not?  I do see the section on detecting compiler features, but it's not clear to me how exactly how I'd make the target use CXX_STANDARD 11 only if available.
-- 
Daniel


From robert.maynard at kitware.com  Wed Oct 29 13:42:46 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 29 Oct 2014 13:42:46 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>
Message-ID: <CAFzjYVq_rGhp5yd7GDwT8dp5cA42zPUEbGPAxU4cNTj4n7WXPQ@mail.gmail.com>

You can find the known compile features that can be detected at:
http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html

At the end of the compile-features manual page (
http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
) there is a section on how to mark a library as having conditional
support on C++11 features.


On Wed, Oct 29, 2014 at 12:58 PM, Daniel Schepler
<dschepler at scalable-networks.com> wrote:
> Where would I find the list of available C++ language features?  For instance, I would suppose there's one for "auto", one for move constructors/assignment operators, and one for "= delete" of default constructors/destructors et al.  These are probably the ones we'd be most interested in here, for the moment.  (Though with our requirements to support older C++ compilers, we might not actually be able to use auto, as the fallback would need the full type anyway.)  Also, is there a portability macro provided for the "= delete" feature?
>
> Also, how would I mark a target so that it activates C++11 features if available, but falls back to old C++ if not?  I do see the section on detecting compiler features, but it's not clear to me how exactly how I'd make the target use CXX_STANDARD 11 only if available.
> --
> Daniel
>
> --
>
> 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

From dschepler at scalable-networks.com  Wed Oct 29 14:15:40 2014
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Wed, 29 Oct 2014 18:15:40 +0000
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>
 <CAFzjYVq_rGhp5yd7GDwT8dp5cA42zPUEbGPAxU4cNTj4n7WXPQ@mail.gmail.com> 
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D398A@SNTMAIL01.snt.loc>

(Whoops, accidentally sent this via private email before.)

My question was about this part of the example:

add_executable(consumer_with consumer_with.cpp)
target_link_libraries(consumer_with foo)
set_property(TARGET consumer_with CXX_STANDARD 11)

add_executable(consumer_no consumer_no.cpp)
target_link_libraries(consumer_no foo)

The question is: how do I detect whether CXX_STANDARD 11 is available before running the "set_property(TARGET consumer_with CXX_STANDARD 11)" line?
--
Daniel


-----Original Message-----
From: Robert Maynard [mailto:robert.maynard at kitware.com] 
Sent: Wednesday, October 29, 2014 10:43 AM
To: Daniel Schepler
Cc: CMake MailingList
Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

You can find the known compile features that can be detected at:
http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html

At the end of the compile-features manual page ( http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
) there is a section on how to mark a library as having conditional support on C++11 features.


On Wed, Oct 29, 2014 at 12:58 PM, Daniel Schepler <dschepler at scalable-networks.com> wrote:
> Where would I find the list of available C++ language features?  For instance, I would suppose there's one for "auto", one for move constructors/assignment operators, and one for "= delete" of default constructors/destructors et al.  These are probably the ones we'd be most interested in here, for the moment.  (Though with our requirements to support older C++ compilers, we might not actually be able to use auto, as the fallback would need the full type anyway.)  Also, is there a portability macro provided for the "= delete" feature?
>
> Also, how would I mark a target so that it activates C++11 features if available, but falls back to old C++ if not?  I do see the section on detecting compiler features, but it's not clear to me how exactly how I'd make the target use CXX_STANDARD 11 only if available.
> --
> Daniel
>
> --
>
> 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


From DLRdave at aol.com  Wed Oct 29 14:38:22 2014
From: DLRdave at aol.com (David Cole)
Date: Wed, 29 Oct 2014 14:38:22 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D398A@SNTMAIL01.snt.loc>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>
 <CAFzjYVq_rGhp5yd7GDwT8dp5cA42zPUEbGPAxU4cNTj4n7WXPQ@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D398A@SNTMAIL01.snt.loc>
Message-ID: <CAKME8fG2Ps1uu8LXvzYLwWPvxabxPPzOgVnQiUG0LimO_TjVSg@mail.gmail.com>

I think your question about CXX_STANDARD is answered in the CXX_STANDARD
docs:
http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html

If you MUST have it, you can set this property to ON:
http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD_REQUIRED.html

(Although I've not used it myself -- not sure what happens if the compiler
does not support the standard. Hopefully, an error at CMake time... try it
and let us know if it works for you.)


HTH,
David C.


On Wed, Oct 29, 2014 at 2:15 PM, Daniel Schepler <
dschepler at scalable-networks.com> wrote:

> (Whoops, accidentally sent this via private email before.)
>
> My question was about this part of the example:
>
> add_executable(consumer_with consumer_with.cpp)
> target_link_libraries(consumer_with foo)
> set_property(TARGET consumer_with CXX_STANDARD 11)
>
> add_executable(consumer_no consumer_no.cpp)
> target_link_libraries(consumer_no foo)
>
> The question is: how do I detect whether CXX_STANDARD 11 is available
> before running the "set_property(TARGET consumer_with CXX_STANDARD 11)"
> line?
> --
> Daniel
>
>
> -----Original Message-----
> From: Robert Maynard [mailto:robert.maynard at kitware.com]
> Sent: Wednesday, October 29, 2014 10:43 AM
> To: Daniel Schepler
> Cc: CMake MailingList
> Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
>
> You can find the known compile features that can be detected at:
> http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html
>
> At the end of the compile-features manual page (
> http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
> ) there is a section on how to mark a library as having conditional
> support on C++11 features.
>
>
> On Wed, Oct 29, 2014 at 12:58 PM, Daniel Schepler <
> dschepler at scalable-networks.com> wrote:
> > Where would I find the list of available C++ language features?  For
> instance, I would suppose there's one for "auto", one for move
> constructors/assignment operators, and one for "= delete" of default
> constructors/destructors et al.  These are probably the ones we'd be most
> interested in here, for the moment.  (Though with our requirements to
> support older C++ compilers, we might not actually be able to use auto, as
> the fallback would need the full type anyway.)  Also, is there a
> portability macro provided for the "= delete" feature?
> >
> > Also, how would I mark a target so that it activates C++11 features if
> available, but falls back to old C++ if not?  I do see the section on
> detecting compiler features, but it's not clear to me how exactly how I'd
> make the target use CXX_STANDARD 11 only if available.
> > --
> > Daniel
> >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141029/9132fab4/attachment-0001.html>

From andrew.st.lee at gmail.com  Wed Oct 29 16:18:03 2014
From: andrew.st.lee at gmail.com (Andrew Lee)
Date: Wed, 29 Oct 2014 20:18:03 +0000
Subject: [CMake] Xcode "CMake PreLink Rules" does not happen before the
	linker is called?
Message-ID: <CAO+3M5rT=tKPzexcJaWziPxHcFBuk=Y-xYe_eN6GjbpCO7ycQw@mail.gmail.com>

Hi,

We have successfully ported our build scripts to a cross-platform CMake
setup recently but there is just one thing we could not get right. We have
a PRELINK build phase that needs to execute before linking. This works for
generated Visual Studio projects and make scripts but not for Xcode
generated projects.
It appears that the generated Xcode "CMake PreLink Rules" build phase
happens after the linker is executed.

I had a look at the source file for the Xcode generator (
https://github.com/awakecoding/cmake/blob/master/Source/cmGlobalXCodeGenerator.cxx)
and Xcode IDE configuration. I suspect it's not possible to get Xcode to
run a pre-link command in the same manner as for the other generators on
other platforms.
Is this correct? I appreciate if somebody can point me in the right
direction.

Cheers,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141029/114b5004/attachment.html>

From dschepler at scalable-networks.com  Wed Oct 29 16:52:02 2014
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Wed, 29 Oct 2014 20:52:02 +0000
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
In-Reply-To: <CAKME8fG2Ps1uu8LXvzYLwWPvxabxPPzOgVnQiUG0LimO_TjVSg@mail.gmail.com>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>
 <CAFzjYVq_rGhp5yd7GDwT8dp5cA42zPUEbGPAxU4cNTj4n7WXPQ@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D398A@SNTMAIL01.snt.loc>
 <CAKME8fG2Ps1uu8LXvzYLwWPvxabxPPzOgVnQiUG0LimO_TjVSg@mail.gmail.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D3AB5@SNTMAIL01.snt.loc>

Thanks for the pointers, that does answer my question.  I would just set CXX_STANDARD to 11 and leave CXX_STANDARD_REQUIRED unset.
--
Daniel

From: David Cole [mailto:DLRdave at aol.com]
Sent: Wednesday, October 29, 2014 11:38 AM
To: Daniel Schepler
Cc: cmake at cmake.org
Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

I think your question about CXX_STANDARD is answered in the CXX_STANDARD docs:
http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html

If you MUST have it, you can set this property to ON:
http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD_REQUIRED.html

(Although I've not used it myself -- not sure what happens if the compiler does not support the standard. Hopefully, an error at CMake time... try it and let us know if it works for you.)


HTH,
David C.


On Wed, Oct 29, 2014 at 2:15 PM, Daniel Schepler <dschepler at scalable-networks.com<mailto:dschepler at scalable-networks.com>> wrote:
(Whoops, accidentally sent this via private email before.)

My question was about this part of the example:

add_executable(consumer_with consumer_with.cpp)
target_link_libraries(consumer_with foo)
set_property(TARGET consumer_with CXX_STANDARD 11)

add_executable(consumer_no consumer_no.cpp)
target_link_libraries(consumer_no foo)

The question is: how do I detect whether CXX_STANDARD 11 is available before running the "set_property(TARGET consumer_with CXX_STANDARD 11)" line?
--
Daniel


-----Original Message-----
From: Robert Maynard [mailto:robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>]
Sent: Wednesday, October 29, 2014 10:43 AM
To: Daniel Schepler
Cc: CMake MailingList
Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

You can find the known compile features that can be detected at:
http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html

At the end of the compile-features manual page ( http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
) there is a section on how to mark a library as having conditional support on C++11 features.


On Wed, Oct 29, 2014 at 12:58 PM, Daniel Schepler <dschepler at scalable-networks.com<mailto:dschepler at scalable-networks.com>> wrote:
> Where would I find the list of available C++ language features?  For instance, I would suppose there's one for "auto", one for move constructors/assignment operators, and one for "= delete" of default constructors/destructors et al.  These are probably the ones we'd be most interested in here, for the moment.  (Though with our requirements to support older C++ compilers, we might not actually be able to use auto, as the fallback would need the full type anyway.)  Also, is there a portability macro provided for the "= delete" feature?
>
> Also, how would I mark a target so that it activates C++11 features if available, but falls back to old C++ if not?  I do see the section on detecting compiler features, but it's not clear to me how exactly how I'd make the target use CXX_STANDARD 11 only if available.
> --
> Daniel
>
> --
>
> Powered by www.kitware.com<http://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<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141029/f13b016d/attachment.html>

From neal.kruis at bigladdersoftware.com  Wed Oct 29 17:35:24 2014
From: neal.kruis at bigladdersoftware.com (Neal Kruis)
Date: Wed, 29 Oct 2014 15:35:24 -0600
Subject: [CMake] CMake binary output directory for Visual Studio project
 with generated MinGW fortran projects
Message-ID: <CAOG8z52XuzzuR_0wN=JdA=ydc6yBRf6NjY=VxfmyE1h=nWuXOQ@mail.gmail.com>

CMakers,

I'm wondering if any of you can help me with a question that I've posted to
Stack Overflow:

http://stackoverflow.com/questions/26637673/how-to-set-the-cmake-binary-output-directory-for-visual-studio-project-with-gene

Essentially, I'm finding that the cmake_add_fortran_subdirectory function,
which uses MinGW, doesn't produce binaries in the same directory as the
master Visual Studio project. My question is about getting all of the
binaries created in the configuration directory (e.g., Debug, Release,
etc.).

Any ideas would be appreciated!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141029/96666061/attachment.html>

From d3ck0r at gmail.com  Thu Oct 30 00:59:58 2014
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 29 Oct 2014 21:59:58 -0700
Subject: [CMake] CMake binary output directory for Visual Studio project
 with generated MinGW fortran projects
In-Reply-To: <CAOG8z52XuzzuR_0wN=JdA=ydc6yBRf6NjY=VxfmyE1h=nWuXOQ@mail.gmail.com>
References: <CAOG8z52XuzzuR_0wN=JdA=ydc6yBRf6NjY=VxfmyE1h=nWuXOQ@mail.gmail.com>
Message-ID: <CAA2GJqXBqNJTXXAga=gGmbxb1n7wTwSzv7ADysyeK+yowmQkBw@mail.gmail.com>

when I asked a similar question years ago, someone said to make install
rules so everything would be copied together; works for combinations of
tools; works consistently for all generators then.  Install directory is
relative to the build directory if not an absolute path.
Have to set debug properties of visual studio project before running
instead of just immediately running; but once it's set you can just build
install and immediately run.

On Wed, Oct 29, 2014 at 2:35 PM, Neal Kruis <
neal.kruis at bigladdersoftware.com> wrote:

> CMakers,
>
> I'm wondering if any of you can help me with a question that I've posted
> to Stack Overflow:
>
>
> http://stackoverflow.com/questions/26637673/how-to-set-the-cmake-binary-output-directory-for-visual-studio-project-with-gene
>
> Essentially, I'm finding that the cmake_add_fortran_subdirectory function,
> which uses MinGW, doesn't produce binaries in the same directory as the
> master Visual Studio project. My question is about getting all of the
> binaries created in the configuration directory (e.g., Debug, Release,
> etc.).
>
> Any ideas would be appreciated!
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141029/544fed2b/attachment-0001.html>

From rcdailey.lists at gmail.com  Thu Oct 30 12:22:15 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 30 Oct 2014 11:22:15 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D3AB5@SNTMAIL01.snt.loc>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>
 <CAFzjYVq_rGhp5yd7GDwT8dp5cA42zPUEbGPAxU4cNTj4n7WXPQ@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D398A@SNTMAIL01.snt.loc>
 <CAKME8fG2Ps1uu8LXvzYLwWPvxabxPPzOgVnQiUG0LimO_TjVSg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D3AB5@SNTMAIL01.snt.loc>
Message-ID: <CAHd499Bupmb2+Q7STOSWL3Udy0vEBNtuXoOb45-7OcWXLm_XeQ@mail.gmail.com>

Why are quotations required for generator expressions using lists now?
Is there a technical reason for it? I think it's intuitive that it
worked without them.

It's never been clear in CMake when to use quotes or not outside of
the fact that if you're passing a parameter to a function with a space
in it, quotes will be necessary.

On Wed, Oct 29, 2014 at 3:52 PM, Daniel Schepler
<dschepler at scalable-networks.com> wrote:
> Thanks for the pointers, that does answer my question.  I would just set
> CXX_STANDARD to 11 and leave CXX_STANDARD_REQUIRED unset.
>
> --
>
> Daniel
>
>
>
> From: David Cole [mailto:DLRdave at aol.com]
> Sent: Wednesday, October 29, 2014 11:38 AM
> To: Daniel Schepler
> Cc: cmake at cmake.org
>
>
> Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
>
>
>
> I think your question about CXX_STANDARD is answered in the CXX_STANDARD
> docs:
>
> http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html
>
>
>
> If you MUST have it, you can set this property to ON:
>
> http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD_REQUIRED.html
>
>
>
> (Although I've not used it myself -- not sure what happens if the compiler
> does not support the standard. Hopefully, an error at CMake time... try it
> and let us know if it works for you.)
>
>
>
>
>
> HTH,
>
> David C.
>
>
>
>
>
> On Wed, Oct 29, 2014 at 2:15 PM, Daniel Schepler
> <dschepler at scalable-networks.com> wrote:
>
> (Whoops, accidentally sent this via private email before.)
>
> My question was about this part of the example:
>
> add_executable(consumer_with consumer_with.cpp)
> target_link_libraries(consumer_with foo)
> set_property(TARGET consumer_with CXX_STANDARD 11)
>
> add_executable(consumer_no consumer_no.cpp)
> target_link_libraries(consumer_no foo)
>
> The question is: how do I detect whether CXX_STANDARD 11 is available before
> running the "set_property(TARGET consumer_with CXX_STANDARD 11)" line?
> --
> Daniel
>
>
>
> -----Original Message-----
> From: Robert Maynard [mailto:robert.maynard at kitware.com]
> Sent: Wednesday, October 29, 2014 10:43 AM
> To: Daniel Schepler
> Cc: CMake MailingList
> Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
>
> You can find the known compile features that can be detected at:
> http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html
>
> At the end of the compile-features manual page (
> http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
> ) there is a section on how to mark a library as having conditional support
> on C++11 features.
>
>
> On Wed, Oct 29, 2014 at 12:58 PM, Daniel Schepler
> <dschepler at scalable-networks.com> wrote:
>> Where would I find the list of available C++ language features?  For
>> instance, I would suppose there's one for "auto", one for move
>> constructors/assignment operators, and one for "= delete" of default
>> constructors/destructors et al.  These are probably the ones we'd be most
>> interested in here, for the moment.  (Though with our requirements to
>> support older C++ compilers, we might not actually be able to use auto, as
>> the fallback would need the full type anyway.)  Also, is there a portability
>> macro provided for the "= delete" feature?
>>
>> Also, how would I mark a target so that it activates C++11 features if
>> available, but falls back to old C++ if not?  I do see the section on
>> detecting compiler features, but it's not clear to me how exactly how I'd
>> make the target use CXX_STANDARD 11 only if available.
>> --
>> Daniel
>>
>> --
>>
>> 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
>
>
>
>
> --
>
> 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

From brad.king at kitware.com  Thu Oct 30 13:28:06 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 30 Oct 2014 13:28:06 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
In-Reply-To: <CAHd499Bupmb2+Q7STOSWL3Udy0vEBNtuXoOb45-7OcWXLm_XeQ@mail.gmail.com>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D37C8@SNTMAIL01.snt.loc>
 <CAFzjYVq_rGhp5yd7GDwT8dp5cA42zPUEbGPAxU4cNTj4n7WXPQ@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D398A@SNTMAIL01.snt.loc>
 <CAKME8fG2Ps1uu8LXvzYLwWPvxabxPPzOgVnQiUG0LimO_TjVSg@mail.gmail.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D3AB5@SNTMAIL01.snt.loc>
 <CAHd499Bupmb2+Q7STOSWL3Udy0vEBNtuXoOb45-7OcWXLm_XeQ@mail.gmail.com>
Message-ID: <54527526.1020006@kitware.com>

On 10/30/2014 12:22 PM, Robert Dailey wrote:
> Why are quotations required for generator expressions using lists now?

It is not a new requirement.  This has always been the case.  It was
just that between 2.8.12 and 3.0 an idiosyncrasy of the implementation
changes accidentally removed the requirement specifically for expressions
given to target_link_libraries (to put in the LINK_LIBRARIES properties).
Quotes were still required in 3.0 for generator expressions with lists
in other contexts.  Dropping it for LINK_LIBRARIES was accidental.

Further development between 3.0 and 3.1 did some internal refactoring
and optimization that takes advantage of the requirement and therefore
restored it in the LINK_LIBRARIES case where it never should have been
dropped.

> Is there a technical reason for it? I think it's intuitive that it
> worked without them.

You need to pass the entire expression with the list it contains as
a single argument to whatever command you're calling.  Otherwise the
unquoted argument will divide the expression on the ;s in it and
pass them as separate arguments to the command.  Then no one argument
is a complete expression.  The 3.1 release notes show an example of
this.

-Brad


From irwin at beluga.phys.uvic.ca  Thu Oct 30 17:07:20 2014
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 30 Oct 2014 14:07:20 -0700 (PDT)
Subject: [CMake] What generator(s) should be used for MinGW-w64?
Message-ID: <alpine.DEB.2.02.1410301324060.15114@enira.zlyna.ubzr>

PLplot developers and users have had a lot of success with MinGW alone
(using the "MinGW Makefiles" generator) or the combination of MinGW
and MSYS (using the "MSYS Makefiles" generator).  However, there is
another gcc compiler out there for Windows called MinGW-w64 that one
of our users would like to use, but I don't know exactly what to
advise him, and so I hope somebody here has had some practical CMake
experience with the MinGW-w64 compiler and could help with such advice.

Here is what I know so far:

MinGW-w64 is a completely separate project than MinGW with
different developers, install procedure, etc.  I have read distributed
binary versions of MSYS are all built with MSYS so are not
ABI-compatible with MinGW-w64, and I will proceed on that assumption.
Furthermore, there is an MSYS2 project (a completely independent
project from MSYS, see <http://sourceforge.net/p/msys2/wiki/Home/>)
which _is_ API-compatible with MinGW-w64 since it is built with that
compiler.

The combination of MinGW-w64 and MSYS2 seems fairly well documented
(see the above wiki reference).  It appears for example, this
combination is a "lite" version of Cygwin.  So I assume
that if MSYS2 is on the PATH, then the "Unix Makefiles" generator
is the correct one to use for this case (since that is the
recommended generator for Cygwin), but I would like confirmation
of that if someone here has experience with the combination
of MinGW-w64 and MSYS2.

Another possible case is when neither MSYS nor MSYS2 are on the PATH.
Is the "MinGW Makefiles" generator the correct one to use with the
MinGW-w64 compiler for this case?  My guess is that might work if the
MinGW-w64 binary package includes some form of make command (similar
to the MinGW mingw32-make.exe command), but I am having trouble
finding a binary package for MinGW-w64 so I have no idea whether
binary packages exist for MinGW-w64, and if so whether they include
some form of make command.  So if somebody here has some experience
with the MinGW-w64 without MSYS2, I would appreciate your comments.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From ewmailing at gmail.com  Thu Oct 30 19:19:11 2014
From: ewmailing at gmail.com (Eric Wing)
Date: Thu, 30 Oct 2014 16:19:11 -0700
Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready
	for testing!
In-Reply-To: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
Message-ID: <CA+Q62MBxFB9We9Jrh=Lf2c+JLwE7ueXAfak3qoaM8+8p6oz6AQ@mail.gmail.com>

Just curious, are the new WinRT changes the same exact changes from CMakeMS?

And if the CMakeMS people are listening, I just want to say you guys
did a terrific job!

Thanks,
Eric

From thehesiod at hotmail.com  Thu Oct 30 21:04:18 2014
From: thehesiod at hotmail.com (thehesiod)
Date: Thu, 30 Oct 2014 18:04:18 -0700 (PDT)
Subject: [CMake] Xcode generator per architecture setting
In-Reply-To: <ABDFA5D59E19E44C8E1B3138320F9AAACD079E64@LAX-EXMB02.dts.local>
References: <ABDFA5D59E19E44C8E1B3138320F9AAACD079E64@LAX-EXMB02.dts.local>
Message-ID: <1414717457988-7588883.post@n2.nabble.com>

Bin Chen wrote
> Hi,
> 
> For Xcode generator, is it possible to specify CFLAGS for each
> architecture, e.g. i386 and x86_64? Thanks!
> 
> Best regards,
> Bin Chen

I used to set set_target_properties(${DRM_TARGET_NAME} PROPERTIES
XCODE_ATTRIBUTE_OTHER_CFLAGS[arch=${_NATIVE_ARCH}] "${MY_OTHER_CFLAGS}")

and noticed that this seemed to take precedence over the CMAKE_C_FLAGS,
however it seems to have stopped working in XCode 6.1, still investigating.

I wish there were a better way.



--
View this message in context: http://cmake.3232098.n2.nabble.com/Xcode-generator-per-architecture-setting-tp7588687p7588883.html
Sent from the CMake mailing list archive at Nabble.com.

From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de  Fri Oct 31 04:14:13 2014
From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian)
Date: Fri, 31 Oct 2014 08:14:13 +0000
Subject: [CMake] What generator(s) should be used for MinGW-w64?
In-Reply-To: <alpine.DEB.2.02.1410301324060.15114@enira.zlyna.ubzr>
References: <alpine.DEB.2.02.1410301324060.15114@enira.zlyna.ubzr>
Message-ID: <8D981219EEA621479C112DA9BDC39A8E2586E105@EXMBS1.ad.igd.fraunhofer.de>

I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The main difference between MinGW-w64 and the original MinGW is that it is far more up to date.
Binary packages can be found here: http://mingw-w64.sourceforge.net/download.php
I generally recommend using the mingw-builds binary packages

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de


-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alan W. Irwin
Sent: Thursday, October 30, 2014 22:07
To: cmake at cmake.org
Subject: [CMake] What generator(s) should be used for MinGW-w64?

PLplot developers and users have had a lot of success with MinGW alone (using the "MinGW Makefiles" generator) or the combination of MinGW and MSYS (using the "MSYS Makefiles" generator).  However, there is another gcc compiler out there for Windows called MinGW-w64 that one of our users would like to use, but I don't know exactly what to advise him, and so I hope somebody here has had some practical CMake experience with the MinGW-w64 compiler and could help with such advice.

Here is what I know so far:

MinGW-w64 is a completely separate project than MinGW with different developers, install procedure, etc.  I have read distributed binary versions of MSYS are all built with MSYS so are not ABI-compatible with MinGW-w64, and I will proceed on that assumption.
Furthermore, there is an MSYS2 project (a completely independent project from MSYS, see <http://sourceforge.net/p/msys2/wiki/Home/>)
which _is_ API-compatible with MinGW-w64 since it is built with that compiler.

The combination of MinGW-w64 and MSYS2 seems fairly well documented (see the above wiki reference).  It appears for example, this combination is a "lite" version of Cygwin.  So I assume that if MSYS2 is on the PATH, then the "Unix Makefiles" generator is the correct one to use for this case (since that is the recommended generator for Cygwin), but I would like confirmation of that if someone here has experience with the combination of MinGW-w64 and MSYS2.

Another possible case is when neither MSYS nor MSYS2 are on the PATH.
Is the "MinGW Makefiles" generator the correct one to use with the
MinGW-w64 compiler for this case?  My guess is that might work if the
MinGW-w64 binary package includes some form of make command (similar to the MinGW mingw32-make.exe command), but I am having trouble finding a binary package for MinGW-w64 so I have no idea whether binary packages exist for MinGW-w64, and if so whether they include some form of make command.  So if somebody here has some experience with the MinGW-w64 without MSYS2, I would appreciate your comments.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
-- 

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

From irwin at beluga.phys.uvic.ca  Fri Oct 31 06:18:42 2014
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 31 Oct 2014 03:18:42 -0700 (PDT)
Subject: [CMake] What generator(s) should be used for MinGW-w64?
In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E2586E105@EXMBS1.ad.igd.fraunhofer.de>
References: <alpine.DEB.2.02.1410301324060.15114@enira.zlyna.ubzr>
 <8D981219EEA621479C112DA9BDC39A8E2586E105@EXMBS1.ad.igd.fraunhofer.de>
Message-ID: <alpine.DEB.2.02.1410310312460.15114@enira.zlyna.ubzr>

On 2014-10-31 08:14-0000 Mueller-Roemer, Johannes Sebastian wrote:

> I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The main difference between MinGW-w64 and the original MinGW is that it is far more up to date.
> Binary packages can be found here: http://mingw-w64.sourceforge.net/download.php
> I generally recommend using the mingw-builds binary packages

Hi Johannes:

Thanks for that useful information.
What is the name of the make command you use, and is it part of the
mingw-builds binary packages that you recommend?

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de  Fri Oct 31 06:47:45 2014
From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian)
Date: Fri, 31 Oct 2014 10:47:45 +0000
Subject: [CMake] What generator(s) should be used for MinGW-w64?
In-Reply-To: <alpine.DEB.2.02.1410310312460.15114@enira.zlyna.ubzr>
References: <alpine.DEB.2.02.1410301324060.15114@enira.zlyna.ubzr>
 <8D981219EEA621479C112DA9BDC39A8E2586E105@EXMBS1.ad.igd.fraunhofer.de>
 <alpine.DEB.2.02.1410310312460.15114@enira.zlyna.ubzr>
Message-ID: <8D981219EEA621479C112DA9BDC39A8E2586E201@EXMBS1.ad.igd.fraunhofer.de>

mingw32-make, and yes it's included (I recently started using ninja as well, but that isn't included, and has some limitations with cmake)

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de

-----Original Message-----
From: Alan W. Irwin [mailto:irwin at beluga.phys.uvic.ca] 
Sent: Friday, October 31, 2014 11:19
To: Mueller-Roemer, Johannes Sebastian
Cc: cmake at cmake.org
Subject: RE: [CMake] What generator(s) should be used for MinGW-w64?

On 2014-10-31 08:14-0000 Mueller-Roemer, Johannes Sebastian wrote:

> I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The main difference between MinGW-w64 and the original MinGW is that it is far more up to date.
> Binary packages can be found here: 
> http://mingw-w64.sourceforge.net/download.php
> I generally recommend using the mingw-builds binary packages

Hi Johannes:

Thanks for that useful information.
What is the name of the make command you use, and is it part of the mingw-builds binary packages that you recommend?

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From brad.king at kitware.com  Fri Oct 31 11:25:59 2014
From: brad.king at kitware.com (Brad King)
Date: Fri, 31 Oct 2014 11:25:59 -0400
Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready
 for testing!
In-Reply-To: <CA+Q62MBxFB9We9Jrh=Lf2c+JLwE7ueXAfak3qoaM8+8p6oz6AQ@mail.gmail.com>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <CA+Q62MBxFB9We9Jrh=Lf2c+JLwE7ueXAfak3qoaM8+8p6oz6AQ@mail.gmail.com>
Message-ID: <5453AA07.1000104@kitware.com>

On 10/30/2014 07:19 PM, Eric Wing wrote:
> Just curious, are the new WinRT changes the same exact changes from CMakeMS?

Yes.  After prototyping the changes in CMakeMS they worked with us
to contribute the functionality upstream.

-Brad


From Gilles.Khouzam at microsoft.com  Fri Oct 31 11:53:59 2014
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Fri, 31 Oct 2014 15:53:59 +0000
Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready
 for testing!
In-Reply-To: <5453AA07.1000104@kitware.com>
References: <CAFzjYVoknNR_rjEQEYTo7-tVemJ+eiRLmLSc634ZDNLy7VBZpg@mail.gmail.com>
 <CA+Q62MBxFB9We9Jrh=Lf2c+JLwE7ueXAfak3qoaM8+8p6oz6AQ@mail.gmail.com>,
 <5453AA07.1000104@kitware.com>
Message-ID: <fae39fa3ca164d7db9f716512ac384d3@CY1PR0301MB0713.namprd03.prod.outlook.com>

We actually have a couple if extra changes that are not fully ready to be pushed upstream yet.

~Gilles
Sent from my Windows Phone
________________________________
From: Brad King<mailto:brad.king at kitware.com>
Sent: ?10/?31/?2014 8:26
To: Eric Wing<mailto:ewmailing at gmail.com>
Cc: Robert Maynard<mailto:robert.maynard at kitware.com>; CMake Developers<mailto:cmake-developers at cmake.org>; CMake MailingList<mailto:cmake at cmake.org>; Gilles Khouzam<mailto:Gilles.Khouzam at microsoft.com>
Subject: Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

On 10/30/2014 07:19 PM, Eric Wing wrote:
> Just curious, are the new WinRT changes the same exact changes from CMakeMS?

Yes.  After prototyping the changes in CMakeMS they worked with us
to contribute the functionality upstream.

-Brad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141031/af873368/attachment.html>

From boxerab at gmail.com  Fri Oct 31 14:20:00 2014
From: boxerab at gmail.com (Aaron Boxer)
Date: Fri, 31 Oct 2014 14:20:00 -0400
Subject: [CMake] Loading Plugins
Message-ID: <CAK8GPyADR6iUGPuX+MgmSHsbvCUPCG91mSMiGxr+kvSSVO6pgw@mail.gmail.com>

Hello!

I have a C CMake project, and I would like to add the following feature:

1) define an interface for a second dynamic library
2) look in a specified folder at runtime, and try to load this library
3) if loading fails, then get notified of this fact, so that I can use
statically linked fall-back routines in the parent project.

Is this possible?  Any ideas or advice would be greatly appreciated.

Thanks,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141031/3ad18ff9/attachment.html>

From blowekamp at mail.nih.gov  Fri Oct 31 14:24:16 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 31 Oct 2014 14:24:16 -0400
Subject: [CMake] Loading Plugins
In-Reply-To: <CAK8GPyADR6iUGPuX+MgmSHsbvCUPCG91mSMiGxr+kvSSVO6pgw@mail.gmail.com>
References: <CAK8GPyADR6iUGPuX+MgmSHsbvCUPCG91mSMiGxr+kvSSVO6pgw@mail.gmail.com>
Message-ID: <55F78FF2-8094-4645-B463-29C5B69C3BFE@mail.nih.gov>

Hello,

Yes, this can be done with ITK's object factory mechanism. I would study how it's done with ITK's ImageIO plugin mechanism[1], then figure out how to adapt the same framework for your interface.

Brad

[1] http://www.itk.org/Wiki/Plugin_IO_mechanisms

    

On Oct 31, 2014, at 2:20 PM, Aaron Boxer <boxerab at gmail.com> wrote:

> Hello!
> 
> I have a C CMake project, and I would like to add the following feature:
> 
> 1) define an interface for a second dynamic library 
> 2) look in a specified folder at runtime, and try to load this library
> 3) if loading fails, then get notified of this fact, so that I can use statically linked fall-back routines in the parent project.
> 
> Is this possible?  Any ideas or advice would be greatly appreciated.
> 
> Thanks,
> Aaron
> 
> 
> -- 
> 
> 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


From rcdailey.lists at gmail.com  Fri Oct 31 15:11:23 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 31 Oct 2014 14:11:23 -0500
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
Message-ID: <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>

I like this idea but it doesn't seem like it will work for targets
with multiple DLLs... for example boost. It has several DLLs. I don't
want to define 1 target for each DLL either. Sometimes that doesn't
make sense.

On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
<post at hendrik-sattler.de> wrote:
> Am 2014-10-28 18:25, schrieb Robert Dailey:
>>
>> I have a third party library like OpenSSL prebuilt for each platform
>> and in my own structure in version control. I have a CMake script that
>> creates an INTERFACE library target for it. I setup the include
>> directories and link targets. However, I don't see a way to configure
>> DLLs in the interface library target. How would you do this, and what
>> would CMake do to these targets to make sure they are copied to the
>> output directory of the executable I run from Visual Studio for
>> debugging?
>
>
> I have this for ZLib:
> if ( ZLIB_FOUND )
>   if ( WIN32 )
>     get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
>     get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE )
>     get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
>     find_file ( ZLIB_DLL
> "${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
>       HINTS
>         "${ZLIB_LIBDIR_BASE}"
>       PATH_SUFFIXES
>         bin
>       NO_DEFAULT_PATH
>     )
>     mark_as_advanced ( ZLIB_DLL )
>     if ( ZLIB_DLL )
>       add_library ( zlib SHARED IMPORTED GLOBAL )
>       set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB "${ZLIB_LIBRARY}"
> )
>       set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_DLL}" )
>     else ( ZLIB_DLL )
>       add_library ( zlib STATIC IMPORTED GLOBAL )
>       set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
> "${ZLIB_LIBRARY}" )
>     endif ( ZLIB_DLL )
>   else( WIN32 )
>     add_library ( zlib UNKNOWN IMPORTED GLOBAL )
>     set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_LIBRARY}"
> )
>   endif( WIN32 )
>   set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
>     "${ZLIB_INCLUDE_DIR}"
>   )
>
>   set ( ZLIB_LIBRARIES zlib )
>   set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
> endif ( ZLIB_FOUND )
>
> The .lib goes into IMPORTED_IMPLIB and the .dll goes into IMPORTED_LOCATION.
> The way to find the .dll from the location of the .lib might differ for
> different libraries.
> For ZLib, the base name is the same.
>
> Later, you can use this imported target:
>   add_custom_command ( TARGET myTarget POST_BUILD
>     COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib>
> $<TARGET_FILE_DIR:myTarget>
>   )
> Now, zlib.dll is in the same directory as myTarget.dll.
>
> HS
>
>> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
>> <post at hendrik-sattler.de> wrote:
>>>
>>> Hi,
>>>
>>> you can use generator expression in a post build rule to copy the dll
>>> file to the same target dir as the target you link it with. The easiest way
>>> to do this is to properly define all 3rd party libraries as imported targets
>>> that contains both, the lib and the dll file.
>>> Sadly, the FindQt4 on Windows doesn't do this and thus make life harder
>>> than needed. CMake configuration files should always do this right.
>>>
>>> OTOH, you could also write a wrapper batch file or change VS properties
>>> to modify PATH to include all libraries before the regular path.
>>>
>>> HS
>>>
>>>
>>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey
>>> <rcdailey.lists at gmail.com>:
>>>>
>>>> This actually used to be a very difficult problem to solve. However,
>>>> to debug in visual studio it's essential.
>>>>
>>>> If I have DLLs located in third party directories OR from targets that
>>>> I depend on, those must all be copied to the directory of the
>>>> executable I'm debugging in order for those DLLs to be found and
>>>> loaded.
>>>>
>>>> Using CMake 3.0.2, I hope this task is simpler, especially with the
>>>> introduction of a nice suite of generator expressions. Can anyone
>>>> recommend a good way to do this?
>>>
>>>
>> --
>>
>> 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

From mike.jackson at bluequartz.net  Fri Oct 31 15:28:00 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Fri, 31 Oct 2014 15:28:00 -0400
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
Message-ID: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>

It sucks, but I do that with Qt's libraries. One target for each library. I prefix the target with "ZZ_" so that in IDEs like Visual Studio and Xcode those targets fall to the bottom of the list. I also group them in folders if Visual Studio will allow it. I use the "copy if different" argument to the CMake command for the copy. Seems to work.

Mike Jackson

On Oct 31, 2014, at 3:11 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:

> I like this idea but it doesn't seem like it will work for targets
> with multiple DLLs... for example boost. It has several DLLs. I don't
> want to define 1 target for each DLL either. Sometimes that doesn't
> make sense.
> 
> On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
> <post at hendrik-sattler.de> wrote:
>> Am 2014-10-28 18:25, schrieb Robert Dailey:
>>> 
>>> I have a third party library like OpenSSL prebuilt for each platform
>>> and in my own structure in version control. I have a CMake script that
>>> creates an INTERFACE library target for it. I setup the include
>>> directories and link targets. However, I don't see a way to configure
>>> DLLs in the interface library target. How would you do this, and what
>>> would CMake do to these targets to make sure they are copied to the
>>> output directory of the executable I run from Visual Studio for
>>> debugging?
>> 
>> 
>> I have this for ZLib:
>> if ( ZLIB_FOUND )
>>  if ( WIN32 )
>>    get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
>>    get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE )
>>    get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
>>    find_file ( ZLIB_DLL
>> "${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
>>      HINTS
>>        "${ZLIB_LIBDIR_BASE}"
>>      PATH_SUFFIXES
>>        bin
>>      NO_DEFAULT_PATH
>>    )
>>    mark_as_advanced ( ZLIB_DLL )
>>    if ( ZLIB_DLL )
>>      add_library ( zlib SHARED IMPORTED GLOBAL )
>>      set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB "${ZLIB_LIBRARY}"
>> )
>>      set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_DLL}" )
>>    else ( ZLIB_DLL )
>>      add_library ( zlib STATIC IMPORTED GLOBAL )
>>      set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>> "${ZLIB_LIBRARY}" )
>>    endif ( ZLIB_DLL )
>>  else( WIN32 )
>>    add_library ( zlib UNKNOWN IMPORTED GLOBAL )
>>    set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_LIBRARY}"
>> )
>>  endif( WIN32 )
>>  set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
>>    "${ZLIB_INCLUDE_DIR}"
>>  )
>> 
>>  set ( ZLIB_LIBRARIES zlib )
>>  set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
>> endif ( ZLIB_FOUND )
>> 
>> The .lib goes into IMPORTED_IMPLIB and the .dll goes into IMPORTED_LOCATION.
>> The way to find the .dll from the location of the .lib might differ for
>> different libraries.
>> For ZLib, the base name is the same.
>> 
>> Later, you can use this imported target:
>>  add_custom_command ( TARGET myTarget POST_BUILD
>>    COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib>
>> $<TARGET_FILE_DIR:myTarget>
>>  )
>> Now, zlib.dll is in the same directory as myTarget.dll.
>> 
>> HS
>> 
>>> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
>>> <post at hendrik-sattler.de> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> you can use generator expression in a post build rule to copy the dll
>>>> file to the same target dir as the target you link it with. The easiest way
>>>> to do this is to properly define all 3rd party libraries as imported targets
>>>> that contains both, the lib and the dll file.
>>>> Sadly, the FindQt4 on Windows doesn't do this and thus make life harder
>>>> than needed. CMake configuration files should always do this right.
>>>> 
>>>> OTOH, you could also write a wrapper batch file or change VS properties
>>>> to modify PATH to include all libraries before the regular path.
>>>> 
>>>> HS
>>>> 
>>>> 
>>>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey
>>>> <rcdailey.lists at gmail.com>:
>>>>> 
>>>>> This actually used to be a very difficult problem to solve. However,
>>>>> to debug in visual studio it's essential.
>>>>> 
>>>>> If I have DLLs located in third party directories OR from targets that
>>>>> I depend on, those must all be copied to the directory of the
>>>>> executable I'm debugging in order for those DLLs to be found and
>>>>> loaded.
>>>>> 
>>>>> Using CMake 3.0.2, I hope this task is simpler, especially with the
>>>>> introduction of a nice suite of generator expressions. Can anyone
>>>>> recommend a good way to do this?
>>>> 
>>>> 
>>> --
>>> 
>>> 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
> -- 
> 
> 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


From rcdailey.lists at gmail.com  Fri Oct 31 15:37:18 2014
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 31 Oct 2014 14:37:18 -0500
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
Message-ID: <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>

If it were only a matter of style / visual annoyance, I wouldn't mind.
However it complicates dependency management when you have to specify
"ZZ_QT_LIB1", "ZZ_QT_LIB2", etc... instead of just "QT" when calling
target_link_libraries().

Unless you do it differently...

On Fri, Oct 31, 2014 at 2:28 PM, Michael Jackson
<mike.jackson at bluequartz.net> wrote:
> It sucks, but I do that with Qt's libraries. One target for each library. I prefix the target with "ZZ_" so that in IDEs like Visual Studio and Xcode those targets fall to the bottom of the list. I also group them in folders if Visual Studio will allow it. I use the "copy if different" argument to the CMake command for the copy. Seems to work.
>
> Mike Jackson
>
> On Oct 31, 2014, at 3:11 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>
>> I like this idea but it doesn't seem like it will work for targets
>> with multiple DLLs... for example boost. It has several DLLs. I don't
>> want to define 1 target for each DLL either. Sometimes that doesn't
>> make sense.
>>
>> On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
>> <post at hendrik-sattler.de> wrote:
>>> Am 2014-10-28 18:25, schrieb Robert Dailey:
>>>>
>>>> I have a third party library like OpenSSL prebuilt for each platform
>>>> and in my own structure in version control. I have a CMake script that
>>>> creates an INTERFACE library target for it. I setup the include
>>>> directories and link targets. However, I don't see a way to configure
>>>> DLLs in the interface library target. How would you do this, and what
>>>> would CMake do to these targets to make sure they are copied to the
>>>> output directory of the executable I run from Visual Studio for
>>>> debugging?
>>>
>>>
>>> I have this for ZLib:
>>> if ( ZLIB_FOUND )
>>>  if ( WIN32 )
>>>    get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
>>>    get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE )
>>>    get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
>>>    find_file ( ZLIB_DLL
>>> "${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
>>>      HINTS
>>>        "${ZLIB_LIBDIR_BASE}"
>>>      PATH_SUFFIXES
>>>        bin
>>>      NO_DEFAULT_PATH
>>>    )
>>>    mark_as_advanced ( ZLIB_DLL )
>>>    if ( ZLIB_DLL )
>>>      add_library ( zlib SHARED IMPORTED GLOBAL )
>>>      set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB "${ZLIB_LIBRARY}"
>>> )
>>>      set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_DLL}" )
>>>    else ( ZLIB_DLL )
>>>      add_library ( zlib STATIC IMPORTED GLOBAL )
>>>      set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>>> "${ZLIB_LIBRARY}" )
>>>    endif ( ZLIB_DLL )
>>>  else( WIN32 )
>>>    add_library ( zlib UNKNOWN IMPORTED GLOBAL )
>>>    set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_LIBRARY}"
>>> )
>>>  endif( WIN32 )
>>>  set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
>>>    "${ZLIB_INCLUDE_DIR}"
>>>  )
>>>
>>>  set ( ZLIB_LIBRARIES zlib )
>>>  set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
>>> endif ( ZLIB_FOUND )
>>>
>>> The .lib goes into IMPORTED_IMPLIB and the .dll goes into IMPORTED_LOCATION.
>>> The way to find the .dll from the location of the .lib might differ for
>>> different libraries.
>>> For ZLib, the base name is the same.
>>>
>>> Later, you can use this imported target:
>>>  add_custom_command ( TARGET myTarget POST_BUILD
>>>    COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib>
>>> $<TARGET_FILE_DIR:myTarget>
>>>  )
>>> Now, zlib.dll is in the same directory as myTarget.dll.
>>>
>>> HS
>>>
>>>> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
>>>> <post at hendrik-sattler.de> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> you can use generator expression in a post build rule to copy the dll
>>>>> file to the same target dir as the target you link it with. The easiest way
>>>>> to do this is to properly define all 3rd party libraries as imported targets
>>>>> that contains both, the lib and the dll file.
>>>>> Sadly, the FindQt4 on Windows doesn't do this and thus make life harder
>>>>> than needed. CMake configuration files should always do this right.
>>>>>
>>>>> OTOH, you could also write a wrapper batch file or change VS properties
>>>>> to modify PATH to include all libraries before the regular path.
>>>>>
>>>>> HS
>>>>>
>>>>>
>>>>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey
>>>>> <rcdailey.lists at gmail.com>:
>>>>>>
>>>>>> This actually used to be a very difficult problem to solve. However,
>>>>>> to debug in visual studio it's essential.
>>>>>>
>>>>>> If I have DLLs located in third party directories OR from targets that
>>>>>> I depend on, those must all be copied to the directory of the
>>>>>> executable I'm debugging in order for those DLLs to be found and
>>>>>> loaded.
>>>>>>
>>>>>> Using CMake 3.0.2, I hope this task is simpler, especially with the
>>>>>> introduction of a nice suite of generator expressions. Can anyone
>>>>>> recommend a good way to do this?
>>>>>
>>>>>
>>>> --
>>>>
>>>> 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
>> --
>>
>> 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

From mike.jackson at bluequartz.net  Fri Oct 31 15:42:44 2014
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Fri, 31 Oct 2014 15:42:44 -0400
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
 <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
Message-ID: <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>

Never said it was pretty, but here is the code I use for Qt4 based projects. I think I had to revamp a lot of this for Qt5. I call it like so:

CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork")


# --------------------------------------------------------------------
#-- Copy all the Qt4 dependent DLLs into the current build directory so that
#-- one can debug an application or library that depends on Qt4 libraries.
#-- This macro is really intended for Windows Builds because windows libraries
#-- do not have any type of rpath or install_name encoded in the libraries so
#-- the least intrusive way to deal with the PATH issues is to just copy all
#-- the dependend DLL libraries into the build directory. Note that this is
#-- NOT needed for static libraries.
macro(CMP_COPY_QT4_RUNTIME_LIBRARIES QTLIBLIST)
    # message(STATUS "CMP_COPY_QT4_RUNTIME_LIBRARIES")
    set(SUPPORT_LIB_OPTION 1)
    if(MSVC_IDE)
      set(SUPPORT_LIB_OPTION 0)
    elseif(APPLE) # Apple systems do NOT need this so just skip this entirely
      set(SUPPORT_LIB_OPTION 2)
    elseif(UNIX AND NOT MSVC)
      set(SUPPORT_LIB_OPTION 3)
    endif()

    if(NOT DEFINED QT_QMAKE_EXECUTABLE)
      message(FATAL_ERROR "Qt is REQUIRED to use this Function or macro. Make sure Qt is found on your system.")
    endif()

    if(SUPPORT_LIB_OPTION EQUAL 0)
      set(TYPE "d")
      FOREACH(qtlib ${QTLIBLIST})
        GET_FILENAME_COMPONENT(QT_DLL_PATH_tmp ${QT_QMAKE_EXECUTABLE} PATH)
        # message(STATUS "CMAKE_GENERATOR: ${CMAKE_GENERATOR}")
        # We need to copy both the Debug and Release versions of the libraries into their respective
        # subfolders for Visual Studio builds
        add_custom_target(ZZ_${qtlib}-Debug-Copy ALL
                            COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QT_DLL_PATH_tmp}/${qtlib}${TYPE}4.dll
                            ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Debug/
                            COMMENT "Copying ${qtlib}${TYPE}4.dll to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Debug/")
        set_target_properties(ZZ_${qtlib}-Debug-Copy PROPERTIES FOLDER ZZ_COPY_FILES)
      #   message(STATUS "Generating Copy Rule for Qt Release DLL Library ${QT_DLL_PATH_tmp}/${qtlib}d4.dll")
        add_custom_target(ZZ_${qtlib}-Release-Copy ALL
                            COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QT_DLL_PATH_tmp}/${qtlib}4.dll
                            ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Release/
                            COMMENT "Copying ${qtlib}4.dll to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Release/")
        set_target_properties(ZZ_${qtlib}-Release-Copy PROPERTIES FOLDER ZZ_COPY_FILES)

      ENDFOREACH(qtlib)
    elseif(SUPPORT_LIB_OPTION EQUAL 1)
      set(TYPE "")
      if( ${CMAKE_BUILD_TYPE} STREQUAL "Debug")
          set(TYPE "d")
      endif()
      FOREACH(qtlib ${QTLIBLIST})
          GET_FILENAME_COMPONENT(QT_DLL_PATH_tmp ${QT_QMAKE_EXECUTABLE} PATH)
          #message(STATUS "Generating Copy Rule for Qt DLL: ${QT_DLL_PATH_tmp}/${qtlib}d4.dll")
          add_custom_target(ZZ_${qtlib}-Debug-Copy ALL
                      COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QT_DLL_PATH_tmp}/${qtlib}${TYPE}4.dll
                      ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/
                      COMMENT "Copying ${qtlib}${TYPE}4.dll to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/")
          set_target_properties(ZZ_${qtlib}-Debug-Copy PROPERTIES FOLDER ZZ_COPY_FILES)
      ENDFOREACH(qtlib)
    endif()
endmacro()


On Oct 31, 2014, at 3:37 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:

> If it were only a matter of style / visual annoyance, I wouldn't mind.
> However it complicates dependency management when you have to specify
> "ZZ_QT_LIB1", "ZZ_QT_LIB2", etc... instead of just "QT" when calling
> target_link_libraries().
> 
> Unless you do it differently...
> 
> On Fri, Oct 31, 2014 at 2:28 PM, Michael Jackson
> <mike.jackson at bluequartz.net> wrote:
>> It sucks, but I do that with Qt's libraries. One target for each library. I prefix the target with "ZZ_" so that in IDEs like Visual Studio and Xcode those targets fall to the bottom of the list. I also group them in folders if Visual Studio will allow it. I use the "copy if different" argument to the CMake command for the copy. Seems to work.
>> 
>> Mike Jackson
>> 
>> On Oct 31, 2014, at 3:11 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>> 
>>> I like this idea but it doesn't seem like it will work for targets
>>> with multiple DLLs... for example boost. It has several DLLs. I don't
>>> want to define 1 target for each DLL either. Sometimes that doesn't
>>> make sense.
>>> 
>>> On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
>>> <post at hendrik-sattler.de> wrote:
>>>> Am 2014-10-28 18:25, schrieb Robert Dailey:
>>>>> 
>>>>> I have a third party library like OpenSSL prebuilt for each platform
>>>>> and in my own structure in version control. I have a CMake script that
>>>>> creates an INTERFACE library target for it. I setup the include
>>>>> directories and link targets. However, I don't see a way to configure
>>>>> DLLs in the interface library target. How would you do this, and what
>>>>> would CMake do to these targets to make sure they are copied to the
>>>>> output directory of the executable I run from Visual Studio for
>>>>> debugging?
>>>> 
>>>> 
>>>> I have this for ZLib:
>>>> if ( ZLIB_FOUND )
>>>> if ( WIN32 )
>>>>   get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
>>>>   get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE )
>>>>   get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
>>>>   find_file ( ZLIB_DLL
>>>> "${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
>>>>     HINTS
>>>>       "${ZLIB_LIBDIR_BASE}"
>>>>     PATH_SUFFIXES
>>>>       bin
>>>>     NO_DEFAULT_PATH
>>>>   )
>>>>   mark_as_advanced ( ZLIB_DLL )
>>>>   if ( ZLIB_DLL )
>>>>     add_library ( zlib SHARED IMPORTED GLOBAL )
>>>>     set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB "${ZLIB_LIBRARY}"
>>>> )
>>>>     set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_DLL}" )
>>>>   else ( ZLIB_DLL )
>>>>     add_library ( zlib STATIC IMPORTED GLOBAL )
>>>>     set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>>>> "${ZLIB_LIBRARY}" )
>>>>   endif ( ZLIB_DLL )
>>>> else( WIN32 )
>>>>   add_library ( zlib UNKNOWN IMPORTED GLOBAL )
>>>>   set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION "${ZLIB_LIBRARY}"
>>>> )
>>>> endif( WIN32 )
>>>> set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
>>>>   "${ZLIB_INCLUDE_DIR}"
>>>> )
>>>> 
>>>> set ( ZLIB_LIBRARIES zlib )
>>>> set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
>>>> endif ( ZLIB_FOUND )
>>>> 
>>>> The .lib goes into IMPORTED_IMPLIB and the .dll goes into IMPORTED_LOCATION.
>>>> The way to find the .dll from the location of the .lib might differ for
>>>> different libraries.
>>>> For ZLib, the base name is the same.
>>>> 
>>>> Later, you can use this imported target:
>>>> add_custom_command ( TARGET myTarget POST_BUILD
>>>>   COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib>
>>>> $<TARGET_FILE_DIR:myTarget>
>>>> )
>>>> Now, zlib.dll is in the same directory as myTarget.dll.
>>>> 
>>>> HS
>>>> 
>>>>> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
>>>>> <post at hendrik-sattler.de> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> you can use generator expression in a post build rule to copy the dll
>>>>>> file to the same target dir as the target you link it with. The easiest way
>>>>>> to do this is to properly define all 3rd party libraries as imported targets
>>>>>> that contains both, the lib and the dll file.
>>>>>> Sadly, the FindQt4 on Windows doesn't do this and thus make life harder
>>>>>> than needed. CMake configuration files should always do this right.
>>>>>> 
>>>>>> OTOH, you could also write a wrapper batch file or change VS properties
>>>>>> to modify PATH to include all libraries before the regular path.
>>>>>> 
>>>>>> HS
>>>>>> 
>>>>>> 
>>>>>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey
>>>>>> <rcdailey.lists at gmail.com>:
>>>>>>> 
>>>>>>> This actually used to be a very difficult problem to solve. However,
>>>>>>> to debug in visual studio it's essential.
>>>>>>> 
>>>>>>> If I have DLLs located in third party directories OR from targets that
>>>>>>> I depend on, those must all be copied to the directory of the
>>>>>>> executable I'm debugging in order for those DLLs to be found and
>>>>>>> loaded.
>>>>>>> 
>>>>>>> Using CMake 3.0.2, I hope this task is simpler, especially with the
>>>>>>> introduction of a nice suite of generator expressions. Can anyone
>>>>>>> recommend a good way to do this?
>>>>>> 
>>>>>> 
>>>>> --
>>>>> 
>>>>> 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
>>> --
>>> 
>>> 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


From post at hendrik-sattler.de  Fri Oct 31 15:51:02 2014
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Fri, 31 Oct 2014 20:51:02 +0100
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
Message-ID: <7C9F1EE6-3C6C-4EB5-B436-0603311FE029@hendrik-sattler.de>



Am 31. Oktober 2014 20:11:23 MEZ, schrieb Robert Dailey <rcdailey.lists at gmail.com>:
>I like this idea but it doesn't seem like it will work for targets
>with multiple DLLs... for example boost. It has several DLLs. I don't
>want to define 1 target for each DLL either. Sometimes that doesn't
>make sense.

The FindQt4 module already does this. Every component has its own imported target, e.g. Qt4::Core. The :: is for namespacing in cmake.
There can only be one library per imported target but you can still group them with variables, again see FindQt4.
Interface targets should not contain libraries.

>On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
><post at hendrik-sattler.de> wrote:
>> Am 2014-10-28 18:25, schrieb Robert Dailey:
>>>
>>> I have a third party library like OpenSSL prebuilt for each platform
>>> and in my own structure in version control. I have a CMake script
>that
>>> creates an INTERFACE library target for it. I setup the include
>>> directories and link targets. However, I don't see a way to
>configure
>>> DLLs in the interface library target. How would you do this, and
>what
>>> would CMake do to these targets to make sure they are copied to the
>>> output directory of the executable I run from Visual Studio for
>>> debugging?
>>
>>
>> I have this for ZLib:
>> if ( ZLIB_FOUND )
>>   if ( WIN32 )
>>     get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
>>     get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE
>)
>>     get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
>>     find_file ( ZLIB_DLL
>>
>"${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
>>       HINTS
>>         "${ZLIB_LIBDIR_BASE}"
>>       PATH_SUFFIXES
>>         bin
>>       NO_DEFAULT_PATH
>>     )
>>     mark_as_advanced ( ZLIB_DLL )
>>     if ( ZLIB_DLL )
>>       add_library ( zlib SHARED IMPORTED GLOBAL )
>>       set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB
>"${ZLIB_LIBRARY}"
>> )
>>       set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>"${ZLIB_DLL}" )
>>     else ( ZLIB_DLL )
>>       add_library ( zlib STATIC IMPORTED GLOBAL )
>>       set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>> "${ZLIB_LIBRARY}" )
>>     endif ( ZLIB_DLL )
>>   else( WIN32 )
>>     add_library ( zlib UNKNOWN IMPORTED GLOBAL )
>>     set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>"${ZLIB_LIBRARY}"
>> )
>>   endif( WIN32 )
>>   set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
>>     "${ZLIB_INCLUDE_DIR}"
>>   )
>>
>>   set ( ZLIB_LIBRARIES zlib )
>>   set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
>> endif ( ZLIB_FOUND )
>>
>> The .lib goes into IMPORTED_IMPLIB and the .dll goes into
>IMPORTED_LOCATION.
>> The way to find the .dll from the location of the .lib might differ
>for
>> different libraries.
>> For ZLib, the base name is the same.
>>
>> Later, you can use this imported target:
>>   add_custom_command ( TARGET myTarget POST_BUILD
>>     COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib>
>> $<TARGET_FILE_DIR:myTarget>
>>   )
>> Now, zlib.dll is in the same directory as myTarget.dll.
>>
>> HS
>>
>>> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
>>> <post at hendrik-sattler.de> wrote:
>>>>
>>>> Hi,
>>>>
>>>> you can use generator expression in a post build rule to copy the
>dll
>>>> file to the same target dir as the target you link it with. The
>easiest way
>>>> to do this is to properly define all 3rd party libraries as
>imported targets
>>>> that contains both, the lib and the dll file.
>>>> Sadly, the FindQt4 on Windows doesn't do this and thus make life
>harder
>>>> than needed. CMake configuration files should always do this right.
>>>>
>>>> OTOH, you could also write a wrapper batch file or change VS
>properties
>>>> to modify PATH to include all libraries before the regular path.
>>>>
>>>> HS
>>>>
>>>>
>>>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey
>>>> <rcdailey.lists at gmail.com>:
>>>>>
>>>>> This actually used to be a very difficult problem to solve.
>However,
>>>>> to debug in visual studio it's essential.
>>>>>
>>>>> If I have DLLs located in third party directories OR from targets
>that
>>>>> I depend on, those must all be copied to the directory of the
>>>>> executable I'm debugging in order for those DLLs to be found and
>>>>> loaded.
>>>>>
>>>>> Using CMake 3.0.2, I hope this task is simpler, especially with
>the
>>>>> introduction of a nice suite of generator expressions. Can anyone
>>>>> recommend a good way to do this?
>>>>
>>>>
>>> --
>>>
>>> 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


From d3ck0r at gmail.com  Fri Oct 31 15:51:35 2014
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 31 Oct 2014 12:51:35 -0700
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
 <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
 <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
Message-ID: <CAA2GJqVeyUgM8sEq6CKw9qKvPNXAMcMpHGRQPPMnpmrMd25t6w@mail.gmail.com>

So much work to go to an intermediate location... you can't distribute from
there easily... it only makes development minorly simpler...
and if you're copying resources(data) to that location just to be able to
test from immediate output instead of a copy of the distribution......

install( files ${QT_LIBS} DESTINATION bin )
install( FILES ${Boost_LIBRARIES} DESTINATION bin )
install( DIRECTORY ${Boost_shared_files_something... data defs) DESTINATION
share )


On Fri, Oct 31, 2014 at 12:42 PM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> Never said it was pretty, but here is the code I use for Qt4 based
> projects. I think I had to revamp a lot of this for Qt5. I call it like so:
>
> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork")
>
>
> # --------------------------------------------------------------------
> #-- Copy all the Qt4 dependent DLLs into the current build directory so
> that
> #-- one can debug an application or library that depends on Qt4 libraries.
> #-- This macro is really intended for Windows Builds because windows
> libraries
> #-- do not have any type of rpath or install_name encoded in the libraries
> so
> #-- the least intrusive way to deal with the PATH issues is to just copy
> all
> #-- the dependend DLL libraries into the build directory. Note that this is
> #-- NOT needed for static libraries.
> macro(CMP_COPY_QT4_RUNTIME_LIBRARIES QTLIBLIST)
>     # message(STATUS "CMP_COPY_QT4_RUNTIME_LIBRARIES")
>     set(SUPPORT_LIB_OPTION 1)
>     if(MSVC_IDE)
>       set(SUPPORT_LIB_OPTION 0)
>     elseif(APPLE) # Apple systems do NOT need this so just skip this
> entirely
>       set(SUPPORT_LIB_OPTION 2)
>     elseif(UNIX AND NOT MSVC)
>       set(SUPPORT_LIB_OPTION 3)
>     endif()
>
>     if(NOT DEFINED QT_QMAKE_EXECUTABLE)
>       message(FATAL_ERROR "Qt is REQUIRED to use this Function or macro.
> Make sure Qt is found on your system.")
>     endif()
>
>     if(SUPPORT_LIB_OPTION EQUAL 0)
>       set(TYPE "d")
>       FOREACH(qtlib ${QTLIBLIST})
>         GET_FILENAME_COMPONENT(QT_DLL_PATH_tmp ${QT_QMAKE_EXECUTABLE} PATH)
>         # message(STATUS "CMAKE_GENERATOR: ${CMAKE_GENERATOR}")
>         # We need to copy both the Debug and Release versions of the
> libraries into their respective
>         # subfolders for Visual Studio builds
>         add_custom_target(ZZ_${qtlib}-Debug-Copy ALL
>                             COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${QT_DLL_PATH_tmp}/${qtlib}${TYPE}4.dll
>                             ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Debug/
>                             COMMENT "Copying ${qtlib}${TYPE}4.dll to
> ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Debug/")
>         set_target_properties(ZZ_${qtlib}-Debug-Copy PROPERTIES FOLDER
> ZZ_COPY_FILES)
>       #   message(STATUS "Generating Copy Rule for Qt Release DLL Library
> ${QT_DLL_PATH_tmp}/${qtlib}d4.dll")
>         add_custom_target(ZZ_${qtlib}-Release-Copy ALL
>                             COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${QT_DLL_PATH_tmp}/${qtlib}4.dll
>                             ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Release/
>                             COMMENT "Copying ${qtlib}4.dll to
> ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Release/")
>         set_target_properties(ZZ_${qtlib}-Release-Copy PROPERTIES FOLDER
> ZZ_COPY_FILES)
>
>       ENDFOREACH(qtlib)
>     elseif(SUPPORT_LIB_OPTION EQUAL 1)
>       set(TYPE "")
>       if( ${CMAKE_BUILD_TYPE} STREQUAL "Debug")
>           set(TYPE "d")
>       endif()
>       FOREACH(qtlib ${QTLIBLIST})
>           GET_FILENAME_COMPONENT(QT_DLL_PATH_tmp ${QT_QMAKE_EXECUTABLE}
> PATH)
>           #message(STATUS "Generating Copy Rule for Qt DLL:
> ${QT_DLL_PATH_tmp}/${qtlib}d4.dll")
>           add_custom_target(ZZ_${qtlib}-Debug-Copy ALL
>                       COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${QT_DLL_PATH_tmp}/${qtlib}${TYPE}4.dll
>                       ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/
>                       COMMENT "Copying ${qtlib}${TYPE}4.dll to
> ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/")
>           set_target_properties(ZZ_${qtlib}-Debug-Copy PROPERTIES FOLDER
> ZZ_COPY_FILES)
>       ENDFOREACH(qtlib)
>     endif()
> endmacro()
>
>
> On Oct 31, 2014, at 3:37 PM, Robert Dailey <rcdailey.lists at gmail.com>
> wrote:
>
> > If it were only a matter of style / visual annoyance, I wouldn't mind.
> > However it complicates dependency management when you have to specify
> > "ZZ_QT_LIB1", "ZZ_QT_LIB2", etc... instead of just "QT" when calling
> > target_link_libraries().
> >
> > Unless you do it differently...
> >
> > On Fri, Oct 31, 2014 at 2:28 PM, Michael Jackson
> > <mike.jackson at bluequartz.net> wrote:
> >> It sucks, but I do that with Qt's libraries. One target for each
> library. I prefix the target with "ZZ_" so that in IDEs like Visual Studio
> and Xcode those targets fall to the bottom of the list. I also group them
> in folders if Visual Studio will allow it. I use the "copy if different"
> argument to the CMake command for the copy. Seems to work.
> >>
> >> Mike Jackson
> >>
> >> On Oct 31, 2014, at 3:11 PM, Robert Dailey <rcdailey.lists at gmail.com>
> wrote:
> >>
> >>> I like this idea but it doesn't seem like it will work for targets
> >>> with multiple DLLs... for example boost. It has several DLLs. I don't
> >>> want to define 1 target for each DLL either. Sometimes that doesn't
> >>> make sense.
> >>>
> >>> On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
> >>> <post at hendrik-sattler.de> wrote:
> >>>> Am 2014-10-28 18:25, schrieb Robert Dailey:
> >>>>>
> >>>>> I have a third party library like OpenSSL prebuilt for each platform
> >>>>> and in my own structure in version control. I have a CMake script
> that
> >>>>> creates an INTERFACE library target for it. I setup the include
> >>>>> directories and link targets. However, I don't see a way to configure
> >>>>> DLLs in the interface library target. How would you do this, and what
> >>>>> would CMake do to these targets to make sure they are copied to the
> >>>>> output directory of the executable I run from Visual Studio for
> >>>>> debugging?
> >>>>
> >>>>
> >>>> I have this for ZLib:
> >>>> if ( ZLIB_FOUND )
> >>>> if ( WIN32 )
> >>>>   get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
> >>>>   get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE )
> >>>>   get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
> >>>>   find_file ( ZLIB_DLL
> >>>>
> "${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
> >>>>     HINTS
> >>>>       "${ZLIB_LIBDIR_BASE}"
> >>>>     PATH_SUFFIXES
> >>>>       bin
> >>>>     NO_DEFAULT_PATH
> >>>>   )
> >>>>   mark_as_advanced ( ZLIB_DLL )
> >>>>   if ( ZLIB_DLL )
> >>>>     add_library ( zlib SHARED IMPORTED GLOBAL )
> >>>>     set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB
> "${ZLIB_LIBRARY}"
> >>>> )
> >>>>     set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
> "${ZLIB_DLL}" )
> >>>>   else ( ZLIB_DLL )
> >>>>     add_library ( zlib STATIC IMPORTED GLOBAL )
> >>>>     set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
> >>>> "${ZLIB_LIBRARY}" )
> >>>>   endif ( ZLIB_DLL )
> >>>> else( WIN32 )
> >>>>   add_library ( zlib UNKNOWN IMPORTED GLOBAL )
> >>>>   set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
> "${ZLIB_LIBRARY}"
> >>>> )
> >>>> endif( WIN32 )
> >>>> set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
> >>>>   "${ZLIB_INCLUDE_DIR}"
> >>>> )
> >>>>
> >>>> set ( ZLIB_LIBRARIES zlib )
> >>>> set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
> >>>> endif ( ZLIB_FOUND )
> >>>>
> >>>> The .lib goes into IMPORTED_IMPLIB and the .dll goes into
> IMPORTED_LOCATION.
> >>>> The way to find the .dll from the location of the .lib might differ
> for
> >>>> different libraries.
> >>>> For ZLib, the base name is the same.
> >>>>
> >>>> Later, you can use this imported target:
> >>>> add_custom_command ( TARGET myTarget POST_BUILD
> >>>>   COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib>
> >>>> $<TARGET_FILE_DIR:myTarget>
> >>>> )
> >>>> Now, zlib.dll is in the same directory as myTarget.dll.
> >>>>
> >>>> HS
> >>>>
> >>>>> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
> >>>>> <post at hendrik-sattler.de> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> you can use generator expression in a post build rule to copy the
> dll
> >>>>>> file to the same target dir as the target you link it with. The
> easiest way
> >>>>>> to do this is to properly define all 3rd party libraries as
> imported targets
> >>>>>> that contains both, the lib and the dll file.
> >>>>>> Sadly, the FindQt4 on Windows doesn't do this and thus make life
> harder
> >>>>>> than needed. CMake configuration files should always do this right.
> >>>>>>
> >>>>>> OTOH, you could also write a wrapper batch file or change VS
> properties
> >>>>>> to modify PATH to include all libraries before the regular path.
> >>>>>>
> >>>>>> HS
> >>>>>>
> >>>>>>
> >>>>>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey
> >>>>>> <rcdailey.lists at gmail.com>:
> >>>>>>>
> >>>>>>> This actually used to be a very difficult problem to solve.
> However,
> >>>>>>> to debug in visual studio it's essential.
> >>>>>>>
> >>>>>>> If I have DLLs located in third party directories OR from targets
> that
> >>>>>>> I depend on, those must all be copied to the directory of the
> >>>>>>> executable I'm debugging in order for those DLLs to be found and
> >>>>>>> loaded.
> >>>>>>>
> >>>>>>> Using CMake 3.0.2, I hope this task is simpler, especially with the
> >>>>>>> introduction of a nice suite of generator expressions. Can anyone
> >>>>>>> recommend a good way to do this?
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>>
> >>>>> 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
> >>> --
> >>>
> >>> 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
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141031/8e534b96/attachment-0001.html>

From bill at classdesign.com  Fri Oct 31 15:51:55 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 31 Oct 2014 19:51:55 +0000
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
 <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
 <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
Message-ID: <5453E85B.7060808@classdesign.com>

On 31/10/2014 19:42, Michael Jackson wrote:
> Never said it was pretty, but here is the code I use for Qt4 based projects. I think I had to revamp a lot of this for Qt5. I call it like so:
>
> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork")
This seems an awful lot of messing around when qt-project.org already 
dump all the debug and release libraries into the installation bin 
directory so all you need is to ensure that the installation bin 
directory is on your PATH when you run or debug executables, just like 
you have to to build using the tools like moc, qmake, dumpcpp, qrc, etc..

IMHO put he Qt bin directory on PATH for debugging and use BundleUtils 
FixupBundle to make deployable kits. No need to do any manual or 
scripted copying of libraries at all.

Regards
Bill.

From post at hendrik-sattler.de  Fri Oct 31 15:53:33 2014
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Fri, 31 Oct 2014 20:53:33 +0100
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
Message-ID: <631A1873-293A-4993-8CF0-99E48FD283DE@hendrik-sattler.de>



Am 31. Oktober 2014 20:28:00 MEZ, schrieb Michael Jackson <mike.jackson at bluequartz.net>:
>It sucks, but I do that with Qt's libraries. One target for each
>library. I prefix the target with "ZZ_" so that in IDEs like Visual
>Studio and Xcode those targets fall to the bottom of the list. I also
>group them in folders if Visual Studio will allow it. I use the "copy
>if different" argument to the CMake command for the copy. Seems to
>work.

Hmm, imported targets don't appear in VS. So why would you name them in such a way?

>Mike Jackson
>
>On Oct 31, 2014, at 3:11 PM, Robert Dailey <rcdailey.lists at gmail.com>
>wrote:
>
>> I like this idea but it doesn't seem like it will work for targets
>> with multiple DLLs... for example boost. It has several DLLs. I don't
>> want to define 1 target for each DLL either. Sometimes that doesn't
>> make sense.
>> 
>> On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
>> <post at hendrik-sattler.de> wrote:
>>> Am 2014-10-28 18:25, schrieb Robert Dailey:
>>>> 
>>>> I have a third party library like OpenSSL prebuilt for each
>platform
>>>> and in my own structure in version control. I have a CMake script
>that
>>>> creates an INTERFACE library target for it. I setup the include
>>>> directories and link targets. However, I don't see a way to
>configure
>>>> DLLs in the interface library target. How would you do this, and
>what
>>>> would CMake do to these targets to make sure they are copied to the
>>>> output directory of the executable I run from Visual Studio for
>>>> debugging?
>>> 
>>> 
>>> I have this for ZLib:
>>> if ( ZLIB_FOUND )
>>>  if ( WIN32 )
>>>    get_filename_component( ZLIB_LIBDIR "${ZLIB_LIBRARY}" PATH )
>>>    get_filename_component ( ZLIB_BASENAME "${ZLIB_LIBRARY}" NAME_WE
>)
>>>    get_filename_component ( ZLIB_LIBDIR_BASE "${ZLIB_LIBDIR}" PATH )
>>>    find_file ( ZLIB_DLL
>>>
>"${CMAKE_SHARED_LIBRARY_PREFIX}${ZLIB_BASENAME}${CMAKE_SHARED_LIBRARY_SUFFIX}"
>>>      HINTS
>>>        "${ZLIB_LIBDIR_BASE}"
>>>      PATH_SUFFIXES
>>>        bin
>>>      NO_DEFAULT_PATH
>>>    )
>>>    mark_as_advanced ( ZLIB_DLL )
>>>    if ( ZLIB_DLL )
>>>      add_library ( zlib SHARED IMPORTED GLOBAL )
>>>      set_property ( TARGET zlib PROPERTY IMPORTED_IMPLIB
>"${ZLIB_LIBRARY}"
>>> )
>>>      set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>"${ZLIB_DLL}" )
>>>    else ( ZLIB_DLL )
>>>      add_library ( zlib STATIC IMPORTED GLOBAL )
>>>      set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>>> "${ZLIB_LIBRARY}" )
>>>    endif ( ZLIB_DLL )
>>>  else( WIN32 )
>>>    add_library ( zlib UNKNOWN IMPORTED GLOBAL )
>>>    set_property ( TARGET zlib PROPERTY IMPORTED_LOCATION
>"${ZLIB_LIBRARY}"
>>> )
>>>  endif( WIN32 )
>>>  set_property ( TARGET zlib PROPERTY INTERFACE_INCLUDE_DIRECTORIES
>>>    "${ZLIB_INCLUDE_DIR}"
>>>  )
>>> 
>>>  set ( ZLIB_LIBRARIES zlib )
>>>  set ( ZLIB_INCLUDE_DIRS "${ZLIB_INCLUDE_DIR}" )
>>> endif ( ZLIB_FOUND )
>>> 
>>> The .lib goes into IMPORTED_IMPLIB and the .dll goes into
>IMPORTED_LOCATION.
>>> The way to find the .dll from the location of the .lib might differ
>for
>>> different libraries.
>>> For ZLib, the base name is the same.
>>> 
>>> Later, you can use this imported target:
>>>  add_custom_command ( TARGET myTarget POST_BUILD
>>>    COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_FILE:zlib>
>>> $<TARGET_FILE_DIR:myTarget>
>>>  )
>>> Now, zlib.dll is in the same directory as myTarget.dll.
>>> 
>>> HS
>>> 
>>>> On Tue, Oct 28, 2014 at 12:21 AM, Hendrik Sattler
>>>> <post at hendrik-sattler.de> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> you can use generator expression in a post build rule to copy the
>dll
>>>>> file to the same target dir as the target you link it with. The
>easiest way
>>>>> to do this is to properly define all 3rd party libraries as
>imported targets
>>>>> that contains both, the lib and the dll file.
>>>>> Sadly, the FindQt4 on Windows doesn't do this and thus make life
>harder
>>>>> than needed. CMake configuration files should always do this
>right.
>>>>> 
>>>>> OTOH, you could also write a wrapper batch file or change VS
>properties
>>>>> to modify PATH to include all libraries before the regular path.
>>>>> 
>>>>> HS
>>>>> 
>>>>> 
>>>>> Am 28. Oktober 2014 02:55:08 MEZ, schrieb Robert Dailey
>>>>> <rcdailey.lists at gmail.com>:
>>>>>> 
>>>>>> This actually used to be a very difficult problem to solve.
>However,
>>>>>> to debug in visual studio it's essential.
>>>>>> 
>>>>>> If I have DLLs located in third party directories OR from targets
>that
>>>>>> I depend on, those must all be copied to the directory of the
>>>>>> executable I'm debugging in order for those DLLs to be found and
>>>>>> loaded.
>>>>>> 
>>>>>> Using CMake 3.0.2, I hope this task is simpler, especially with
>the
>>>>>> introduction of a nice suite of generator expressions. Can anyone
>>>>>> recommend a good way to do this?
>>>>> 
>>>>> 
>>>> --
>>>> 
>>>> 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
>> -- 
>> 
>> 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


From kainjow at kainjow.com  Fri Oct 31 16:11:21 2014
From: kainjow at kainjow.com (Kevin Wojniak)
Date: Fri, 31 Oct 2014 13:11:21 -0700
Subject: [CMake] Copying another target's executable into OS X app bundle
	with CMake 3
Message-ID: <5D093998-7BD7-43F1-BDFE-93868FC4F86A@kainjow.com>

Hi, we have several projects setup where the main target has a dependency on a smaller target and the smaller target?s executable gets copied into the main target?s OS X app bundle. We?ve been doing this with a combination of getting the target?s LOCATION property and making that path a source of the main target and setting its MACOSX_PACKAGE_LOCATION property.

However with CMake 3?s policy change we?re trying to replace usage of this. Unfortunately it looks like we have to now use add_custom_command() and $<TARGET_FILE:?>. This works, but I?m wondering if there?s a better way to accomplish what I?m after? It?d be great if CMake had some command that takes generator expressions but places targets into a bundle. We don?t use the ?install? targets as we need the bundles to be setup with the executables for debugging.

Also it?d be very hand to have a generator expression to get the target?s bundle folder. To do that now we have to use "$<TARGET_FILE_DIR:${TARGET}>/..? but it?d be nice and clean to have something like $<TARGET_BUNDLE:?>

Thanks,
Kevin


From dschepler at scalable-networks.com  Fri Oct 31 16:46:22 2014
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Fri, 31 Oct 2014 20:46:22 +0000
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <5453E85B.7060808@classdesign.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
 <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
 <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
 <5453E85B.7060808@classdesign.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4DF5@SNTMAIL01.snt.loc>

And what if there are more dependencies?  For example, we have a project here that uses Qt, Boost, OGRE, MYGUI, GDAL, Protobuf and EXPAT at least.  And then if some of those builds aren't self-contained, you could add in dependencies like OpenSSL, libjpeg, libpng, etc.  It seems like all those PATH entries could easily end up overflowing Windows' limit on the length of PATH.
-- 
Daniel

-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Somerville
Sent: Friday, October 31, 2014 12:52 PM
To: cmake at cmake.org
Subject: Re: [CMake] Copying DLLs to output directory

On 31/10/2014 19:42, Michael Jackson wrote:
> Never said it was pretty, but here is the code I use for Qt4 based projects. I think I had to revamp a lot of this for Qt5. I call it like so:
>
> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork")
This seems an awful lot of messing around when qt-project.org already dump all the debug and release libraries into the installation bin directory so all you need is to ensure that the installation bin directory is on your PATH when you run or debug executables, just like you have to to build using the tools like moc, qmake, dumpcpp, qrc, etc..

IMHO put he Qt bin directory on PATH for debugging and use BundleUtils FixupBundle to make deployable kits. No need to do any manual or scripted copying of libraries at all.

Regards
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


From chrysalisx at gmail.com  Fri Oct 31 16:59:06 2014
From: chrysalisx at gmail.com (Walter Gray)
Date: Fri, 31 Oct 2014 13:59:06 -0700
Subject: [CMake] Including unquoted ENV ProgramFiles in PATHS makes find_*
	fail
Message-ID: <5453F81A.3010303@gmail.com>

I was working on a find module, and ran into some rather unpredicted 
behavior - it appears that including ENV ProgramFiles at the end the 
list of PATHS makes the search fail!  Remove that line, put it first, or 
put it in quotes, and it works just fine.  Does anyone have any clue why 
this might happen? For reference, here's the command and the value of 
ProgramFiles on my machine:

ProgramFiles=C:\Program Files (x86)

#Fails:
find_path(wxWidgets_ROOT_DIR
     NAMES include/wx/wx.h
     PATHS
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno 
Setup: App Path]"
       ENV ProgramFiles
     )
#Works:
find_path(wxWidgets_ROOT_DIR
     NAMES include/wx/wx.h
     PATHS
       ENV ProgramFiles
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno 
Setup: App Path]"
     )
#Works
find_path(wxWidgets_ROOT_DIR
     NAMES include/wx/wx.h
     PATHS
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno 
Setup: App Path]"
       "ENV ProgramFiles"
     )


From bill at classdesign.com  Fri Oct 31 17:12:12 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 31 Oct 2014 21:12:12 +0000
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4DF5@SNTMAIL01.snt.loc>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
 <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
 <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
 <5453E85B.7060808@classdesign.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4DF5@SNTMAIL01.snt.loc>
Message-ID: <5453FB2C.8030704@classdesign.com>

On 31/10/2014 20:46, Daniel Schepler wrote:
> And what if there are more dependencies?  For example, we have a project here that uses Qt, Boost, OGRE, MYGUI, GDAL, Protobuf and EXPAT at least.  And then if some of those builds aren't self-contained, you could add in dependencies like OpenSSL, libjpeg, libpng, etc.  It seems like all those PATH entries could easily end up overflowing Windows' limit on the length of PATH.
Seriously? 32,767 bytes maximum in an environment variable. If you blow 
that then I suggest installing all those packages somewhere nearer the 
filesystem root!

Regards
Bill.

From dschepler at scalable-networks.com  Fri Oct 31 17:18:36 2014
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Fri, 31 Oct 2014 21:18:36 +0000
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <5453FB2C.8030704@classdesign.com>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
 <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
 <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
 <5453E85B.7060808@classdesign.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4DF5@SNTMAIL01.snt.loc>
 <5453FB2C.8030704@classdesign.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4E94@SNTMAIL01.snt.loc>

In my online research, I was finding limits more like 1024 or 2048 characters maximum.  But if 32767 bytes is the real limit, and there are no compatibility issues with certain programs for values longer than 1024 characters, that would be great.
-- 
Daniel


-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Somerville
Sent: Friday, October 31, 2014 2:12 PM
To: cmake at cmake.org
Subject: Re: [CMake] Copying DLLs to output directory

On 31/10/2014 20:46, Daniel Schepler wrote:
> And what if there are more dependencies?  For example, we have a project here that uses Qt, Boost, OGRE, MYGUI, GDAL, Protobuf and EXPAT at least.  And then if some of those builds aren't self-contained, you could add in dependencies like OpenSSL, libjpeg, libpng, etc.  It seems like all those PATH entries could easily end up overflowing Windows' limit on the length of PATH.
Seriously? 32,767 bytes maximum in an environment variable. If you blow that then I suggest installing all those packages somewhere nearer the filesystem root!

Regards
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


From bill at classdesign.com  Fri Oct 31 17:23:46 2014
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 31 Oct 2014 21:23:46 +0000
Subject: [CMake] Copying DLLs to output directory
In-Reply-To: <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4E94@SNTMAIL01.snt.loc>
References: <CAHd499BEwC4npoxbe9e-mRJ-TtGfKWqR6fCGtNC0-NEwUZch1A@mail.gmail.com>
 <C13D6854-DC36-4717-B4BF-B0F4D510DB47@hendrik-sattler.de>
 <CAHd499BU_He81N0qk3DR6kg-CYUOx-NUySWVpfOoQog9CsAXnw@mail.gmail.com>
 <c3fc8b5445da5f67433300a4052c7a85@mail.hendrik-sattler.de>
 <CAHd499De4M89FyhoNNu=kOQDmUVybj6rQyXj23+MJMzH2paN5w@mail.gmail.com>
 <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net>
 <CAHd499ARFpyqFSN0-3hpSPRrjgC=FhTW6JJcnnvSCL4EyQPZeA@mail.gmail.com>
 <AFFDAC06-F6E3-46FF-88EA-213BAA6C3B4A@bluequartz.net>
 <5453E85B.7060808@classdesign.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4DF5@SNTMAIL01.snt.loc>
 <5453FB2C.8030704@classdesign.com>
 <E80C0FB7C5F9C7489F5E4B83BAD92C94380D4E94@SNTMAIL01.snt.loc>
Message-ID: <5453FDE2.3080201@classdesign.com>

On 31/10/2014 21:18, Daniel Schepler wrote:
> In my online research, I was finding limits more like 1024 or 2048 characters maximum.  But if 32767 bytes is the real limit, and there are no compatibility issues with certain programs for values longer than 1024 characters, that would be great.
Even that can be coped with if you are on Windows Vista or later since 
you can create symlinks to the various library directories if they lie 
at the end of lengthy paths. Then just add the symlinks to the PATH 
environment variable. Syminks are also very handy if you have versions 
in the paths to libraries as you only need to move the symlinks to 
switch versions :(

Regards
Bill.

From d3ck0r at gmail.com  Fri Oct 31 17:48:07 2014
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 31 Oct 2014 14:48:07 -0700
Subject: [CMake] Loading Plugins
In-Reply-To: <55F78FF2-8094-4645-B463-29C5B69C3BFE@mail.nih.gov>
References: <CAK8GPyADR6iUGPuX+MgmSHsbvCUPCG91mSMiGxr+kvSSVO6pgw@mail.gmail.com>
 <55F78FF2-8094-4645-B463-29C5B69C3BFE@mail.nih.gov>
Message-ID: <CAA2GJqXXcdZZd04Jq3Lj1EihVT1T349VCo4Re0aCKMEM5Xy2jQ@mail.gmail.com>

really nothing at all to do with cmake; a couple macros and you can support
cross-platform... a few less and you can init interfaces pretty easily....
at the end of init or during early discovery of functions, if they fail you
can fillthe interface with static methods or return a different
interface....

code part of
https://code.google.com/p/c-system-abstraction-component-gui/source/browse/src/streamlib/ffmpeg/ffmpeg_interface.c


#ifdef WIN32
#define lib_format WIDE("avformat-56.dll")
#else

#if defined( __ANDROID__) || defined( __LINUX__ )
#define lib_format WIDE("libavformat.so")
#endif

static struct fmpeg_interface
{
#define declare_func(a,b,c) a (CPROC *b) c
#define setup_func(lib, a,b,c) if( ffmpeg.b=(a(CPROC*)c)LoadFunction( lib,
_WIDE(#b) ) )

declare_func( void, av_register_all,(void) );
declare_func( int, avformat_open_input, (AVFormatContext **ps, const char
*filename, AVInputFormat *fmt, AVDictionary **options) );
/*...*/
} ffmpeg;


void Init( void )
{
 setup_func( lib_format, void, av_register_all,(void) );
setup_func( lib_format, int, avformat_open_input, (AVFormatContext **,
const char *, AVInputFormat *, AVDictionary **) );
setup_func( lib_format, int, avformat_close_input, (AVFormatContext **) );
 }

void LaterUsage( void )
{
ffmpeg.av_register_all();
}

void LaterUsageAsPointer( void )
{
struct fmpeg_interface interface = &ffmpeg; /* or from some other function
*/
interface->av_register_all();
}

if you have intellisense, makes for nice popups of available methods.

On Fri, Oct 31, 2014 at 11:24 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Hello,
>
> Yes, this can be done with ITK's object factory mechanism. I would study
> how it's done with ITK's ImageIO plugin mechanism[1], then figure out how
> to adapt the same framework for your interface.
>
> Brad
>
> [1] http://www.itk.org/Wiki/Plugin_IO_mechanisms
>
>
>
> On Oct 31, 2014, at 2:20 PM, Aaron Boxer <boxerab at gmail.com> wrote:
>
> > Hello!
> >
> > I have a C CMake project, and I would like to add the following feature:
> >
> > 1) define an interface for a second dynamic library
> > 2) look in a specified folder at runtime, and try to load this library
> > 3) if loading fails, then get notified of this fact, so that I can use
> statically linked fall-back routines in the parent project.
> >
> > Is this possible?  Any ideas or advice would be greatly appreciated.
> >
> > Thanks,
> > Aaron
> >
> >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141031/17562246/attachment.html>

From boxerab at gmail.com  Fri Oct 31 22:44:11 2014
From: boxerab at gmail.com (Aaron Boxer)
Date: Fri, 31 Oct 2014 22:44:11 -0400
Subject: [CMake] Loading Plugins
In-Reply-To: <CAA2GJqXXcdZZd04Jq3Lj1EihVT1T349VCo4Re0aCKMEM5Xy2jQ@mail.gmail.com>
References: <CAK8GPyADR6iUGPuX+MgmSHsbvCUPCG91mSMiGxr+kvSSVO6pgw@mail.gmail.com>
 <55F78FF2-8094-4645-B463-29C5B69C3BFE@mail.nih.gov>
 <CAA2GJqXXcdZZd04Jq3Lj1EihVT1T349VCo4Re0aCKMEM5Xy2jQ@mail.gmail.com>
Message-ID: <CAK8GPyCOm-T+QryS=ja0nvS66bAy+Ps6L7odkGdUcL_oAdjK1g@mail.gmail.com>

On Fri, Oct 31, 2014 at 5:48 PM, J Decker <d3ck0r at gmail.com> wrote:

>
> really nothing at all to do with cmake; a couple macros and you can
> support cross-platform... a few less and you can init interfaces pretty
> easily....
> at the end of init or during early discovery of functions, if they fail
> you can fillthe interface with static methods or return a different
> interface....
>
> code part of
> https://code.google.com/p/c-system-abstraction-component-gui/source/browse/src/streamlib/ffmpeg/ffmpeg_interface.c
>
>
> #ifdef WIN32
> #define lib_format WIDE("avformat-56.dll")
> #else
>
> #if defined( __ANDROID__) || defined( __LINUX__ )
> #define lib_format WIDE("libavformat.so")
> #endif
>
> static struct fmpeg_interface
> {
> #define declare_func(a,b,c) a (CPROC *b) c
> #define setup_func(lib, a,b,c) if( ffmpeg.b=(a(CPROC*)c)LoadFunction( lib,
> _WIDE(#b) ) )
>
> declare_func( void, av_register_all,(void) );
> declare_func( int, avformat_open_input, (AVFormatContext **ps, const char
> *filename, AVInputFormat *fmt, AVDictionary **options) );
> /*...*/
> } ffmpeg;
>
>
> void Init( void )
> {
>  setup_func( lib_format, void, av_register_all,(void) );
> setup_func( lib_format, int, avformat_open_input, (AVFormatContext **,
> const char *, AVInputFormat *, AVDictionary **) );
> setup_func( lib_format, int, avformat_close_input, (AVFormatContext **) );
>  }
>
> void LaterUsage( void )
> {
> ffmpeg.av_register_all();
> }
>
> void LaterUsageAsPointer( void )
> {
> struct fmpeg_interface interface = &ffmpeg; /* or from some other function
> */
> interface->av_register_all();
> }
>
> if you have intellisense, makes for nice popups of available methods.
>
>
Thanks. After a little Googling, I found this Dr. Dobbs article that
describes, with source code, how create a plugin architecture.

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141031/3b320f7c/attachment-0001.html>