From workbench at gmx.at  Sun Jun  2 07:31:33 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 2 Jun 2019 13:31:33 +0200
Subject: [CMake] Question about INSTALL and cpack
Message-ID: <dbe58913-dde2-bf0d-d514-f62824c0d026@gmx.at>

Hi everyone,

i'm relative new the cmake and i'm asking myself if i need the install
command for ExternalProject_Add() since these commands also "install"
the libraries needed at runtime.


Or do i need the install command only for targets that i want to compile ?


best regards!


From workbench at gmx.at  Sun Jun  2 08:07:47 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 2 Jun 2019 14:07:47 +0200
Subject: [CMake] Question about properties.
Message-ID: <dd543236-1a06-2d20-5448-e68e1cb52f62@gmx.at>

Hi again,


i'm reading up on properties and i see how to use set_properties and
get_properties but i don't know how i can find out which properties
exists for each entry (GLOBAL, DIRECTORY, TARGET, SOURCE, ...).


How can i retrieve a property if i don't have a list with all available
properties ?


best regards!


From workbench at gmx.at  Sun Jun  2 08:16:53 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 2 Jun 2019 14:16:53 +0200
Subject: [CMake] Question about running C code from within cmake
Message-ID: <a80b078b-447e-ae5b-f46f-4a7e3cb88956@gmx.at>

Hi everyone,


i'm trying to search for a way for win32 to get the cpu core count. i
found the c code:

|SYSTEM_INFO sysinfo;GetSystemInfo(&sysinfo);intnumCPU
=sysinfo.dwNumberOfProcessors; Is there a way i can get the return value
numCPU and create a variable out of it ? for apple and linux i allready
have a solution only win32 is left. best regards! |

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190602/1ca37a93/attachment.html>

From mellery451 at gmail.com  Sun Jun  2 10:11:03 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Sun, 2 Jun 2019 07:11:03 -0700
Subject: [CMake] Question about properties.
In-Reply-To: <dd543236-1a06-2d20-5448-e68e1cb52f62@gmx.at>
References: <dd543236-1a06-2d20-5448-e68e1cb52f62@gmx.at>
Message-ID: <D9F4EC6F-8F69-4086-943F-DDBB876B88F4@gmail.com>

I think you can refer to https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html  or ?cmake ?help-properties?.


> On Jun 2, 2019, at 5:07 AM, Steven Truppe <workbench at gmx.at> wrote:
> 
> Hi again,
> 
> 
> i'm reading up on properties and i see how to use set_properties and
> get_properties but i don't know how i can find out which properties
> exists for each entry (GLOBAL, DIRECTORY, TARGET, SOURCE, ...).
> 
> 
> How can i retrieve a property if i don't have a list with all available
> properties ?
> 
> 
> best regards!
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake


From mellery451 at gmail.com  Sun Jun  2 10:18:19 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Sun, 2 Jun 2019 07:18:19 -0700
Subject: [CMake] Question about running C code from within cmake
In-Reply-To: <a80b078b-447e-ae5b-f46f-4a7e3cb88956@gmx.at>
References: <a80b078b-447e-ae5b-f46f-4a7e3cb88956@gmx.at>
Message-ID: <B4053C7E-CEE6-44A2-AC94-D9326B67E2E2@gmail.com>

have a look at https://cmake.org/cmake/help/latest/module/ProcessorCount.html

If you still think you really need to compile/run code for this, have a look at https://cmake.org/cmake/help/latest/command/try_run.html#command:try_run, but that is harder to get working and maintain.

> On Jun 2, 2019, at 5:16 AM, Steven Truppe <workbench at gmx.at> wrote:
> 
> Hi everyone,
> 
> 
> 
> i'm trying to search for a way for win32 to get the cpu core count. i found the c code:
> 
> SYSTEM_INFO sysinfo;
> GetSystemInfo(&sysinfo);
> int numCPU = sysinfo.dwNumberOfProcessors
> ;
> 
> Is there a way i can get the return value numCPU and create a variable out of it ? for apple and linux i allready have a
> solution only win32 is left.
> 
> best regards!
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake


From andrew.amaclean at gmail.com  Sun Jun  2 18:38:20 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Mon, 3 Jun 2019 08:38:20 +1000
Subject: [CMake] Question about running C code from within cmake
In-Reply-To: <mailman.0.1559491202.27744.cmake@cmake.org>
References: <mailman.0.1559491202.27744.cmake@cmake.org>
Message-ID: <CAHDsG9OYCZ9+H75DVmFKmJV_VHb1bCkrJA6cg9BMf9nD_sx+zg@mail.gmail.com>

See: https://cmake.org/cmake/help/latest/module/ProcessorCount.html. There
is an example of its use there.

Windows also has a system variable called NUMBER_OF_PROCESSORS. Type "set"
on the command line and you will see it.



> ---------- Forwarded message ----------
> From: Steven Truppe <workbench at gmx.at>
> To: CMake MailingList <cmake at cmake.org>
> Cc:
> Bcc:
> Date: Sun, 2 Jun 2019 14:16:53 +0200
> Subject: [CMake] Question about running C code from within cmake
>
> Hi everyone,
>
>
> i'm trying to search for a way for win32 to get the cpu core count. i
> found the c code:
>
> SYSTEM_INFO sysinfo;GetSystemInfo(&sysinfo);int numCPU = sysinfo.dwNumberOfProcessors;
>
> Is there a way i can get the return value numCPU and create a variable out of it ? for apple and linux i allready have a
> solution only win32 is left.
>
> best regards!
>
>
>
> --
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190603/4fb862d8/attachment.html>

From doenges at mvtec.com  Mon Jun  3 06:19:56 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Mon, 3 Jun 2019 12:19:56 +0200
Subject: [CMake] Question about running C code from within cmake
In-Reply-To: <a80b078b-447e-ae5b-f46f-4a7e3cb88956@gmx.at>
References: <a80b078b-447e-ae5b-f46f-4a7e3cb88956@gmx.at>
Message-ID: <5fd6e7a7-a432-9d36-04eb-cb2a05fec0f8@mvtec.com>

The easiest way to get the number of cores on your Windows build machine 
from within CMake is to get the value of the NUMBER_OF_PROCESSORS 
environment variable using $ENV{NUMBER_OF_PROCESSORS}.

Am 02.06.19 um 14:16 schrieb Steven Truppe:
>
> Hi everyone,
>
>
> i'm trying to search for a way for win32 to get the cpu core count. i 
> found the c code:
>
> |SYSTEM_INFO sysinfo;GetSystemInfo(&sysinfo);intnumCPU 
> =sysinfo.dwNumberOfProcessors; Is there a way i can get the return 
> value numCPU and create a variable out of it ? for apple and linux i 
> allready have a solution only win32 is left. best regards! |
>
-- 

*Dr. Eric D?nges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:doenges at mvtec.com> | Tel: +49 89 457 695-0 | 
www.mvtec.com <http://www.mvtec.com>

Sign up <http://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190603/57fc452d/attachment.html>

From robert.maynard at kitware.com  Mon Jun  3 14:35:03 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 3 Jun 2019 14:35:03 -0400
Subject: [CMake] Free CMake course during KHQ Summer courses July 22-25 2019
Message-ID: <CAFzjYVoccwmSN8H5EN=6oJQ-jv0hzDDWHvciMCpfBvjrRNT4=g@mail.gmail.com>

Hi All,

This summer between July 22 - 25th Kitware is offering 7 free courses
over 3 days at our new headquarters in Albany NY.  One of the free
courses we will be offering is a full day CMake course on Tuesday July
23rd. Hopefully some of you will be able to attend, and we can meet in
person.

Sign up for the courses at: https://forms.gle/4Lze8vXrZSyvxWVm6
You can find more information on each course at:
https://blog.kitware.com/events/free-vtk-js-girder-tomviz-vtk-paraview-and-cmake-courses-at-kitware-this-summer/

The 4 day overview schedule is:

Monday July 22:
- VTK.JS: https://kitware.github.io/vtk-js/
- Girder: https://girder.readthedocs.io/en/stable/

Tuesday July 23:
- CMake

Wednesday July 24:
- VTK: https://vtk.org/
- Tomviz: https://tomviz.org/

Thursday July 25
- ParaView: https://www.paraview.org
- CMB: https://www.computationalmodelbuilder.org/

From bryan.christ at gmail.com  Mon Jun  3 18:16:10 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Mon, 3 Jun 2019 17:16:10 -0500
Subject: [CMake] Linking on OSX
Message-ID: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>

New to this mailing list so I hope I'm asking this in the right venue...

I'm trying to port my application (a program and a shared library) to OSX.
It was rather easy to modify my CMake script to go from Linux and add in
FreeBSD.  OSX is giving me a lot of problems though.

First of all find_package() doesn't seem to find the ncurses.dylib
installed by XCode as it test for wsyncup().  For whatever reason, that
test fails.  The default location for the library is pretty sane
(/usr/lib/) but the include file for ncurses is about 9 directories deep
inside of XCode's install directory.  Lots of problems here so I decided to
look at the symbol linkage for htop and see what it does.  It links to a
different version that got pulled down via homebrew in
/usr/local/opt/ncurses/lib (and include respectively)

Is there a way to force CMake to link to the library found there instead of
in /usr/lib/ ?

-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190603/08ec29a2/attachment.html>

From juan.e.sanchez at gmail.com  Mon Jun  3 18:27:48 2019
From: juan.e.sanchez at gmail.com (Juan E. Sanchez)
Date: Mon, 3 Jun 2019 17:27:48 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
Message-ID: <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>

Hello,

According to this:
https://github.com/neovim/neovim/issues/9050

It looks like macOS made it so you have to do something like this:
open 
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

for libraries and includes to be put into /usr.

Regards,

Juan


On 6/3/19 5:16 PM, Bryan Christ wrote:
> New to this mailing list so I hope I'm asking this in the right venue...
> 
> I'm trying to port my application (a program and a shared library) to 
> OSX.? It was rather easy to modify my CMake script to go from Linux and 
> add in FreeBSD.? OSX is giving me a lot of problems though.
> 
> First of all find_package() doesn't seem to find the ncurses.dylib 
> installed by XCode as it test for wsyncup().? For whatever reason, that 
> test fails.? The default location for the library is pretty sane 
> (/usr/lib/) but the include file for ncurses?is about 9 directories deep 
> inside of XCode's install directory.? Lots of problems here so I decided 
> to look at the symbol linkage for htop and see what it does.? It links 
> to a different version that got pulled down via homebrew in 
> /usr/local/opt/ncurses/lib (and include respectively)
> 
> Is there a way to force CMake to link to the library found there instead 
> of in /usr/lib/ ?
> 
> -- 
> Bryan
> <><
> 


From bryan.christ at gmail.com  Mon Jun  3 18:41:58 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Mon, 3 Jun 2019 17:41:58 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
Message-ID: <CAPQiZK_3raB4MqB7R8nCch7ick=y_k6Lr3HVa-p9Ce_mp_pXcQ@mail.gmail.com>

Jaun,

Thank you for pointing out that thread / issue.  It's a rather thread, but
soooo much I've what I'm experiencing is characterized in there.  I'll look
tomorrow and reply with results.

On Mon, Jun 3, 2019 at 5:27 PM Juan E. Sanchez <juan.e.sanchez at gmail.com>
wrote:

> Hello,
>
> According to this:
> https://github.com/neovim/neovim/issues/9050
>
> It looks like macOS made it so you have to do something like this:
> open
>
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>
> for libraries and includes to be put into /usr.
>
> Regards,
>
> Juan
>
>
> On 6/3/19 5:16 PM, Bryan Christ wrote:
> > New to this mailing list so I hope I'm asking this in the right venue...
> >
> > I'm trying to port my application (a program and a shared library) to
> > OSX.  It was rather easy to modify my CMake script to go from Linux and
> > add in FreeBSD.  OSX is giving me a lot of problems though.
> >
> > First of all find_package() doesn't seem to find the ncurses.dylib
> > installed by XCode as it test for wsyncup().  For whatever reason, that
> > test fails.  The default location for the library is pretty sane
> > (/usr/lib/) but the include file for ncurses is about 9 directories deep
> > inside of XCode's install directory.  Lots of problems here so I decided
> > to look at the symbol linkage for htop and see what it does.  It links
> > to a different version that got pulled down via homebrew in
> > /usr/local/opt/ncurses/lib (and include respectively)
> >
> > Is there a way to force CMake to link to the library found there instead
> > of in /usr/lib/ ?
> >
> > --
> > Bryan
> > <><
> >
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190603/f2e1d807/attachment.html>

From vinay.kotegowder at gmail.com  Tue Jun  4 09:37:58 2019
From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder)
Date: Tue, 4 Jun 2019 19:07:58 +0530
Subject: [CMake] find_program usage
Message-ID: <CAE3QRuMXVjssPayQOAo1O3wvoRTcJvnJjNPfKaXMKEL9ONP5xw@mail.gmail.com>

Hi Everyone,

This is simple code running on Windows machine:

if(WIN32)
  message(STATUS "On windows")
  find_program(_TOOL
              arm-none-eabi-gcc.exe
              PATHS "C:"
            )
endif()

message(STATUS "${_TOOL}")

Result after executing: cmake -P mycmake.cmake

-- On windows
-- _TOOL-NOTFOUND

Can anyone tell me what is wrong with the usage of "find_program"  ?

Vinay
Senior Engineer

From kyle.edwards at kitware.com  Tue Jun  4 09:42:02 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Tue, 04 Jun 2019 09:42:02 -0400
Subject: [CMake] find_program usage
In-Reply-To: <CAE3QRuMXVjssPayQOAo1O3wvoRTcJvnJjNPfKaXMKEL9ONP5xw@mail.gmail.com>
References: <CAE3QRuMXVjssPayQOAo1O3wvoRTcJvnJjNPfKaXMKEL9ONP5xw@mail.gmail.com>
Message-ID: <1559655722.28229.7.camel@kitware.com>

On Tue, 2019-06-04 at 19:07 +0530, vinay kumar Kotegowder wrote:
> Hi Everyone,
> 
> This is simple code running on Windows machine:
> 
> if(WIN32)
> ? message(STATUS "On windows")
> ? find_program(_TOOL
> ??????????????arm-none-eabi-gcc.exe
> ??????????????PATHS "C:"
> ????????????)
> endif()
> 
> message(STATUS "${_TOOL}")
> 
> Result after executing: cmake -P mycmake.cmake
> 
> -- On windows
> -- _TOOL-NOTFOUND
> 
> Can anyone tell me what is wrong with the usage of "find_program"???

find_program() is looking in C:, but not its subdirectories. So, unless
arm-none-eabi-gcc.exe is located directly in C:, CMake won't find it.

As a side note, GCC isn't typically found with find_program(). You most
likely want to write a cross-compiling toolchain file which contains
this location instead. See below for details:

https://cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html

Kyle

From vinay.kotegowder at gmail.com  Tue Jun  4 10:08:50 2019
From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder)
Date: Tue, 4 Jun 2019 19:38:50 +0530
Subject: [CMake] find_program usage
In-Reply-To: <1559655722.28229.7.camel@kitware.com>
References: <CAE3QRuMXVjssPayQOAo1O3wvoRTcJvnJjNPfKaXMKEL9ONP5xw@mail.gmail.com>
 <1559655722.28229.7.camel@kitware.com>
Message-ID: <CAE3QRuPukisHyyteK7ZgYbw5EuW43TkpAh8vq__0Ni4z6L+LQw@mail.gmail.com>

The original intent of the snippet is to find the required tool chain
(On windows : arm-none-eabi-gcc.exe or armclang.exe; On Linix :
arm-none-eabi-gcc or armclang) path which can later be used to build
the project.

I have been trying with find_program and find_path commands.
My understanding was that it would find the program from root(which is
C: in Windows and / in Linux) and all the sub directories underneath
it but I learnt from your reply that it is not the case.

Can this be done? I mean, should it be possible to find the program
without hard coding the path ?

- Vinay

On Tue, Jun 4, 2019 at 7:12 PM Kyle Edwards <kyle.edwards at kitware.com> wrote:
>
> On Tue, 2019-06-04 at 19:07 +0530, vinay kumar Kotegowder wrote:
> > Hi Everyone,
> >
> > This is simple code running on Windows machine:
> >
> > if(WIN32)
> >   message(STATUS "On windows")
> >   find_program(_TOOL
> >               arm-none-eabi-gcc.exe
> >               PATHS "C:"
> >             )
> > endif()
> >
> > message(STATUS "${_TOOL}")
> >
> > Result after executing: cmake -P mycmake.cmake
> >
> > -- On windows
> > -- _TOOL-NOTFOUND
> >
> > Can anyone tell me what is wrong with the usage of "find_program"  ?
>
> find_program() is looking in C:, but not its subdirectories. So, unless
> arm-none-eabi-gcc.exe is located directly in C:, CMake won't find it.
>
> As a side note, GCC isn't typically found with find_program(). You most
> likely want to write a cross-compiling toolchain file which contains
> this location instead. See below for details:
>
> https://cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html
>
> Kyle

From kyle.edwards at kitware.com  Tue Jun  4 10:37:35 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Tue, 04 Jun 2019 10:37:35 -0400
Subject: [CMake] find_program usage
In-Reply-To: <CAE3QRuPukisHyyteK7ZgYbw5EuW43TkpAh8vq__0Ni4z6L+LQw@mail.gmail.com>
References: <CAE3QRuMXVjssPayQOAo1O3wvoRTcJvnJjNPfKaXMKEL9ONP5xw@mail.gmail.com>
 <1559655722.28229.7.camel@kitware.com>
 <CAE3QRuPukisHyyteK7ZgYbw5EuW43TkpAh8vq__0Ni4z6L+LQw@mail.gmail.com>
Message-ID: <1559659055.28229.12.camel@kitware.com>

On Tue, 2019-06-04 at 19:38 +0530, vinay kumar Kotegowder wrote:
> The original intent of the snippet is to find the required tool chain
> (On windows : arm-none-eabi-gcc.exe or armclang.exe; On Linix :
> arm-none-eabi-gcc or armclang) path which can later be used to build
> the project.
> 
> I have been trying with find_program and find_path commands.
> My understanding was that it would find the program from root(which
> is
> C: in Windows and / in Linux) and all the sub directories underneath
> it but I learnt from your reply that it is not the case.
> 
> Can this be done? I mean, should it be possible to find the program
> without hard coding the path ?

It is possible to pass hints and paths to find_program() telling it
additional places to look ("it *might* be in C:/MinGW/whatever/bin"),
but other than that, find_program() does not search recursively. See
the find_program() documentation for more details:

https://cmake.org/cmake/help/v3.14/command/find_program.html

Again, for GCC, I strongly recommend that you use a toolchain file,
rather than setting CMAKE_C_COMPILER from inside your project. CMake
does a bunch of checks with the compiler when you first call project(),
which end up no longer being valid if you change CMAKE_C_COMPILER. (I
suppose you could set CMAKE_C_COMPILER from in your project before
calling project(), but I do not recommend this method.) You *can* call
find_program() from inside your toolchain file if you don't want to
hard-code the paths.

Kyle

From workbench at gmx.at  Tue Jun  4 10:39:48 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 16:39:48 +0200
Subject: [CMake] Question about regular expressions
Message-ID: <c1f26324-1639-9d33-75ca-c37c803de09b@gmx.at>

Hi everyone,


i had the same question a few days ago but can't rember the command (and
can't find it in the cods):

I have a regular expression like "WITH_LIB${lib}_EXAMPLE_([A-Za-z]+)"
and i want the get the content of the found variables in the (), the
command i used stored them if MATCH_XYZ but i can't exactly rember =(.


best regards!


From kyle.edwards at kitware.com  Tue Jun  4 10:43:12 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Tue, 04 Jun 2019 10:43:12 -0400
Subject: [CMake] Question about regular expressions
In-Reply-To: <c1f26324-1639-9d33-75ca-c37c803de09b@gmx.at>
References: <c1f26324-1639-9d33-75ca-c37c803de09b@gmx.at>
Message-ID: <1559659392.28229.13.camel@kitware.com>

On Tue, 2019-06-04 at 16:39 +0200, Steven Truppe wrote:
> Hi everyone,
> 
> 
> i had the same question a few days ago but can't rember the command
> (and
> can't find it in the cods):
> 
> I have a regular expression like "WITH_LIB${lib}_EXAMPLE_([A-Za-z]+)"
> and i want the get the content of the found variables in the (), the
> command i used stored them if MATCH_XYZ but i can't exactly rember
> =(.
> 
> 
> best regards!

CMAKE_MATCH_<n>

https://cmake.org/cmake/help/v3.14/variable/CMAKE_MATCH_n.html

Kyle

From workbench at gmx.at  Tue Jun  4 11:10:16 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 17:10:16 +0200
Subject: [CMake] General question:
Message-ID: <ff1e5ee1-143e-0ef3-9495-d517625ef762@gmx.at>

Hi everyone again,


i've the following code:

https://paste.debian.net/1086040/

and i just try to traverse a list and include files whose part of the
name are the list entries.


best regards!


From workbench at gmx.at  Tue Jun  4 11:11:53 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 17:11:53 +0200
Subject: [CMake] General question:
In-Reply-To: <ff1e5ee1-143e-0ef3-9495-d517625ef762@gmx.at>
References: <ff1e5ee1-143e-0ef3-9495-d517625ef762@gmx.at>
Message-ID: <e8d5c3bf-9196-2197-7765-9c5be9b9ac29@gmx.at>

I want the output not to be 'in' but 'glade' ...


On 04.06.19 17:10, Steven Truppe wrote:
> Hi everyone again,
>
>
> i've the following code:
>
> https://paste.debian.net/1086040/
>
> and i just try to traverse a list and include files whose part of the
> name are the list entries.
>
>
> best regards!
>

From kyle.edwards at kitware.com  Tue Jun  4 11:13:07 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Tue, 04 Jun 2019 11:13:07 -0400
Subject: [CMake] General question:
In-Reply-To: <e8d5c3bf-9196-2197-7765-9c5be9b9ac29@gmx.at>
References: <ff1e5ee1-143e-0ef3-9495-d517625ef762@gmx.at>
 <e8d5c3bf-9196-2197-7765-9c5be9b9ac29@gmx.at>
Message-ID: <1559661187.28229.14.camel@kitware.com>

On Tue, 2019-06-04 at 17:11 +0200, Steven Truppe wrote:
> I want the output not to be 'in' but 'glade' ...
> 
> 
> On 04.06.19 17:10, Steven Truppe wrote:
> > 
> > Hi everyone again,
> > 
> > 
> > i've the following code:
> > 
> > https://paste.debian.net/1086040/
> > 
> > and i just try to traverse a list and include files whose part of
> > the
> > name are the list entries.
> > 
> > 
> > best regards!
> > 

Please see the foreach() documentation:

https://cmake.org/cmake/help/v3.14/command/foreach.html

I think you want:

foreach(lib IN LISTS libs)

Kyle

From workbench at gmx.at  Tue Jun  4 11:45:06 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 17:45:06 +0200
Subject: [CMake] General question
Message-ID: <6e51f1d6-da11-3fa7-492e-62d6d3c34468@gmx.at>

 ??? Hi everyone,


i have the following code:

set(ALL_LIBS "glad;glfw")

# WITH_LIB_GLAD
option(WITH_LIB_GLAD 1)
option(WITH_LIB_GLAD_EXAMPLE_BASIC "Build the basic Glad example (default:0)" 1)
option(WITH_LIB_GLAD_EXAMPLE_SECOND "Build the second Glad example (default:0)" 1)

# WITH_LIB_GLFW
option(WITH_LIB_GLFW 1)
option(WITH_LIB_GLFW_EXAMPLE_CBASIC "Build the basic GLFW C example (default:1)" 1)
option(WITH_LIB_GLFW_EXAMPLE_CPPBASIC "Build the basic GLFW C example (default:1)" 1)


################
## bsBuildLib ##
################
macro(bsBuildLibs libs)
 ??? foreach(lib ${libs})
 ??? ??? message(STATUS "Searching incude path for lib: <${lib}>")
 ??? ??? bsIncludeLibs(${lib})
 ??? ??? bsBuildLibExamples(${lib})
 ??? endforeach()
endmacro()

###################
## bsIncludeLibs ##
###################
macro(bsIncludeLibs lib)
 ??? message(STATUS "INCLUDE library ${lib}")
 ??? include("lib_${lib}")
endmacro()

########################
## bsBuildLibExamples ##
########################
macro(bsBuildLibExamples lib)
 ??? # get all examples
 ??? foreach(_var in VARIABLES)
 ??? ??? string(TOUPPER ${lib} lib_upper)
 ??? ??? if(_var MATCHES "WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)")
 ??? ??? ??? message(STATUS "Found example: ${CMAKE_MATCH_0}")
 ??? ??? endif()
 ??? endforeach()
endmacro()

The final result should be that i get the name of the examples, like for
glad BASIC and SECOND and for glfw CBASIC and CPPBASIC.


best regards!




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/b55547a3/attachment-0001.html>

From workbench at gmx.at  Tue Jun  4 12:10:19 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 18:10:19 +0200
Subject: [CMake] General question about regex
Message-ID: <a7f7c9cd-c0cd-ac7a-366d-fcbf4763e598@gmx.at>

Hello again,


i've the following variable defined:

set(WITH_LIB_GLAD_EXAMPLE_BASIC 1)

And the if the line


foreach(_var VARIABLES)

 ??? if(_var MATCHES "WITH_LIB_GLAD_EXAMPLE_([A-Za-z]+)")

 ??? ??? message(STATUS "Found a match")

endforeach()


I never get the message "Found match", what am i doing wrong here ??


From kornel at lyx.org  Tue Jun  4 12:47:50 2019
From: kornel at lyx.org (Kornel Benko)
Date: Tue, 04 Jun 2019 18:47:50 +0200
Subject: [CMake] General question about regex
In-Reply-To: <a7f7c9cd-c0cd-ac7a-366d-fcbf4763e598@gmx.at>
References: <a7f7c9cd-c0cd-ac7a-366d-fcbf4763e598@gmx.at>
Message-ID: <22289096.PHOEFkUO95@amd64>

Am Dienstag, 4. Juni 2019, 18:10:19 CEST schrieb Steven Truppe:
> Hello again,
> 
> 
> i've the following variable defined:
> 
> set(WITH_LIB_GLAD_EXAMPLE_BASIC 1)
> 
> And the if the line
> 
> 
> foreach(_var VARIABLES)
> 
>      if(_var MATCHES "WITH_LIB_GLAD_EXAMPLE_([A-Za-z]+)")
> 
>          message(STATUS "Found a match")
> 
> endforeach()
> 
> 
> I never get the message "Found match", what am i doing wrong here ??
> 
> 

What about the attached?

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x.cmake
Type: text/x-cmake
Size: 279 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/f261ce18/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/f261ce18/attachment.sig>

From workbench at gmx.at  Tue Jun  4 13:19:40 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 19:19:40 +0200
Subject: [CMake] General question about regex
In-Reply-To: <22289096.PHOEFkUO95@amd64>
References: <a7f7c9cd-c0cd-ac7a-366d-fcbf4763e598@gmx.at>
 <22289096.PHOEFkUO95@amd64>
Message-ID: <0312cac6-c29d-917f-17dc-28254189db12@gmx.at>

I found the solution:

 ??? get_cmake_property(_vars VARIABLES)
  ?? foreach(_var ${_vars})
 ??? ??? string(TOUPPER ${lib} lib_upper)
 ??? ??? if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)$")
	??? ??? message(STATUS "Number of examples found: ${CMAKE_MATCH_COUNT}")
 ??? ??? 	message(STATUS "Number 1 found: ${CMAKE_MATCH_0}")
 ??? ??? endif()

 ??? endforeach()

Now i've two problem - the CMAKE_MATCH_0 contains the hole string and
not only the part the is in the (), i need only the part from the () -
is there another command i can use for this ?


On 04.06.19 18:47, Kornel Benko wrote:
> Am Dienstag, 4. Juni 2019, 18:10:19 CEST schrieb Steven Truppe:
>> Hello again,
>>
>>
>> i've the following variable defined:
>>
>> set(WITH_LIB_GLAD_EXAMPLE_BASIC 1)
>>
>> And the if the line
>>
>>
>> foreach(_var VARIABLES)
>>
>>       if(_var MATCHES "WITH_LIB_GLAD_EXAMPLE_([A-Za-z]+)")
>>
>>           message(STATUS "Found a match")
>>
>> endforeach()
>>
>>
>> I never get the message "Found match", what am i doing wrong here ??
>>
>>
> What about the attached?
>
> 	Kornel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/877817ea/attachment.html>

From kyle.edwards at kitware.com  Tue Jun  4 13:22:46 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Tue, 04 Jun 2019 13:22:46 -0400
Subject: [CMake] General question about regex
In-Reply-To: <0312cac6-c29d-917f-17dc-28254189db12@gmx.at>
References: <a7f7c9cd-c0cd-ac7a-366d-fcbf4763e598@gmx.at>
 <22289096.PHOEFkUO95@amd64> <0312cac6-c29d-917f-17dc-28254189db12@gmx.at>
Message-ID: <1559668966.28229.15.camel@kitware.com>

On Tue, 2019-06-04 at 19:19 +0200, Steven Truppe wrote:
> I found the solution:
> ??? get_cmake_property(_vars VARIABLES)
> ??? foreach(_var ${_vars})
> ??? ??? string(TOUPPER ${lib} lib_upper)
> ??? ??? if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-
> z]+)$")
> 	??? ??? message(STATUS "Number of examples found:
> ${CMAKE_MATCH_COUNT}")
> ??? ????	message(STATUS "Number 1 found: ${CMAKE_MATCH_0}")
> ??? ??? endif()
> ??? endforeach()
> Now i've two problem - the CMAKE_MATCH_0 contains the hole string and
> not only the part the is in the (), i need only the part from the ()
> - is there another command i can use for this ?

CMAKE_MATCH_1

Kyle

From workbench at gmx.at  Tue Jun  4 13:47:10 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 19:47:10 +0200
Subject: [CMake] General question about regex
In-Reply-To: <1559668966.28229.15.camel@kitware.com>
References: <a7f7c9cd-c0cd-ac7a-366d-fcbf4763e598@gmx.at>
 <22289096.PHOEFkUO95@amd64> <0312cac6-c29d-917f-17dc-28254189db12@gmx.at>
 <1559668966.28229.15.camel@kitware.com>
Message-ID: <f8d8146d-a33f-9f40-ceef-aa56a4878954@gmx.at>

Thanks alot. My other problem i have no how can i loop over the result,
there are just variables and ${CMAKE_CATCH_COUNT) what command can i use
the iterate over the result ??


best regrads!

On 04.06.19 19:22, Kyle Edwards wrote:
> On Tue, 2019-06-04 at 19:19 +0200, Steven Truppe wrote:
>> I found the solution:
>>  ??? get_cmake_property(_vars VARIABLES)
>>  ??? foreach(_var ${_vars})
>>  ??? ??? string(TOUPPER ${lib} lib_upper)
>>  ??? ??? if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-
>> z]+)$")
>> 	??? ??? message(STATUS "Number of examples found:
>> ${CMAKE_MATCH_COUNT}")
>>  ??? ????	message(STATUS "Number 1 found: ${CMAKE_MATCH_0}")
>>  ??? ??? endif()
>>  ??? endforeach()
>> Now i've two problem - the CMAKE_MATCH_0 contains the hole string and
>> not only the part the is in the (), i need only the part from the ()
>> - is there another command i can use for this ?
> CMAKE_MATCH_1
>
> Kyle
>

From bryan.christ at gmail.com  Tue Jun  4 13:56:46 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Tue, 4 Jun 2019 12:56:46 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
Message-ID: <CAPQiZK9=dCg7UCA9fSJNjeRxFdfXKGTe8cQ8ogLsR-htphwsYQ@mail.gmail.com>

Juan,

Thanks for your suggestions.  I went through that thread pretty thoroughly
trying all of the recommended tips and, unfortunately, nothing seemed to
work.  I also tried running that open command you cited, but there are
still no includes for ncurses in /usr/include or /usr/local/include.  In
fact /usr/include doesn't even exist on this system (mojave).

On Mon, Jun 3, 2019 at 5:27 PM Juan E. Sanchez <juan.e.sanchez at gmail.com>
wrote:

> Hello,
>
> According to this:
> https://github.com/neovim/neovim/issues/9050
>
> It looks like macOS made it so you have to do something like this:
> open
>
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>
> for libraries and includes to be put into /usr.
>
> Regards,
>
> Juan
>
>
> On 6/3/19 5:16 PM, Bryan Christ wrote:
> > New to this mailing list so I hope I'm asking this in the right venue...
> >
> > I'm trying to port my application (a program and a shared library) to
> > OSX.  It was rather easy to modify my CMake script to go from Linux and
> > add in FreeBSD.  OSX is giving me a lot of problems though.
> >
> > First of all find_package() doesn't seem to find the ncurses.dylib
> > installed by XCode as it test for wsyncup().  For whatever reason, that
> > test fails.  The default location for the library is pretty sane
> > (/usr/lib/) but the include file for ncurses is about 9 directories deep
> > inside of XCode's install directory.  Lots of problems here so I decided
> > to look at the symbol linkage for htop and see what it does.  It links
> > to a different version that got pulled down via homebrew in
> > /usr/local/opt/ncurses/lib (and include respectively)
> >
> > Is there a way to force CMake to link to the library found there instead
> > of in /usr/lib/ ?
> >
> > --
> > Bryan
> > <><
> >
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/77ead29a/attachment-0001.html>

From marc.herbert at gmail.com  Tue Jun  4 15:05:29 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Tue, 4 Jun 2019 12:05:29 -0700
Subject: [CMake] In add_subdirectory( binary_dir),
 binary_dir/ is just a decoy when there's no sub-target
Message-ID: <CA+rkZbiK9na=PKn27r-+X14z=n-4CN5H7xd4cYTHUO_JAZau3A@mail.gmail.com>

tl;dr: should there be at least one target per CMakeLists.txt?

https://cmake.org/cmake/help/v3.14/command/add_subdirectory.html
> add_subdirectory(source_dir [binary_dir] )
> "The binary_dir specifies the directory in which to place the output
files. [...] If binary_dir is not specified, the value of source_dir,
before expanding any relative path, will be used (the typical usage)."

I found this part of the documentation to be correct ONLY when the
subdirectory defines and uses its own "sub-"target(s). If the subdirectory
refers to higher main targets instead then binary_dir/ is just a decoy: the
subdirectory build happens elsewhere. binary_dir is a decoy whether it's
explicit or default. It exists but there are only totally generic and
unused files there.

Example:

mainsrc/
??? CMakeLists.txt
??? inmodule
?   ??? CMakeLists.txt
?   ??? infile.c
??? mainfile.c


# mainsrc/CMakeLists.txt
add_executable(mainexe mainfile.c)
add_subdirectory(inmodule [ decoy_binary_dir ] )

# mainsrc/inmodule/CMakeLists.txt
target_sources(mainexe PRIVATE infile.c) # <= direct reference, no
sub-target


cmake -GNinja -B build -S mainsrc && ninja -C build

build
??? CMakeFiles
?   ???
?   ??? mainexe.dir
?   ?   ???
?   ?   ???
?   ?   ??? inmodule       <= ACTUAL binary_dir!
?   ?   ?   ??? infile.c.o
?   ?   ??? mainfile.c.o
?   ?   ???
?   ?   :
?   ???
?   :
??? inmodule       <= decoy with unused, boilerplate files and no reference
to any code
?   ??? CMakeFiles/
?   ??? cmake_install.cmake


The midly irritating part is that cmake complains about the lack of a
binary_dir argument if the module is an _out-of-tree_ subdirectory:

CMake Error at CMakeLists.txt:5 (add_subdirectory):
  add_subdirectory not given a binary directory but the given source
  directory "~/cmake-test/outmodule" is not a subdirectory of
  "~/cmake-test/maindir".  When specifying an out-of-tree source
  a binary directory must be explicitly specified.

That request makes sense of course except... when given that binary_dir
argument it requested, it's still becomes a decoy as described above.
This is the actual (and funny) binary_dir /in this out-of-tree case:
build
??? CMakeFiles
?   ??? mainexe.dir
?   ?   ??? home
?   ?       ??? joe
?   ?           ??? cmake-test
?   ?               ??? outmodule
?   ?                   ??? outfile.c.o



Reproduced with cmake version 3.14.4. No difference between make and ninja.

Researching the interwebs most people, tutorials and other documents seem
to assume (at least) one target per CMakeLists.txt. Should such a
recommendation be made more official to avoid the sort of confusion above?
Could this recommendation avoid other, unrelated problems I haven't
experienced? Yet?

Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/1f594906/attachment.html>

From robert.maynard at kitware.com  Tue Jun  4 15:07:20 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 4 Jun 2019 15:07:20 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.15.0-rc1 is ready for testing
Message-ID: <CAFzjYVoAVF33mse6zdyfWDQuJzOz171NyOQUgH+G-HWSbq98ew@mail.gmail.com>

I am proud to announce the first CMake 3.15 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.15

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.15/release/3.15.html

Some of the more significant changes in CMake 3.15 are:

* The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and
  "MSVC_RUNTIME_LIBRARY" target property were introduced to select the
  runtime library used by compilers targeting the MSVC ABI. See policy
  "CMP0091".

* With MSVC-like compilers the value of "CMAKE_<LANG>_FLAGS" no
  longer contains warning flags like "/W3" by default. See policy
  "CMP0092".

* The "Clang" compiler variant on Windows that targets the MSVC ABI
  but has a GNU-like command line is now supported.

* Preliminary support for the "Swift" language was added to the
  "Ninja" generator.

* The "$<COMPILE_LANG_AND_ID:...>" generator expression was
  introduced to allow specification of compile options for target
  files based on the "CMAKE_<LANG>_COMPILER_ID" and "LANGUAGE" of each
  source file.

* The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID",
  "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE",
  "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching
  one value from a comma-separated list.

* The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell
  "find_package()" calls to look for a package configuration file
  first even if a find module is available.

* The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set
  on Interface Libraries. The headers specified by those properties
  can be installed using the "install(TARGETS)" command by passing the
  "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively.

* The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and
  "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the
  Just My Code feature of the Visual Studio Debugger when compiling
  with MSVC cl 19.05 and higher.

* The "FindBoost" module was reworked to expose a more consistent
  user experience between its ?Config? and ?Module? modes and with
  other find modules in general.

* The "message()" command learned new types: "NOTICE", "VERBOSE",
  "DEBUG" and "TRACE".

* The "export(PACKAGE)" command now does nothing unless enabled via
  "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".


* The "CMAKE_GENERATOR" environment variable was added to specify a
  default generator to use when "cmake(1)" is run without a "-G"
  option.  Additionally, environment variables
  "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and
  "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.

* The "cmake(1)" command gained a new "--install" option. This may
  be used after building a project to run installation without using
  the generated build system or the native build tool.

* The "cmake(1)" command learned a new CLI option "--loglevel".

* The "cmake-server(7)" mode has been deprecated and will be removed
  from a future version of CMake.  Please port clients to use the
  "cmake-file-api(7)" instead.


CMake 3.15 Release Notes
************************

Changes made since CMake 3.14 include the following.


New Features
============


Generators
----------

* The "Xcode" generator now supports per-target schemes. See the
  "CMAKE_XCODE_GENERATE_SCHEME" variable and "XCODE_GENERATE_SCHEME"
  target property.

* The "Green Hills MULTI" generator has been updated:

  * It now supports the "add_custom_command()" and
    "add_custom_target()" commands.

  * It is now available on Linux.


Languages
---------

* Preliminary support for the "Swift" language was added to the
  "Ninja" generator:

  * Use the "SWIFTC" environment variable to specify a compiler.

  * The "Swift_DEPENDENCIES_FILE" target property and
    "Swift_DEPENDENCIES_FILE" source file property were added to
    customize dependency files.

  * The "Swift_MODULE_NAME" target property was added to customize
    the Swift module name.

  * The "Swift_DIAGNOSTICS_FILE" source property was added to
    indicate where to write the serialised Swift diagnostics.

  The Swift support is experimental, not considered stable, and may
  change in future releases of CMake.


Compilers
---------

* The "Clang" compiler variant on Windows that targets the MSVC ABI
  but has a GNU-like command line is now supported.

* Support for the Clang-based ARM compiler was added with compiler
  id "ARMClang".

* Support was added for the IAR compiler architectures Renesas RX,
  RL78, RH850 and Texas Instruments MSP430.

* Support was added for the IAR compilers built for Linux (IAR
  BuildLx).


Command-Line
------------

* The "CMAKE_GENERATOR" environment variable was added to specify a
  default generator to use when "cmake(1)" is run without a "-G"
  option.  Additionally, environment variables
  "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and
  "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.

* The "cmake(1)" "--build" tool "--target" parameter gained support
  for multiple targets, e.g. "cmake --build . --target Library1
  Library2". It now also has a short form "-t" alias, e.g. "cmake
  --build . -t Library1 Library2".

* The "cmake(1)" command gained a new "--install" option. This may
  be used after building a project to run installation without using
  the generated build system or the native build tool.

* The "cmake(1)" command learned a new CLI option "--loglevel".

* The "cmake(1)" "-E remove_directory" command-line tool learned to
  support removing multiple directories.

* The "cmake(1)" "-E tar" tool has been improved:

  * It now continues adding files to an archive even if some of the
    files are not readable.  This behavior is more consistent with the
    classic "tar" tool.

  * It now parses all flags, and if an invalid flag was provided, a
    warning is issued.

  * It now displays an error if no action flag was specified, along
    with a list of possible actions: "t" (list), "c" (create) or "x"
    (extract).

  * It now supports extracting ("-x") or listing ("-t") only
    specific files or directories.

  * It now supports Zstandard compression with a "--zstd" option.
    Zstandard was designed to give a compression ratio comparable to
    that of the DEFLATE (zip) algorithm, but faster, especially for
    decompression.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  gained a new "JOB_POOL" option that works with the "Ninja" generator
  to set the pool variable on the build statement.

* The "add_library()" command "ALIAS" option learned to support
  import libraries of the "UNKNOWN" type.

* The "cmake_parse_arguments()" command gained an additional
  "<prefix>_KEYWORDS_MISSING_VALUES" output variable to report keyword
  arguments that were given by the caller with no values.

* The "execute_process()" command gained a "COMMAND_ECHO" option and
  supporting "CMAKE_EXECUTE_PROCESS_COMMAND_ECHO" variable to enable
  echoing of the command-line string before execution.

* The "file(INSTALL)" command learned a new argument,
  "FOLLOW_SYMLINK_CHAIN", which can be used to recursively resolve and
  install symlinks.

* "list()" learned new sub-commands: "PREPEND", "POP_FRONT" and
  "POP_BACK".

* The "message()" command learned new types: "NOTICE", "VERBOSE",
  "DEBUG" and "TRACE".

* The "string()" learned a new sub-command "REPEAT".


Variables
---------

* The "CMAKE_CROSSCOMPILING_EMULATOR" variable and corresponding
  "CROSSCOMPILING_EMULATOR" target property learned to support
  arguments to the emulator.

* The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell
  "find_package()" calls to look for a package configuration file
  first even if a find module is available.

* The "CMAKE_FRAMEWORK" variable was added to initialize the
  "FRAMEWORK" property on all targets.

* The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and
  "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the
  Just My Code feature of the Visual Studio Debugger when compiling
  with MSVC cl 19.05 and higher.

* The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and
  "MSVC_RUNTIME_LIBRARY" target property were introduced to select the
  runtime library used by compilers targeting the MSVC ABI. See policy
  "CMP0091".

* The "CMAKE_PROJECT_INCLUDE" and "CMAKE_PROJECT_INCLUDE_BEFORE"
  variables were added to allow injection of custom code at the sites
  of "project()" calls without knowing the project name a priori.


Properties
----------

* The "ADDITIONAL_CLEAN_FILES" target property and
  "ADDITIONAL_CLEAN_FILES" directory property were added. They allow
  to register additional files that should be removed during the clean
  stage.

* The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set
  on Interface Libraries. The headers specified by those properties
  can be installed using the "install(TARGETS)" command by passing the
  "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively.

* The "VS_PACKAGE_REFERENCES" target property was added to tell
  Visual Studio Generators to add references to "nuget" packages.

* The "VS_PROJECT_IMPORT" target property was added to allow managed
  Visual Studio project files to import external ".props" files.

* The "VS_NO_SOLUTION_DEPLOY" target property was added to tell
  Visual Studio Generators whether to deploy an artifact to the WinCE
  or Windows Phone target device.


Modules
-------

* The "FindBoost" module was reworked to expose a more consistent
  user experience between its ?Config? and ?Module? modes and with
  other find modules in general.

  * A new imported target "Boost::headers" is now defined (same as
    "Boost::boost").

  * New output variables "Boost_VERSION_MACRO",
    "Boost_VERSION_MAJOR", "Boost_VERSION_MINOR",
    "Boost_VERSION_PATCH", and "Boost_VERSION_COUNT" were added.

  * The "QUIET" argument passed to "find_package()" is no longer
    ignored in config mode.  Note that the CMake package shipped with
    Boost "1.70.0" ignores the "QUIET" argument passed to
    "find_package()".  This is fixed in the next Boost release.

  * The input switch "Boost_DETAILED_FAILURE_MSG" was removed.

  * "Boost_VERSION" now reports the version in "x.y.z" format in
    module mode.  See policy "CMP0093".

* The "FindCups" module now provides imported targets.

* The "FindEnvModules" module was added to use Lua- and TCL-based
  environment modules in CTest Scripts.

* The "FindGLEW" module now provides an interface more consistent
  with what upstream GLEW provides in its own CMake package files.

* The "FindPkgConfig" now populates "INTERFACE_LINK_OPTIONS"
  property of imported targets with other (non-library) linker flags.

* The "FindPostgreSQL" module learned to find debug and release
  variants separately.

* Modules "FindPython3", "FindPython2" and "FindPython" gained
  additional lookup strategies and controls, and a new default. See
  policy "CMP0094".

* Modules "FindPython", "FindPython2" and "FindPython3" gain a new
  target (respectively "Python::Module", "Python2::Module" and
  "Python3::Module") which can be used to develop Python modules.

* Modules "FindPython3", "FindPython2" and "FindPython" gain
  capability to control how virtual environments are handled.

* The "UseSWIG" module learned to manage alternate library names by
  passing "-interface <library_name>" for "python" language or
  "-dllimport <library_name>" for "CSharp" language to the "SWIG"
  compiler.


Generator Expressions
---------------------

* The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID",
  "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE",
  "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching
  one value from a comma-separated list.

* The "$<CUDA_COMPILER_ID:...>" and "$<CUDA_COMPILER_VERSION:...>"
  "generator expressions" were added.

* The "$<COMPILE_LANG_AND_ID:...>" generator expression was
  introduced to allow specification of compile options for target
  files based on the "CMAKE_<LANG>_COMPILER_ID" and "LANGUAGE" of each
  source file.

* A "$<FILTER:list,INCLUDE|EXCLUDE,regex>" "generator expression"
  has been added.

* A "$<REMOVE_DUPLICATES:list>" "generator expression" has been
  added.

* The "$<SHELL_PATH:...>" "generator expression" gained support for
  a list of paths.

* New "$<TARGET_FILE*>" "generator expressions" were added to
  retrieve the prefix, base name, and suffix of the file names of
  various artifacts:

  * "$<TARGET_FILE_PREFIX:...>"

  * "$<TARGET_FILE_BASE_NAME:...>"

  * "$<TARGET_FILE_SUFFIX:...>"

  * "$<TARGET_LINKER_FILE_PREFIX:...>"

  * "$<TARGET_LINKER_FILE_BASE_NAME:...>"

  * "$<TARGET_LINKER_FILE_SUFFIX:...>"

  * "$<TARGET_PDB_FILE_BASE_NAME:...>"

* The "$<TARGET_OBJECTS:...>" "generator expression" is now
  supported on "SHARED", "STATIC", "MODULE" libraries and executables.


CTest
-----

* The "ctest_submit()" command learned a new option: "BUILD_ID".
  This can be used to store the ID assigned to this build by CDash to
  a variable.

* The "ctest_update()" command learned to honor a new variable:
  "CTEST_UPDATE_VERSION_OVERRIDE". This can be used to specify the
  current version of your source tree rather than using the update
  command to discover the current version that is checked out.


CPack
-----

* The "CPack IFW Generator" gained a new
  "CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer
  stylesheet.


Deprecated and Removed Features
===============================

* The "cmake-server(7)" mode has been deprecated and will be removed
  from a future version of CMake.  Please port clients to use the
  "cmake-file-api(7)" instead.

* The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now
  deprecated.  Use the "ADDITIONAL_CLEAN_FILES" directory property
  instead.

* The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered
  deprecated. Support still exists but will be removed in future
  versions.

* The "export(PACKAGE)" command now does nothing unless enabled via
  "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".

* The "Xcode" generator now requires at least Xcode 5.

* An explicit deprecation diagnostic was added for policy "CMP0066"
  ("CMP0065" and below were already deprecated). The "cmake-
  policies(7)" manual explains that the OLD behaviors of all policies
  are deprecated and that projects should port to the NEW behaviors.


Other Changes
=============

* CMake learned how to compile C++14 with the IBM AIX XL compiler
  and the SunPro compiler and to compile C++20 with the AppleClang
  compiler.

* With MSVC-like compilers the value of "CMAKE_<LANG>_FLAGS" no
  longer contains warning flags like "/W3" by default. See policy
  "CMP0092".

* IBM Clang-based XL compilers that define "__ibmxl__" now use the
  compiler id "XLClang" instead of "XL".  See policy "CMP0089".

* The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were
  changed to ignore empty arguments with a warning instead of treating
  them as a relative path and removing the contents of the current
  directory.

From bryan.christ at gmail.com  Tue Jun  4 15:57:52 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Tue, 4 Jun 2019 14:57:52 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
Message-ID: <CAPQiZK9UQq+MOMOUrGp501sEbzL=4ePvGUBXMCaoeCKPOh50jw@mail.gmail.com>

Juan,

In my case I was looking to build and link against ncurses.  A second set
of libs got installed by homebrew so I decided to use those instead.  To
use the alternate location, I was told the following would work (and it
did).

set(CMAKE_PREFIX_PATH /usr/local/opt/ncurses)



On Mon, Jun 3, 2019 at 5:27 PM Juan E. Sanchez <juan.e.sanchez at gmail.com>
wrote:

> Hello,
>
> According to this:
> https://github.com/neovim/neovim/issues/9050
>
> It looks like macOS made it so you have to do something like this:
> open
>
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>
> for libraries and includes to be put into /usr.
>
> Regards,
>
> Juan
>
>
> On 6/3/19 5:16 PM, Bryan Christ wrote:
> > New to this mailing list so I hope I'm asking this in the right venue...
> >
> > I'm trying to port my application (a program and a shared library) to
> > OSX.  It was rather easy to modify my CMake script to go from Linux and
> > add in FreeBSD.  OSX is giving me a lot of problems though.
> >
> > First of all find_package() doesn't seem to find the ncurses.dylib
> > installed by XCode as it test for wsyncup().  For whatever reason, that
> > test fails.  The default location for the library is pretty sane
> > (/usr/lib/) but the include file for ncurses is about 9 directories deep
> > inside of XCode's install directory.  Lots of problems here so I decided
> > to look at the symbol linkage for htop and see what it does.  It links
> > to a different version that got pulled down via homebrew in
> > /usr/local/opt/ncurses/lib (and include respectively)
> >
> > Is there a way to force CMake to link to the library found there instead
> > of in /usr/lib/ ?
> >
> > --
> > Bryan
> > <><
> >
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/a5d8fa51/attachment-0001.html>

From workbench at gmx.at  Tue Jun  4 16:04:24 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 22:04:24 +0200
Subject: [CMake] General question about variable scope.
Message-ID: <7cab1ae5-cea7-9865-f5b4-7a890e0bdea1@gmx.at>

Hi everyone,


i've the following code:

macro(bsBuildLibExamples lib)
	# get all examples
	get_cmake_property(_vars VARIABLES)
	foreach(_var ${_vars})
	    string(TOUPPER ${lib} lib_upper)
	    set(WITH_LIB_${lib_upper}_EXAMPLES "")
	    if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)$")
		message(STATUS "Example found: ${CMAKE_MATCH_1}")
		list(APPEND ${WITH_LIB_${lib_upper}_EXAMPLES} ${CMAKE_MATCH_1})
              endif()
	endforeach()

     message(STATUS "Glad examples: ${WITH_LIB_GLAD_EXAMPLES}")
     message(STATUS "GLFW examples: ${WITH_LIB_GLFW_EXAMPLES}")

endmacro()


The problem is that ${WITH_LIB_${lib_upper}_EXAMPLES} is not available
anymore after the foreach, i was not able to find something in the docs
about this, i hope someone here can help me out.


best regrads!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/6d8a6190/attachment.html>

From bryan.christ at gmail.com  Tue Jun  4 16:11:44 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Tue, 4 Jun 2019 15:11:44 -0500
Subject: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored
Message-ID: <CAPQiZK_V2BjpzeBeGn74e7MrogwzNpa4yVLr2QeX3=+8fYw7_w@mail.gmail.com>

For building my project on Linux with gcc I set the following.

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

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

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

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

endif()

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

What am I doing wrong?

-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/9282be54/attachment.html>

From guy at alum.mit.edu  Tue Jun  4 16:10:05 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 4 Jun 2019 13:10:05 -0700
Subject: [CMake] Linking on OSX
In-Reply-To: <CAPQiZK9=dCg7UCA9fSJNjeRxFdfXKGTe8cQ8ogLsR-htphwsYQ@mail.gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <CAPQiZK9=dCg7UCA9fSJNjeRxFdfXKGTe8cQ8ogLsR-htphwsYQ@mail.gmail.com>
Message-ID: <574846C6-A8A4-4307-92CC-3A2CC02AC782@alum.mit.edu>

On Jun 4, 2019, at 10:56 AM, Bryan Christ <bryan.christ at gmail.com> wrote:

> Thanks for your suggestions.  I went through that thread pretty thoroughly trying all of the recommended tips and, unfortunately, nothing seemed to work.  I also tried running that open command you cited, but there are still no includes for ncurses in /usr/include or /usr/local/include.

Presumably after you ran the open command you then performed an installation of the package from the window that the command popped up?

If not, you need to do that.

From guy at alum.mit.edu  Tue Jun  4 16:24:24 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 4 Jun 2019 13:24:24 -0700
Subject: [CMake] Linking on OSX
In-Reply-To: <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
Message-ID: <AEF3A2ED-868D-465C-A342-15DF89E42406@alum.mit.edu>

On Jun 3, 2019, at 3:27 PM, Juan E. Sanchez <juan.e.sanchez at gmail.com> wrote:

> It looks like macOS made it so you have to do something like this:
> open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
> 
> for libraries and includes to be put into /usr.

*Libraries* should exist in /usr/lib regardless of whether you do that, or even whether you have Xcode, or the command-line developer tools, installed - if you don't have the shared libraries in /usr/lib, programs using the libraries won't work, and programs shipped with macOS use, at minimum, libSystem, and may use other libraries.  vi, for example, uses the ncurses library.

It's the *headers* that aren't installed in /usr/include by default.  The compiler *should* look in the directory where they're installed, however.

Note that macOS 10.15 Catalina apparently has a separate read-only volume that contains all the executables and libraries, and presumably including /usr, so it may be *impossible* to arrange, on 10.15, that there be a /usr/include directory.

From bryan.christ at gmail.com  Tue Jun  4 16:33:53 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Tue, 4 Jun 2019 15:33:53 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <AEF3A2ED-868D-465C-A342-15DF89E42406@alum.mit.edu>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <AEF3A2ED-868D-465C-A342-15DF89E42406@alum.mit.edu>
Message-ID: <CAPQiZK-ZK7gkRHEFt+jTXR=f=kGBgARyu=CRV5+QygwP-iJX1w@mail.gmail.com>

Guy,

I would agree with you, but I've been told that OSX is moving away from
it's Unix heritage and placing libraries in non-traditional locations (not
/usr or /usr/local) and that's going to be increasingly the norm in the
future.

https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja


On Tue, Jun 4, 2019 at 3:24 PM Guy Harris <guy at alum.mit.edu> wrote:

> On Jun 3, 2019, at 3:27 PM, Juan E. Sanchez <juan.e.sanchez at gmail.com>
> wrote:
>
> > It looks like macOS made it so you have to do something like this:
> > open
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
> >
> > for libraries and includes to be put into /usr.
>
> *Libraries* should exist in /usr/lib regardless of whether you do that, or
> even whether you have Xcode, or the command-line developer tools, installed
> - if you don't have the shared libraries in /usr/lib, programs using the
> libraries won't work, and programs shipped with macOS use, at minimum,
> libSystem, and may use other libraries.  vi, for example, uses the ncurses
> library.
>
> It's the *headers* that aren't installed in /usr/include by default.  The
> compiler *should* look in the directory where they're installed, however.
>
> Note that macOS 10.15 Catalina apparently has a separate read-only volume
> that contains all the executables and libraries, and presumably including
> /usr, so it may be *impossible* to arrange, on 10.15, that there be a
> /usr/include directory.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/ad7d13e7/attachment.html>

From guy at alum.mit.edu  Tue Jun  4 16:52:15 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 4 Jun 2019 13:52:15 -0700
Subject: [CMake] Linking on OSX
In-Reply-To: <CAPQiZK-ZK7gkRHEFt+jTXR=f=kGBgARyu=CRV5+QygwP-iJX1w@mail.gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <AEF3A2ED-868D-465C-A342-15DF89E42406@alum.mit.edu>
 <CAPQiZK-ZK7gkRHEFt+jTXR=f=kGBgARyu=CRV5+QygwP-iJX1w@mail.gmail.com>
Message-ID: <E57E1741-E055-422F-8788-21CB9A2F7995@alum.mit.edu>

On Jun 4, 2019, at 1:33 PM, Bryan Christ <bryan.christ at gmail.com> wrote:

> I would agree with you, but I've been told that OSX is moving away from it's Unix heritage and placing libraries in non-traditional locations (not /usr or /usr/local) and that's going to be increasingly the norm in the future.
> 
> https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja

That talks about *headers*, not *libraries*.  (Don't be confused by the "/Library" used in some path names in that item - /Library has more than libraries in it.)

macOS has, all the way back to when it was called "Mac OS X", had a notion of "frameworks", which are not installed under /usr/lib, and that contain dynamically-linked shared libraries; the higher-level Cocoa APIs, for example, are provided as frameworks, as are C libraries such as Core Foundation.

UNIX APIs, however, are, and have always been, implemented as regular dynamically-linked shared libraries under /usr/lib.

The executable image for Microsoft Word for Mac has the strings

	/usr/lib/libz.1.dylib
	/usr/lib/libsqlite3.dylib
	/usr/lib/libobjc.A.dylib
	/usr/lib/libc++.1.dylib
	/usr/lib/libSystem.B.dylib

built into it as library paths; if Apple were to decide to put UNIX libraries somewhere other than /usr/lib, and not have a /usr/lib symbolic link pointing to the new location, the run-time linker would have to extract the final component of paths beginning with /usr/lib and treat them as if they pointed to a library in the new location, instead; they could probably do that, but it's not clear what the point of doing so would be.

So if somebody were to claim that macOS will be putting *UNIX libraries* (as opposed to macOS frameworks, or header files) in some location other than /usr/lib, I'd have to ask for some pretty solid evidence to believe that claim; I haven't seen any such evidence so far.

From workbench at gmx.at  Tue Jun  4 17:14:09 2019
From: workbench at gmx.at (Steven Truppe)
Date: Tue, 4 Jun 2019 23:14:09 +0200
Subject: [CMake] Question about looping inside a macro.
Message-ID: <2c507fc8-4210-4328-aeb0-8c9bd516471b@gmx.at>

Hi everyone, like you know i'm relative new the cmake and i'm working my
way through the book and the documentation but there is something that i
don't understand in the docs.

I just want to write a macro that uses as first argument a list and then
iterates over it.

The docs show the example:

macro(_BAR)
   foreach(arg IN LISTS ARGN)
     [...]
   endforeach()
endmacro()

So i wrote this macro:

macro(bsPrintList list)

 ??? foreach(l IN LISTS ARGN)

 ??? ??? message(STATUS "List entry: ${l})

 ??? endforeach()

endmacro()


I tried all sorts of combinations like foreach(l ${list}) etc. but come
to no result =(.


This is a really easy questin so i hope someone can explain to me what
i'm doing wrong here, next part i'm going to learn are functions and how
to handle their arguments...


best regards!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/2149ea53/attachment-0001.html>

From bryan.christ at gmail.com  Tue Jun  4 17:15:58 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Tue, 4 Jun 2019 16:15:58 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <574846C6-A8A4-4307-92CC-3A2CC02AC782@alum.mit.edu>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <CAPQiZK9=dCg7UCA9fSJNjeRxFdfXKGTe8cQ8ogLsR-htphwsYQ@mail.gmail.com>
 <574846C6-A8A4-4307-92CC-3A2CC02AC782@alum.mit.edu>
Message-ID: <CAPQiZK92mXBfALRaqeQwvV7ZAE=Uf=F+mcy+S204-KBAES_7tA@mail.gmail.com>

Yes.  Unfortunately, I still don't get the wide version of ncurses so I
have to point elsewhere.  But even assuming that solved my problem , I
understand the procedure is a stop-gap and might not eventually be
supported.

On Tue, Jun 4, 2019 at 4:01 PM Guy Harris <guy at alum.mit.edu> wrote:

> On Jun 4, 2019, at 10:56 AM, Bryan Christ <bryan.christ at gmail.com> wrote:
>
> > Thanks for your suggestions.  I went through that thread pretty
> thoroughly trying all of the recommended tips and, unfortunately, nothing
> seemed to work.  I also tried running that open command you cited, but
> there are still no includes for ncurses in /usr/include or
> /usr/local/include.
>
> Presumably after you ran the open command you then performed an
> installation of the package from the window that the command popped up?
>
> If not, you need to do that.
>


-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/c6d9eedf/attachment.html>

From bryan.christ at gmail.com  Tue Jun  4 17:27:02 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Tue, 4 Jun 2019 16:27:02 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <E57E1741-E055-422F-8788-21CB9A2F7995@alum.mit.edu>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <AEF3A2ED-868D-465C-A342-15DF89E42406@alum.mit.edu>
 <CAPQiZK-ZK7gkRHEFt+jTXR=f=kGBgARyu=CRV5+QygwP-iJX1w@mail.gmail.com>
 <E57E1741-E055-422F-8788-21CB9A2F7995@alum.mit.edu>
Message-ID: <CAPQiZK-Wp3+pi1Oy8wWk_zP0MBA47W73eZLCDtESJFmymeofFA@mail.gmail.com>

Thanks for the explanation.  Yes.  The use of the term Library certainly
added to my confusion.  I've been coding on Linux for 20 and the "proper"
way of doing things on Mac is a bit elusive to me as I stumble around.



On Tue, Jun 4, 2019 at 4:21 PM Guy Harris <guy at alum.mit.edu> wrote:

> On Jun 4, 2019, at 1:33 PM, Bryan Christ <bryan.christ at gmail.com> wrote:
>
> > I would agree with you, but I've been told that OSX is moving away from
> it's Unix heritage and placing libraries in non-traditional locations (not
> /usr or /usr/local) and that's going to be increasingly the norm in the
> future.
> >
> >
> https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja
>
> That talks about *headers*, not *libraries*.  (Don't be confused by the
> "/Library" used in some path names in that item - /Library has more than
> libraries in it.)
>
> macOS has, all the way back to when it was called "Mac OS X", had a notion
> of "frameworks", which are not installed under /usr/lib, and that contain
> dynamically-linked shared libraries; the higher-level Cocoa APIs, for
> example, are provided as frameworks, as are C libraries such as Core
> Foundation.
>
> UNIX APIs, however, are, and have always been, implemented as regular
> dynamically-linked shared libraries under /usr/lib.
>
> The executable image for Microsoft Word for Mac has the strings
>
>         /usr/lib/libz.1.dylib
>         /usr/lib/libsqlite3.dylib
>         /usr/lib/libobjc.A.dylib
>         /usr/lib/libc++.1.dylib
>         /usr/lib/libSystem.B.dylib
>
> built into it as library paths; if Apple were to decide to put UNIX
> libraries somewhere other than /usr/lib, and not have a /usr/lib symbolic
> link pointing to the new location, the run-time linker would have to
> extract the final component of paths beginning with /usr/lib and treat them
> as if they pointed to a library in the new location, instead; they could
> probably do that, but it's not clear what the point of doing so would be.
>
> So if somebody were to claim that macOS will be putting *UNIX libraries*
> (as opposed to macOS frameworks, or header files) in some location other
> than /usr/lib, I'd have to ask for some pretty solid evidence to believe
> that claim; I haven't seen any such evidence so far.
>


-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/6fca5058/attachment.html>

From guy at alum.mit.edu  Tue Jun  4 17:36:27 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 4 Jun 2019 14:36:27 -0700
Subject: [CMake] Linking on OSX
In-Reply-To: <CAPQiZK-Wp3+pi1Oy8wWk_zP0MBA47W73eZLCDtESJFmymeofFA@mail.gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <AEF3A2ED-868D-465C-A342-15DF89E42406@alum.mit.edu>
 <CAPQiZK-ZK7gkRHEFt+jTXR=f=kGBgARyu=CRV5+QygwP-iJX1w@mail.gmail.com>
 <E57E1741-E055-422F-8788-21CB9A2F7995@alum.mit.edu>
 <CAPQiZK-Wp3+pi1Oy8wWk_zP0MBA47W73eZLCDtESJFmymeofFA@mail.gmail.com>
Message-ID: <22CC8976-F136-405B-9443-A69C890B1D1B@alum.mit.edu>

On Jun 4, 2019, at 2:27 PM, Bryan Christ <bryan.christ at gmail.com> wrote:

> Thanks for the explanation.  Yes.  The use of the term Library certainly added to my confusion.  I've been coding on Linux for 20 and the "proper" way of doing things on Mac is a bit elusive to me as I stumble around.

Yeah, it must be weird going from a system that stuffs libraries in /usr/lib64 to a system that stuffs them in /usr/lib. :-)

(There's no need to put 32-bit and 64-bit libraries in separate directories if you can put the 32-bit and 64-bit versions of a library in the same file, as you can in Darwin.

But the real point is that every UN*X has its own quirks, and somebody might find the UN*X with which you're most familiar to be the quirky one.  If you're going to do cross-platform UN*X programming, be prepared to have assumptions about UN*X, made based on the platform or platforms with which you're familiar, to be violated by some other UN*X.)

From bruce.r.stephens at gmail.com  Tue Jun  4 17:36:24 2019
From: bruce.r.stephens at gmail.com (Bruce Stephens)
Date: Tue, 4 Jun 2019 22:36:24 +0100
Subject: [CMake] Question about looping inside a macro.
In-Reply-To: <2c507fc8-4210-4328-aeb0-8c9bd516471b@gmx.at>
References: <2c507fc8-4210-4328-aeb0-8c9bd516471b@gmx.at>
Message-ID: <CAMqww3T9J8zotSAa+yX9A8Y+x3PxTs4oKvHTahFhUOF=Z0fN6w@mail.gmail.com>

This works:
macro(bsPrintList)
  foreach(l ${ARGN})
    message(STATUS "List entry: ${l}")
  endforeach()
endmacro()

bsPrintList(foo bar baz)

On Tue, 4 Jun 2019 at 22:14, Steven Truppe <workbench at gmx.at> wrote:
>
> Hi everyone, like you know i'm relative new the cmake and i'm working my way through the book and the documentation but there is something that i don't understand in the docs.
>
> I just want to write a macro that uses as first argument a list and then iterates over it.
>
> The docs show the example:
>
> macro(_BAR)
>   foreach(arg IN LISTS ARGN)
>     [...]
>   endforeach()
> endmacro()
>
> So i wrote this macro:
>
> macro(bsPrintList list)
>
>     foreach(l IN LISTS ARGN)
>
>         message(STATUS "List entry: ${l})
>
>     endforeach()
>
> endmacro()
>
>
> I tried all sorts of combinations like foreach(l ${list}) etc. but come to no result =(.
>
>
> This is a really easy questin so i hope someone can explain to me what i'm doing wrong here, next part i'm going to learn are functions and how to handle their arguments...
>
>
> best regards!
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From bryan.christ at gmail.com  Tue Jun  4 17:43:15 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Tue, 4 Jun 2019 16:43:15 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <22CC8976-F136-405B-9443-A69C890B1D1B@alum.mit.edu>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <AEF3A2ED-868D-465C-A342-15DF89E42406@alum.mit.edu>
 <CAPQiZK-ZK7gkRHEFt+jTXR=f=kGBgARyu=CRV5+QygwP-iJX1w@mail.gmail.com>
 <E57E1741-E055-422F-8788-21CB9A2F7995@alum.mit.edu>
 <CAPQiZK-Wp3+pi1Oy8wWk_zP0MBA47W73eZLCDtESJFmymeofFA@mail.gmail.com>
 <22CC8976-F136-405B-9443-A69C890B1D1B@alum.mit.edu>
Message-ID: <CAPQiZK-Seu13GbRaAExE2fdPM40TqntSS3K5Vm3B16Vew_qBLA@mail.gmail.com>

Indeed.  They all have their nuances :)

On Tue, Jun 4, 2019 at 4:36 PM Guy Harris <guy at alum.mit.edu> wrote:

> On Jun 4, 2019, at 2:27 PM, Bryan Christ <bryan.christ at gmail.com> wrote:
>
> > Thanks for the explanation.  Yes.  The use of the term Library certainly
> added to my confusion.  I've been coding on Linux for 20 and the "proper"
> way of doing things on Mac is a bit elusive to me as I stumble around.
>
> Yeah, it must be weird going from a system that stuffs libraries in
> /usr/lib64 to a system that stuffs them in /usr/lib. :-)
>
> (There's no need to put 32-bit and 64-bit libraries in separate
> directories if you can put the 32-bit and 64-bit versions of a library in
> the same file, as you can in Darwin.
>
> But the real point is that every UN*X has its own quirks, and somebody
> might find the UN*X with which you're most familiar to be the quirky one.
> If you're going to do cross-platform UN*X programming, be prepared to have
> assumptions about UN*X, made based on the platform or platforms with which
> you're familiar, to be violated by some other UN*X.)



-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/fc25837a/attachment.html>

From tomfinegan at google.com  Tue Jun  4 18:24:29 2019
From: tomfinegan at google.com (Tom Finegan)
Date: Tue, 4 Jun 2019 15:24:29 -0700
Subject: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored
In-Reply-To: <CAPQiZK_V2BjpzeBeGn74e7MrogwzNpa4yVLr2QeX3=+8fYw7_w@mail.gmail.com>
References: <CAPQiZK_V2BjpzeBeGn74e7MrogwzNpa4yVLr2QeX3=+8fYw7_w@mail.gmail.com>
Message-ID: <CABRgNyxdcNE2k24rWHZ7ec7SSJ-w4yCxYTeMUEAmXwxDZjPNrg@mail.gmail.com>

I think you want CMAKE_SHARED_LINKER_FLAGS:

https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LINKER_FLAGS.html

You can also use target_link_libraries to pass linker flags:

https://cmake.org/cmake/help/latest/command/target_link_libraries.html

On Tue, Jun 4, 2019 at 1:12 PM Bryan Christ <bryan.christ at gmail.com> wrote:

> For building my project on Linux with gcc I set the following.
>
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--no-as-needed")
>
> Later, if, the system appears to be OSX, I change it:
>
> if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
>
>     set(CMAKE_EXE_LINKER_FLAGS "-Wl,-undefined -Wl,dynamic_lookup")
>     set(CMAKE_PREFIX_PATH /usr/local/opt/ncurses)
>
> endif()
>
> However, when creating the shared object, linking fails.  The flags are
> not being passed to clang as expected.  When I dive into
> CMakeFile/vterm-shared.dir/link.txt I confirm that the wrong flags are
> there.
>
> What am I doing wrong?
>
> --
> Bryan
> <><
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190604/62cf7415/attachment-0001.html>

From workbench at gmx.at  Tue Jun  4 18:47:15 2019
From: workbench at gmx.at (Steven Truppe)
Date: Wed, 5 Jun 2019 00:47:15 +0200
Subject: [CMake] Troubles with small CMakeLists.txt
Message-ID: <d86dc424-4d67-108d-d639-20a8ef0033dd@gmx.at>

Hi everyone,

i finaly have solved the issues i had and now have the working code on:
https://wandbox.org/permlink/ujEH8F91SVzMyt1D


The problem is that the i only get the last result as output, he create
the variables and stores them (i tested with cmake_print_variables) but
at the end the resulting variables are empty - only the last one is
correct....

I hope someone here can help.


best regards!


From workbench at gmx.at  Tue Jun  4 18:56:16 2019
From: workbench at gmx.at (Steven Truppe)
Date: Wed, 5 Jun 2019 00:56:16 +0200
Subject: [CMake] Troubles with small CMakeLists.txt
In-Reply-To: <d86dc424-4d67-108d-d639-20a8ef0033dd@gmx.at>
References: <d86dc424-4d67-108d-d639-20a8ef0033dd@gmx.at>
Message-ID: <9d9f743a-22b2-e549-9fc1-3d3dac776014@gmx.at>

I've made the code more readable and easy to understand so you don't
have to read through all the code:
https://wandbox.org/permlink/qp7ScGBeMOtolfxb

On 05.06.19 00:47, Steven Truppe wrote:
> Hi everyone,
>
> i finaly have solved the issues i had and now have the working code on:
> https://wandbox.org/permlink/ujEH8F91SVzMyt1D
>
>
> The problem is that the i only get the last result as output, he create
> the variables and stores them (i tested with cmake_print_variables) but
> at the end the resulting variables are empty - only the last one is
> correct....
>
> I hope someone here can help.
>
>
> best regards!
>

From juan.e.sanchez at gmail.com  Tue Jun  4 18:57:26 2019
From: juan.e.sanchez at gmail.com (Juan E. Sanchez)
Date: Tue, 4 Jun 2019 17:57:26 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <CAPQiZK9=dCg7UCA9fSJNjeRxFdfXKGTe8cQ8ogLsR-htphwsYQ@mail.gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <CAPQiZK9=dCg7UCA9fSJNjeRxFdfXKGTe8cQ8ogLsR-htphwsYQ@mail.gmail.com>
Message-ID: <41e98586-8f89-914b-d926-af2ea3757b6b@gmail.com>

Hello,

It looks like you are making progress.  Note that to use the gcc-8 and 
g++-8 compilers from brew, you need to have include files in 
/usr/include.  Otherwise you get strange errors about missing _stdio.h, 
etc.  I believe in another thread, someone suggests how to make sure the 
headers get put in the right place.

I looked and found curses.h (not ncurses.h) here.
/usr/include/curses.h.

Regards,

Juan


On 6/4/19 12:56 PM, Bryan Christ wrote:
> Juan,
> 
> Thanks for your suggestions.? I went through that thread pretty 
> thoroughly trying all of the recommended tips and, unfortunately, 
> nothing seemed to work.? I also tried running that open command you 
> cited, but there are still no includes for ncurses in /usr/include or 
> /usr/local/include.? In fact /usr/include doesn't even exist on this 
> system (mojave).
> 
> On Mon, Jun 3, 2019 at 5:27 PM Juan E. Sanchez <juan.e.sanchez at gmail.com 
> <mailto:juan.e.sanchez at gmail.com>> wrote:
> 
>     Hello,
> 
>     According to this:
>     https://github.com/neovim/neovim/issues/9050
> 
>     It looks like macOS made it so you have to do something like this:
>     open
>     /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
> 
>     for libraries and includes to be put into /usr.
> 
>     Regards,
> 
>     Juan
> 
> 
>     On 6/3/19 5:16 PM, Bryan Christ wrote:
>      > New to this mailing list so I hope I'm asking this in the right
>     venue...
>      >
>      > I'm trying to port my application (a program and a shared
>     library) to
>      > OSX.? It was rather easy to modify my CMake script to go from
>     Linux and
>      > add in FreeBSD.? OSX is giving me a lot of problems though.
>      >
>      > First of all find_package() doesn't seem to find the ncurses.dylib
>      > installed by XCode as it test for wsyncup().? For whatever
>     reason, that
>      > test fails.? The default location for the library is pretty sane
>      > (/usr/lib/) but the include file for ncurses?is about 9
>     directories deep
>      > inside of XCode's install directory.? Lots of problems here so I
>     decided
>      > to look at the symbol linkage for htop and see what it does.? It
>     links
>      > to a different version that got pulled down via homebrew in
>      > /usr/local/opt/ncurses/lib (and include respectively)
>      >
>      > Is there a way to force CMake to link to the library found there
>     instead
>      > of in /usr/lib/ ?
>      >
>      > --
>      > Bryan
>      > <><
>      >
> 
>     -- 
> 
>     Powered by www.kitware.com <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:
>     https://cmake.org/mailman/listinfo/cmake
> 
> 
> 
> -- 
> Bryan
> <><


From Stephan.Szabo at sony.com  Tue Jun  4 19:13:35 2019
From: Stephan.Szabo at sony.com (Stephan.Szabo at sony.com)
Date: Tue, 4 Jun 2019 23:13:35 +0000
Subject: [CMake] Troubles with small CMakeLists.txt
In-Reply-To: <9d9f743a-22b2-e549-9fc1-3d3dac776014@gmx.at>
References: <d86dc424-4d67-108d-d639-20a8ef0033dd@gmx.at>
 <9d9f743a-22b2-e549-9fc1-3d3dac776014@gmx.at>
Message-ID: <6DC96A862F4DA14CB85E89B984CCB288015527F5B2@USCULXMSG10.am.sony.com>

Hi,

Looking at the cmake there, your bsBuildLibExamples macro starts off by doing
   set(WITH_LIB_${lib_upper}_EXAMPLES "")
but lib_upper isn't set to match the new value of lib until later inside the foreach.
So it seems like you're resetting the value of the previous iteration.

Moving the 
  string(TOUPPER ${lib} lib_upper)
to the top of the macro seems to make all the variables show up.

Regards,
Stephan

-----Original Message-----
From: CMake <cmake-bounces at cmake.org> On Behalf Of Steven Truppe
Sent: Tuesday, June 4, 2019 3:56 PM
To: cmake at cmake.org
Subject: Re: [CMake] Troubles with small CMakeLists.txt

I've made the code more readable and easy to understand so you don't have to read through all the code:
https://wandbox.org/permlink/qp7ScGBeMOtolfxb

On 05.06.19 00:47, Steven Truppe wrote:
> Hi everyone,
>
> i finaly have solved the issues i had and now have the working code on:
> https://wandbox.org/permlink/ujEH8F91SVzMyt1D
>
>
> The problem is that the i only get the last result as output, he 
> create the variables and stores them (i tested with 
> cmake_print_variables) but at the end the resulting variables are 
> empty - only the last one is correct....
>
> I hope someone here can help.
>
>
> best regards!
>
-- 

Powered by www.kitware.com

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

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

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

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

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

From workbench at gmx.at  Tue Jun  4 19:32:39 2019
From: workbench at gmx.at (Steven Truppe)
Date: Wed, 5 Jun 2019 01:32:39 +0200
Subject: [CMake] Troubles with small CMakeLists.txt
In-Reply-To: <6DC96A862F4DA14CB85E89B984CCB288015527F5B2@USCULXMSG10.am.sony.com>
References: <d86dc424-4d67-108d-d639-20a8ef0033dd@gmx.at>
 <9d9f743a-22b2-e549-9fc1-3d3dac776014@gmx.at>
 <6DC96A862F4DA14CB85E89B984CCB288015527F5B2@USCULXMSG10.am.sony.com>
Message-ID: <4de11592-d260-76c6-3840-718d8c6db0f8@gmx.at>

That was the issue - thanks alot for you help, i'm sitting now for over
5 hours in front of cmake and my eyes need some rest (and more brain
needs more cmake knowledge:).


best regards!

On 05.06.19 01:13, Stephan.Szabo at sony.com wrote:
> Hi,
>
> Looking at the cmake there, your bsBuildLibExamples macro starts off by doing
>     set(WITH_LIB_${lib_upper}_EXAMPLES "")
> but lib_upper isn't set to match the new value of lib until later inside the foreach.
> So it seems like you're resetting the value of the previous iteration.
>
> Moving the
>    string(TOUPPER ${lib} lib_upper)
> to the top of the macro seems to make all the variables show up.
>
> Regards,
> Stephan
>
> -----Original Message-----
> From: CMake <cmake-bounces at cmake.org> On Behalf Of Steven Truppe
> Sent: Tuesday, June 4, 2019 3:56 PM
> To: cmake at cmake.org
> Subject: Re: [CMake] Troubles with small CMakeLists.txt
>
> I've made the code more readable and easy to understand so you don't have to read through all the code:
> https://wandbox.org/permlink/qp7ScGBeMOtolfxb
>
> On 05.06.19 00:47, Steven Truppe wrote:
>> Hi everyone,
>>
>> i finaly have solved the issues i had and now have the working code on:
>> https://wandbox.org/permlink/ujEH8F91SVzMyt1D
>>
>>
>> The problem is that the i only get the last result as output, he
>> create the variables and stores them (i tested with
>> cmake_print_variables) but at the end the resulting variables are
>> empty - only the last one is correct....
>>
>> I hope someone here can help.
>>
>>
>> best regards!
>>

From mathieu.malaterre at gmail.com  Wed Jun  5 06:00:19 2019
From: mathieu.malaterre at gmail.com (Mathieu Malaterre)
Date: Wed, 5 Jun 2019 12:00:19 +0200
Subject: [CMake] Conditional install() rules based on CPack generator
Message-ID: <CA+7wUsy61C4QKEuQ7mb66JKmKQU9_vWLo0mV7Za_B-9LK0CETg@mail.gmail.com>

Hi there,

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

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

where:

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

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

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

Thanks,

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

-- 
Mathieu

From volker.enderlein at ifm-chemnitz.de  Wed Jun  5 07:53:50 2019
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Wed, 5 Jun 2019 13:53:50 +0200
Subject: [CMake] Project warning since 3.15.0-rc1
Message-ID: <f7c64278-99aa-e8ca-ceae-668c6f0533ec@ifm-chemnitz.de>

Hi,


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

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

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

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

 ??? project(ProjectName)

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

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


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


Cheers, Volker



From ggarra13 at gmail.com  Wed Jun  5 08:27:51 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Wed, 5 Jun 2019 09:27:51 -0300
Subject: [CMake] ADD_CUSTOM_TARGET USES_TERMINAL not printing out stuff
Message-ID: <4278bc16-93e4-ccd0-730e-4deade7e9d82@gmail.com>

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

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

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


From brad.king at kitware.com  Wed Jun  5 10:51:14 2019
From: brad.king at kitware.com (Brad King)
Date: Wed, 5 Jun 2019 10:51:14 -0400
Subject: [CMake] ADD_CUSTOM_TARGET USES_TERMINAL not printing out stuff
In-Reply-To: <4278bc16-93e4-ccd0-730e-4deade7e9d82@gmail.com>
References: <4278bc16-93e4-ccd0-730e-4deade7e9d82@gmail.com>
Message-ID: <5d7435df-6ec1-0498-1920-d167df445e16@kitware.com>

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

Thanks for trying the release candidate!

However, I cannot reproduce this in a simple example:


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

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

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

$ cmake .. -GNinja

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

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

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

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

Thanks,
-Brad

From ggarra13 at gmail.com  Wed Jun  5 12:27:29 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Wed, 5 Jun 2019 13:27:29 -0300
Subject: [CMake] ADD_CUSTOM_TARGET USES_TERMINAL not printing out stuff
In-Reply-To: <5d7435df-6ec1-0498-1920-d167df445e16@kitware.com>
References: <4278bc16-93e4-ccd0-730e-4deade7e9d82@gmail.com>
 <5d7435df-6ec1-0498-1920-d167df445e16@kitware.com>
Message-ID: <e0f40ea0-689b-2693-3ee3-1739c42f3f37@gmail.com>



El 05/06/19 a las 11:51, Brad King escribi?:
> On 6/5/19 8:27 AM, Gonzalo Garramu?o wrote:
>> This used to print out all that cpack was doing while it was doing it.
>> Now with v3.15.0-rc1 it just sits there and outputs all the text at the
>> end when it finishes, which sucks as it looks like it has hung.
> Thanks for trying the release candidate!
>
> However, I cannot reproduce this in a simple example:
>
Thanks Brad, for trying it out.  The problem seems to be related to 
cpack.  I posted a more complete example with a bash wrapup script. You 
will still need to fill in the bin directory of the build with something 
big, so cpack will take a while compressing it.

From bryan.christ at gmail.com  Wed Jun  5 12:28:36 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Wed, 5 Jun 2019 11:28:36 -0500
Subject: [CMake] Linking on OSX
In-Reply-To: <41e98586-8f89-914b-d926-af2ea3757b6b@gmail.com>
References: <CAPQiZK8u+CFS+hD6N0QB2nh9LfKi0TPgTLC2eUfavP7w29teUg@mail.gmail.com>
 <d53c88a2-06ad-bd71-a64f-5bea4cd226d5@gmail.com>
 <CAPQiZK9=dCg7UCA9fSJNjeRxFdfXKGTe8cQ8ogLsR-htphwsYQ@mail.gmail.com>
 <41e98586-8f89-914b-d926-af2ea3757b6b@gmail.com>
Message-ID: <CAPQiZK_k2SK5N5hcpgi1mbrik-FMwe8M7NSNAj002kxcoh4Ghw@mail.gmail.com>

Yes.  Unfortunately the version of curses which is supplied by XCode
doesn't include the wide character support so I have to point elsewhere.

On Tue, Jun 4, 2019 at 5:57 PM Juan E. Sanchez <juan.e.sanchez at gmail.com>
wrote:

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

-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190605/06402ada/attachment.html>

From bryan.christ at gmail.com  Wed Jun  5 12:29:05 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Wed, 5 Jun 2019 11:29:05 -0500
Subject: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored
In-Reply-To: <CABRgNyxdcNE2k24rWHZ7ec7SSJ-w4yCxYTeMUEAmXwxDZjPNrg@mail.gmail.com>
References: <CAPQiZK_V2BjpzeBeGn74e7MrogwzNpa4yVLr2QeX3=+8fYw7_w@mail.gmail.com>
 <CABRgNyxdcNE2k24rWHZ7ec7SSJ-w4yCxYTeMUEAmXwxDZjPNrg@mail.gmail.com>
Message-ID: <CAPQiZK9rGjuPFEyc-TFPcBFYN9TcJnsw6OR3CT3HhVwXGsBp8A@mail.gmail.com>

Tom,

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

On Tue, Jun 4, 2019 at 5:24 PM Tom Finegan <tomfinegan at google.com> wrote:

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

-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190605/d348b25e/attachment.html>

From tomfinegan at google.com  Wed Jun  5 13:12:55 2019
From: tomfinegan at google.com (Tom Finegan)
Date: Wed, 5 Jun 2019 10:12:55 -0700
Subject: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored
In-Reply-To: <CAPQiZK9rGjuPFEyc-TFPcBFYN9TcJnsw6OR3CT3HhVwXGsBp8A@mail.gmail.com>
References: <CAPQiZK_V2BjpzeBeGn74e7MrogwzNpa4yVLr2QeX3=+8fYw7_w@mail.gmail.com>
 <CABRgNyxdcNE2k24rWHZ7ec7SSJ-w4yCxYTeMUEAmXwxDZjPNrg@mail.gmail.com>
 <CAPQiZK9rGjuPFEyc-TFPcBFYN9TcJnsw6OR3CT3HhVwXGsBp8A@mail.gmail.com>
Message-ID: <CABRgNyyAo1G3VEOauSYUH90c6d9BtKVUSvZSNU9d+a-b5R3zVw@mail.gmail.com>

On Wed, Jun 5, 2019 at 9:29 AM Bryan Christ <bryan.christ at gmail.com> wrote:

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

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

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


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

From bryan.christ at gmail.com  Wed Jun  5 13:21:40 2019
From: bryan.christ at gmail.com (Bryan Christ)
Date: Wed, 5 Jun 2019 12:21:40 -0500
Subject: [CMake] Trouble with CMAKE_EXE_LINKER_FLAGS not honored
In-Reply-To: <CABRgNyyAo1G3VEOauSYUH90c6d9BtKVUSvZSNU9d+a-b5R3zVw@mail.gmail.com>
References: <CAPQiZK_V2BjpzeBeGn74e7MrogwzNpa4yVLr2QeX3=+8fYw7_w@mail.gmail.com>
 <CABRgNyxdcNE2k24rWHZ7ec7SSJ-w4yCxYTeMUEAmXwxDZjPNrg@mail.gmail.com>
 <CAPQiZK9rGjuPFEyc-TFPcBFYN9TcJnsw6OR3CT3HhVwXGsBp8A@mail.gmail.com>
 <CABRgNyyAo1G3VEOauSYUH90c6d9BtKVUSvZSNU9d+a-b5R3zVw@mail.gmail.com>
Message-ID: <CAPQiZK9FVAt0phh_PDfvDiLuYBRgTiUoZU0S_Kn85tkwSLZtSw@mail.gmail.com>

Tom,

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

Ty!

On Wed, Jun 5, 2019 at 12:13 PM Tom Finegan <tomfinegan at google.com> wrote:

>
> On Wed, Jun 5, 2019 at 9:29 AM Bryan Christ <bryan.christ at gmail.com>
> wrote:
>
>> Tom,
>>
>> I'll give that a try.  Can that variable be changed after project() is
>> called?
>>
>
> Yes, you should be able to change it at any point in your CMake script(s).
>
> Remember that CMAKE_<linker type>_LINKER_FLAGS will effect all targets.
> Restricting your settings changes to the targets for which they are
> intended is usually better than touching variables like
> CMAKE_SHARED_LINKER_FLAGS.  You may have better results using
> target_link_libraries() to set your flags.
>
>
>>
>> On Tue, Jun 4, 2019 at 5:24 PM Tom Finegan <tomfinegan at google.com> wrote:
>>
>>> I think you want CMAKE_SHARED_LINKER_FLAGS:
>>>
>>>
>>> https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LINKER_FLAGS.html
>>>
>>> You can also use target_link_libraries to pass linker flags:
>>>
>>> https://cmake.org/cmake/help/latest/command/target_link_libraries.html
>>>
>>> On Tue, Jun 4, 2019 at 1:12 PM Bryan Christ <bryan.christ at gmail.com>
>>> wrote:
>>>
>>>> For building my project on Linux with gcc I set the following.
>>>>
>>>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
>>>> -Wl,--no-as-needed")
>>>>
>>>> Later, if, the system appears to be OSX, I change it:
>>>>
>>>> if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
>>>>
>>>>     set(CMAKE_EXE_LINKER_FLAGS "-Wl,-undefined -Wl,dynamic_lookup")
>>>>     set(CMAKE_PREFIX_PATH /usr/local/opt/ncurses)
>>>>
>>>> endif()
>>>>
>>>> However, when creating the shared object, linking fails.  The flags are
>>>> not being passed to clang as expected.  When I dive into
>>>> CMakeFile/vterm-shared.dir/link.txt I confirm that the wrong flags are
>>>> there.
>>>>
>>>> What am I doing wrong?
>>>>
>>>> --
>>>> Bryan
>>>> <><
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For
>>>> more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://cmake.org/mailman/listinfo/cmake
>>>>
>>>
>>
>> --
>> Bryan
>> <><
>>
>

-- 
Bryan
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190605/2cd06e1f/attachment.html>

From eric.noulard at gmail.com  Wed Jun  5 18:27:42 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 6 Jun 2019 00:27:42 +0200
Subject: [CMake] Conditional install() rules based on CPack generator
In-Reply-To: <CA+7wUsy61C4QKEuQ7mb66JKmKQU9_vWLo0mV7Za_B-9LK0CETg@mail.gmail.com>
References: <CA+7wUsy61C4QKEuQ7mb66JKmKQU9_vWLo0mV7Za_B-9LK0CETg@mail.gmail.com>
Message-ID: <CAPASGLpOm8Fc6bNaqfX-WUH_XUn1j2t7q11-R5iNoqsoo+DVNg@mail.gmail.com>

Le mer. 5 juin 2019 ? 12:00, Mathieu Malaterre <mathieu.malaterre at gmail.com>
a ?crit :

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

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

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

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

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

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

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

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

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


Eric



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


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190606/d7621d81/attachment.html>

From workbench at gmx.at  Thu Jun  6 10:51:24 2019
From: workbench at gmx.at (Steven Truppe)
Date: Thu, 6 Jun 2019 16:51:24 +0200
Subject: [CMake] A bit harder question:
Message-ID: <57dfed98-5f38-f517-556d-53b93ba96218@gmx.at>

#---------------------------------------------------------------------------------------------------------------------------------------------
# This is the start
#---------------------------------------------------------------------------------------------------------------------------------------------

################
## bsBuildLibs ##
#################
macro(bsBuildLibs)
 ??? foreach(lib ${ARGN})
 ??? ??? bsIncludeLib(${lib})
 ??? ??? bsGetLibExamples(${lib})
 ??? ??? bsIncludeLibExamples(${lib})
 ??? endforeach()
endmacro()

##################
## bsIncludeLib ##
##################
macro(bsIncludeLib)
 ??? set(fn "${CMAKE_SOURCE_DIR}/tools/cmake/modules/lib_${ARGV0}.cmake")
 ??? if(EXISTS ${fn})
 ??? ??? include(lib_${ARGV0})
 ??? else()
 ??? ??? message(FATAL_ERROR "Unable to find library configuration file:
${lib_${ARGV0}}!")
 ??? endif()
endmacro()

######################
## bsGetLibExamples ##
######################
macro(bsGetLibExamples)
 ??? string(TOUPPER ${lib} lib_upper)
 ??? set(WITH_LIB_${lib_upper}_EXAMPLES "")
 ??? # get all examples
 ??? get_cmake_property(_vars VARIABLES)
 ??? foreach(_var ${_vars})
 ??? ??? string(TOUPPER ${lib} lib_upper)
 ??? ??? if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)$")
 ??? ??? ??? list(APPEND WITH_LIB_${lib_upper}_EXAMPLES ${CMAKE_MATCH_1})
 ??? ??? endif()
 ??? endforeach()
endmacro()

###########################
## bsIncludeLibsExamples ##
###########################
macro(bsIncludeLibExamples)
 ??? foreach(lib ${ARGN})
 ??? ??? string(TOUPPER ${lib} lib_upper)
 ??? ??? if(DEFINED "WITH_LIB_${lib_upper}_EXAMPLES")
 ??? ??? ??? foreach(example IN LISTS WITH_LIB_${lib_upper}_EXAMPLES)
 ??? ??? ??? ??? string(TOLOWER ${example} example_lower)
 ??? ??? ??? ??? set(fn
"${CMAKE_SOURCE_DIR}/tools/cmake/modules/lib_${lib}_example_${example_lower}.cmake")
 ??? ??? ??? ??? set(lib_name "lib_${lib}_example_${example_lower}")
 ??? ??? ??? ??? if(EXISTS ${fn})
 ??? ??? ??? ??? ??? message(STATUS "Bulding lib ${lib}, example:
${example}")
 ??? ??? ??? ??? ??? include(${lib_name})
 ??? ??? ??? ??? else()
 ??? ??? ??? ??? ??? message(FATAL_ERROR "Could not find example file
${fn} for library ${lib} and (example: ${example_lower})!")
 ??? ??? ??? ??? endif()
 ??? ??? ??? endforeach()
 ??? ??? endif()
 ??? endforeach()
endmacro()





########################################
## FIRST FILE I INCLUDE with inclde() ##
########################################

set(ALL_LIBS "glad;glfw")

set(WITH_LIB_GLAD 1)
set(WITH_LIB_GLAD_EXAMPLE_CBASIC 1)

set(WITH_LIB_GLFW 1)
set(WITH_LIB_GLFW_EXAMPLE_CBASIC 1)
set(WITH_LIB_GLFW_EXAMPLE_CPPBASIC 1)

bsBuildLibs(${ALL_LIBS})

---------------------------------------------------------------------------------------------------------------------------------------------

if turns into loading different files that are part of the compilation:
- First the ALL_LIBS list get looped and all examples for the libraries
are filtered out
- i then i have one example .cmake file for every example with the same
name sheme as you see at the first set() lines like
WITH_LIB_GLAD_EXAMPLE_CBASIC -
 ?this file is included and there should the build process be
acompilshed (the filename here would be lib_glad_example_cbasic.c).

Here is an example if lib_glad.cmake.

---------------------------------------------------------------------------------------------------------------------------------------------


IF(WITH_LIB_GLAD)
 ??? ###################
 ??? ## first example ##
 ??? ###################
 ??? find_package(OpenGL REQUIRED)
 ??? find_package(X11 REQUIRED)
 ??? find_package(Threads REQUIRED)

 ??? set(LIB_GLAD_INC_PATH
 ??? ??? ${OUTPUT_PATH}/glad/include
 ??? ??? ${OPENGL_INCLUDE_DIR}
 ??? ??? ${X11_INCLUDE_DIR}
 ??? )

 ??? set(LIB_GLAD_LIB_PATH
 ??? ??? ${OUTPUT_PATH}/glad/lib
 ??? ??? ${OPENGL_LIBRARIES}
 ??? ??? ${X11_LIBRARIES}
 ??? )

 ??? set(LIB_GLAD_STATIC_LIBS
 ??? ??? glad
 ??? ??? m
 ??? ??? rt
 ??? ??? ${CMAKE_DL_LIBS}
 ??? ??? OpenGL::GL
 ??? ??? Threads::Threads
 ??? ??? X11::X11
 ??? ??? X11::Xxf86vm
 ??? ??? X11::Xi
 ??? ??? X11::Xrandr
 ??? ??? X11::Xcursor
 ??? ??? X11::Xinerama
 ??? )

 ??? cmake_print_variables(OUTPUT_PATH)
 ??? ExternalProject_Add(external_glad
 ??? ??? PREFIX ${CMAKE_BINARY_DIR}/glad-log
 ??? ??? GIT_REPOSITORY ${GLAD_REPO}
 ??? ??? GIT_TAG ${GLAD_TAG}
 ??? ??? GIT_PROGRESS true
 ??? ??? GIT_SHALLOW True
 ??? ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad
 ??? ??? UPDATE_COMMAND ""
 ??? ??? PATCH_COMMAND ""
 ??? ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad
 ??? ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE}
-DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/glad -DGLAD_INSTALL=True
 ??? ??? #CONFIGURE_COMMAND ""
 ??? ??? INSTALL_COMMAND ""
 ??? )

ENDIF()

###########################
## second file i include ##
###########################
IF(WITH_LIB_GLAD AND WITH_LIB_GLAD_EXAMPLE_CBASIC)

 ??? add_executable(LIB_GLAD_EXAMPLE_CBASIC ${LIB_GLAD_EXAMPLE_CBASIC_SRC})
 ??? set(CMAKE_C_COMPILER ${LIB_GLAD_EXAMPLE_CBASIC_COMPILER})

 ??? cmake_print_variables(LIB_GLAD_INC_PATH)
 ??? target_include_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
${LIB_GLAD_INC_PATH})
 ??? target_link_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
${LIB_GLAD_LIB_PATH})
 ??? target_link_libraries(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
${LIB_GLAD_STATIC_LIBS})

 ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG
${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG})
 ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FALGS_RELEASE
${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_RELEASE})

 ??? cmake_print_variables(LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH)
 ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
OUTPUT_NAME_RELEASE ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE})
 ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
OUTPUT_NAME_DEBUG ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_DEBUG})
 ??? add_dependencies(LIB_GLAD_EXAMPLE_CBASIC
${LIB_GLAD_EXAMPLE_CBASIC_DEPS})
 ??? install(
 ??? ??? TARGETS LIB_GLAD_EXAMPLE_CBASIC
 ??? ??? RUNTIME DESTINATION ${LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH}
 ??? )


ENDIF()

and here is the example build file lib_glad_example_cbasic.cmake:

# i tried to remove the IF but it's the same result

if(WITH_LIB_GLAD AND WITH_LIB_GLAD_EXAMPLE_CBASIC)

 ??? message(STATUS "---> Building example WITH_LIB_GLAD_EXAMPLE_CBASIC")

 ??? add_executable(LIB_GLAD_EXAMPLE_CBASIC ${LIB_GLAD_EXAMPLE_CBASIC_SRC})
 ??? set(CMAKE_C_COMPILER ${LIB_GLAD_EXAMPLE_CBASIC_COMPILER})

 ??? cmake_print_variables(LIB_GLAD_INC_PATH)
 ??? target_include_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
${LIB_GLAD_INC_PATH})
 ??? target_link_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
${LIB_GLAD_LIB_PATH})
 ??? target_link_libraries(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
${LIB_GLAD_STATIC_LIBS})

 ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG
${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG})
 ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FALGS_RELEASE
${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_RELEASE})

 ??? cmake_print_variables(LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH)
 ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
OUTPUT_NAME_RELEASE ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE})
 ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
OUTPUT_NAME_DEBUG ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_DEBUG})
 ??? add_dependencies(LIB_GLAD_EXAMPLE_CBASIC
${LIB_GLAD_EXAMPLE_CBASIC_DEPS})
 ??? install(
 ??? ??? TARGETS LIB_GLAD_EXAMPLE_CBASIC
 ??? ??? RUNTIME DESTINATION ${LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH}
 ??? )
ENDIF()


---------------------------------------------------------------------------------------------------------------------------------------------

Now my problem is that the variable CMAKE_BUILD_TYPE automaticaly is set
to debug but i'm using cmake 3.14 with the line:

# avoid having empty buildtype
IF(NOT DEFINED CMAKE_BUILD_TYPE)
 ??? set(CMAKE_BUILD_TYPE Release CACHE STRING "The build type of the
project. (default:Release)")
ENDIF()

and the build_tool directory from the ExternalProject_Add is never
installed but it is tried to compile the example file. It worked before
i'm confused
that something because of the order of how things are working is making
me trouble.

I hope someone can help me out here, it would be the rest work of the
puzzle to make things work uniquely for my libs and their examples.

best regrads!


From workbench at gmx.at  Thu Jun  6 10:54:05 2019
From: workbench at gmx.at (Steven Truppe)
Date: Thu, 6 Jun 2019 16:54:05 +0200
Subject: [CMake] A bit harder question:
In-Reply-To: <57dfed98-5f38-f517-556d-53b93ba96218@gmx.at>
References: <57dfed98-5f38-f517-556d-53b93ba96218@gmx.at>
Message-ID: <b9859ff1-a7c4-2f32-cec8-31dc4ac2832c@gmx.at>

It's also odd that i have to include(ExternalProject) to use the command
but i'm on cmake version 3.14 ...

On 06.06.19 16:51, Steven Truppe wrote:
> #---------------------------------------------------------------------------------------------------------------------------------------------
>
> # This is the start
> #---------------------------------------------------------------------------------------------------------------------------------------------
>
>
> ################
> ## bsBuildLibs ##
> #################
> macro(bsBuildLibs)
> ??? foreach(lib ${ARGN})
> ??? ??? bsIncludeLib(${lib})
> ??? ??? bsGetLibExamples(${lib})
> ??? ??? bsIncludeLibExamples(${lib})
> ??? endforeach()
> endmacro()
>
> ##################
> ## bsIncludeLib ##
> ##################
> macro(bsIncludeLib)
> ??? set(fn "${CMAKE_SOURCE_DIR}/tools/cmake/modules/lib_${ARGV0}.cmake")
> ??? if(EXISTS ${fn})
> ??? ??? include(lib_${ARGV0})
> ??? else()
> ??? ??? message(FATAL_ERROR "Unable to find library configuration file:
> ${lib_${ARGV0}}!")
> ??? endif()
> endmacro()
>
> ######################
> ## bsGetLibExamples ##
> ######################
> macro(bsGetLibExamples)
> ??? string(TOUPPER ${lib} lib_upper)
> ??? set(WITH_LIB_${lib_upper}_EXAMPLES "")
> ??? # get all examples
> ??? get_cmake_property(_vars VARIABLES)
> ??? foreach(_var ${_vars})
> ??? ??? string(TOUPPER ${lib} lib_upper)
> ??? ??? if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)$")
> ??? ??? ??? list(APPEND WITH_LIB_${lib_upper}_EXAMPLES ${CMAKE_MATCH_1})
> ??? ??? endif()
> ??? endforeach()
> endmacro()
>
> ###########################
> ## bsIncludeLibsExamples ##
> ###########################
> macro(bsIncludeLibExamples)
> ??? foreach(lib ${ARGN})
> ??? ??? string(TOUPPER ${lib} lib_upper)
> ??? ??? if(DEFINED "WITH_LIB_${lib_upper}_EXAMPLES")
> ??? ??? ??? foreach(example IN LISTS WITH_LIB_${lib_upper}_EXAMPLES)
> ??? ??? ??? ??? string(TOLOWER ${example} example_lower)
> ??? ??? ??? ??? set(fn
> "${CMAKE_SOURCE_DIR}/tools/cmake/modules/lib_${lib}_example_${example_lower}.cmake")
>
> ??? ??? ??? ??? set(lib_name "lib_${lib}_example_${example_lower}")
> ??? ??? ??? ??? if(EXISTS ${fn})
> ??? ??? ??? ??? ??? message(STATUS "Bulding lib ${lib}, example:
> ${example}")
> ??? ??? ??? ??? ??? include(${lib_name})
> ??? ??? ??? ??? else()
> ??? ??? ??? ??? ??? message(FATAL_ERROR "Could not find example file
> ${fn} for library ${lib} and (example: ${example_lower})!")
> ??? ??? ??? ??? endif()
> ??? ??? ??? endforeach()
> ??? ??? endif()
> ??? endforeach()
> endmacro()
>
>
>
>
>
> ########################################
> ## FIRST FILE I INCLUDE with inclde() ##
> ########################################
>
> set(ALL_LIBS "glad;glfw")
>
> set(WITH_LIB_GLAD 1)
> set(WITH_LIB_GLAD_EXAMPLE_CBASIC 1)
>
> set(WITH_LIB_GLFW 1)
> set(WITH_LIB_GLFW_EXAMPLE_CBASIC 1)
> set(WITH_LIB_GLFW_EXAMPLE_CPPBASIC 1)
>
> bsBuildLibs(${ALL_LIBS})
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>
> if turns into loading different files that are part of the compilation:
> - First the ALL_LIBS list get looped and all examples for the libraries
> are filtered out
> - i then i have one example .cmake file for every example with the same
> name sheme as you see at the first set() lines like
> WITH_LIB_GLAD_EXAMPLE_CBASIC -
> ?this file is included and there should the build process be
> acompilshed (the filename here would be lib_glad_example_cbasic.c).
>
> Here is an example if lib_glad.cmake.
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> IF(WITH_LIB_GLAD)
> ??? ###################
> ??? ## first example ##
> ??? ###################
> ??? find_package(OpenGL REQUIRED)
> ??? find_package(X11 REQUIRED)
> ??? find_package(Threads REQUIRED)
>
> ??? set(LIB_GLAD_INC_PATH
> ??? ??? ${OUTPUT_PATH}/glad/include
> ??? ??? ${OPENGL_INCLUDE_DIR}
> ??? ??? ${X11_INCLUDE_DIR}
> ??? )
>
> ??? set(LIB_GLAD_LIB_PATH
> ??? ??? ${OUTPUT_PATH}/glad/lib
> ??? ??? ${OPENGL_LIBRARIES}
> ??? ??? ${X11_LIBRARIES}
> ??? )
>
> ??? set(LIB_GLAD_STATIC_LIBS
> ??? ??? glad
> ??? ??? m
> ??? ??? rt
> ??? ??? ${CMAKE_DL_LIBS}
> ??? ??? OpenGL::GL
> ??? ??? Threads::Threads
> ??? ??? X11::X11
> ??? ??? X11::Xxf86vm
> ??? ??? X11::Xi
> ??? ??? X11::Xrandr
> ??? ??? X11::Xcursor
> ??? ??? X11::Xinerama
> ??? )
>
> ??? cmake_print_variables(OUTPUT_PATH)
> ??? ExternalProject_Add(external_glad
> ??? ??? PREFIX ${CMAKE_BINARY_DIR}/glad-log
> ??? ??? GIT_REPOSITORY ${GLAD_REPO}
> ??? ??? GIT_TAG ${GLAD_TAG}
> ??? ??? GIT_PROGRESS true
> ??? ??? GIT_SHALLOW True
> ??? ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad
> ??? ??? UPDATE_COMMAND ""
> ??? ??? PATCH_COMMAND ""
> ??? ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad
> ??? ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE}
> -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/glad -DGLAD_INSTALL=True
> ??? ??? #CONFIGURE_COMMAND ""
> ??? ??? INSTALL_COMMAND ""
> ??? )
>
> ENDIF()
>
> ###########################
> ## second file i include ##
> ###########################
> IF(WITH_LIB_GLAD AND WITH_LIB_GLAD_EXAMPLE_CBASIC)
>
> ??? add_executable(LIB_GLAD_EXAMPLE_CBASIC
> ${LIB_GLAD_EXAMPLE_CBASIC_SRC})
> ??? set(CMAKE_C_COMPILER ${LIB_GLAD_EXAMPLE_CBASIC_COMPILER})
>
> ??? cmake_print_variables(LIB_GLAD_INC_PATH)
> ??? target_include_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
> ${LIB_GLAD_INC_PATH})
> ??? target_link_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
> ${LIB_GLAD_LIB_PATH})
> ??? target_link_libraries(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
> ${LIB_GLAD_STATIC_LIBS})
>
> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG
> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG})
> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FALGS_RELEASE
> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_RELEASE})
>
> ??? cmake_print_variables(LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH)
> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
> OUTPUT_NAME_RELEASE ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE})
> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
> OUTPUT_NAME_DEBUG ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_DEBUG})
> ??? add_dependencies(LIB_GLAD_EXAMPLE_CBASIC
> ${LIB_GLAD_EXAMPLE_CBASIC_DEPS})
> ??? install(
> ??? ??? TARGETS LIB_GLAD_EXAMPLE_CBASIC
> ??? ??? RUNTIME DESTINATION ${LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH}
> ??? )
>
>
> ENDIF()
>
> and here is the example build file lib_glad_example_cbasic.cmake:
>
> # i tried to remove the IF but it's the same result
>
> if(WITH_LIB_GLAD AND WITH_LIB_GLAD_EXAMPLE_CBASIC)
>
> ??? message(STATUS "---> Building example WITH_LIB_GLAD_EXAMPLE_CBASIC")
>
> ??? add_executable(LIB_GLAD_EXAMPLE_CBASIC
> ${LIB_GLAD_EXAMPLE_CBASIC_SRC})
> ??? set(CMAKE_C_COMPILER ${LIB_GLAD_EXAMPLE_CBASIC_COMPILER})
>
> ??? cmake_print_variables(LIB_GLAD_INC_PATH)
> ??? target_include_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
> ${LIB_GLAD_INC_PATH})
> ??? target_link_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
> ${LIB_GLAD_LIB_PATH})
> ??? target_link_libraries(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
> ${LIB_GLAD_STATIC_LIBS})
>
> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG
> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG})
> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FALGS_RELEASE
> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_RELEASE})
>
> ??? cmake_print_variables(LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH)
> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
> OUTPUT_NAME_RELEASE ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE})
> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
> OUTPUT_NAME_DEBUG ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_DEBUG})
> ??? add_dependencies(LIB_GLAD_EXAMPLE_CBASIC
> ${LIB_GLAD_EXAMPLE_CBASIC_DEPS})
> ??? install(
> ??? ??? TARGETS LIB_GLAD_EXAMPLE_CBASIC
> ??? ??? RUNTIME DESTINATION ${LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH}
> ??? )
> ENDIF()
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>
> Now my problem is that the variable CMAKE_BUILD_TYPE automaticaly is set
> to debug but i'm using cmake 3.14 with the line:
>
> # avoid having empty buildtype
> IF(NOT DEFINED CMAKE_BUILD_TYPE)
> ??? set(CMAKE_BUILD_TYPE Release CACHE STRING "The build type of the
> project. (default:Release)")
> ENDIF()
>
> and the build_tool directory from the ExternalProject_Add is never
> installed but it is tried to compile the example file. It worked before
> i'm confused
> that something because of the order of how things are working is making
> me trouble.
>
> I hope someone can help me out here, it would be the rest work of the
> puzzle to make things work uniquely for my libs and their examples.
>
> best regrads!
>

From workbench at gmx.at  Thu Jun  6 11:13:28 2019
From: workbench at gmx.at (Steven Truppe)
Date: Thu, 6 Jun 2019 17:13:28 +0200
Subject: [CMake] A bit harder question:
In-Reply-To: <b9859ff1-a7c4-2f32-cec8-31dc4ac2832c@gmx.at>
References: <57dfed98-5f38-f517-556d-53b93ba96218@gmx.at>
 <b9859ff1-a7c4-2f32-cec8-31dc4ac2832c@gmx.at>
Message-ID: <1c0954b7-73c0-42b1-ef83-087bf2a0f95f@gmx.at>

I made a few misakes

On 06.06.19 16:54, Steven Truppe wrote:
> It's also odd that i have to include(ExternalProject) to use the command
> but i'm on cmake version 3.14 ...
>
> On 06.06.19 16:51, Steven Truppe wrote:
>> #---------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> # This is the start
>> #---------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> ################
>> ## bsBuildLibs ##
>> #################
>> macro(bsBuildLibs)
>> ??? foreach(lib ${ARGN})
>> ??? ??? bsIncludeLib(${lib})
>> ??? ??? bsGetLibExamples(${lib})
>> ??? ??? bsIncludeLibExamples(${lib})
>> ??? endforeach()
>> endmacro()
>>
>> ##################
>> ## bsIncludeLib ##
>> ##################
>> macro(bsIncludeLib)
>> ??? set(fn "${CMAKE_SOURCE_DIR}/tools/cmake/modules/lib_${ARGV0}.cmake")
>> ??? if(EXISTS ${fn})
>> ??? ??? include(lib_${ARGV0})
>> ??? else()
>> ??? ??? message(FATAL_ERROR "Unable to find library configuration file:
>> ${lib_${ARGV0}}!")
>> ??? endif()
>> endmacro()
>>
>> ######################
>> ## bsGetLibExamples ##
>> ######################
>> macro(bsGetLibExamples)
>> ??? string(TOUPPER ${lib} lib_upper)
>> ??? set(WITH_LIB_${lib_upper}_EXAMPLES "")
>> ??? # get all examples
>> ??? get_cmake_property(_vars VARIABLES)
>> ??? foreach(_var ${_vars})
>> ??? ??? string(TOUPPER ${lib} lib_upper)
>> ??? ??? if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)$")
>> ??? ??? ??? list(APPEND WITH_LIB_${lib_upper}_EXAMPLES ${CMAKE_MATCH_1})
>> ??? ??? endif()
>> ??? endforeach()
>> endmacro()
>>
>> ###########################
>> ## bsIncludeLibsExamples ##
>> ###########################
>> macro(bsIncludeLibExamples)
>> ??? foreach(lib ${ARGN})
>> ??? ??? string(TOUPPER ${lib} lib_upper)
>> ??? ??? if(DEFINED "WITH_LIB_${lib_upper}_EXAMPLES")
>> ??? ??? ??? foreach(example IN LISTS WITH_LIB_${lib_upper}_EXAMPLES)
>> ??? ??? ??? ??? string(TOLOWER ${example} example_lower)
>> ??? ??? ??? ??? set(fn
>> "${CMAKE_SOURCE_DIR}/tools/cmake/modules/lib_${lib}_example_${example_lower}.cmake")
>>
>>
>> ??? ??? ??? ??? set(lib_name "lib_${lib}_example_${example_lower}")
>> ??? ??? ??? ??? if(EXISTS ${fn})
>> ??? ??? ??? ??? ??? message(STATUS "Bulding lib ${lib}, example:
>> ${example}")
>> ??? ??? ??? ??? ??? include(${lib_name})
>> ??? ??? ??? ??? else()
>> ??? ??? ??? ??? ??? message(FATAL_ERROR "Could not find example file
>> ${fn} for library ${lib} and (example: ${example_lower})!")
>> ??? ??? ??? ??? endif()
>> ??? ??? ??? endforeach()
>> ??? ??? endif()
>> ??? endforeach()
>> endmacro()
>>
>>
>>
>> set(ALL_LIBS "glad;glfw")
>>
>> set(WITH_LIB_GLAD 1)
>> set(WITH_LIB_GLAD_EXAMPLE_CBASIC 1)
>>
>> set(WITH_LIB_GLFW 1)
>> set(WITH_LIB_GLFW_EXAMPLE_CBASIC 1)
>> set(WITH_LIB_GLFW_EXAMPLE_CPPBASIC 1)
>>
>> bsBuildLibs(${ALL_LIBS})
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> If turns into loading different files that are part of the compilation:
>> - First the ALL_LIBS list get looped and all examples for the libraries
>> are filtered out
>> - i then i have one example .cmake file for every example with the same
>> name sheme as you see at the first set() lines like .

so 2 files: one with the ExternalExample_Add() command and one for the
build process -

in this example we have lib_glad.inc that is included first and the
lib_glad_example_cbasic.cmake file for building an example.

>> WITH_LIB_GLAD_EXAMPLE_CBASIC -
>> ?this file is included and there should the build process be
>> acompilshed (the filename here would be lib_glad_example_cbasic.c).
>>
>> Here is an example if lib_glad.cmake.
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------
>>
>> (lib_glad.cmake)
>>
>>
>> IF(WITH_LIB_GLAD)
>> ??? ###################
>> ??? ## first example ##
>> ??? ###################
>> ??? find_package(OpenGL REQUIRED)
>> ??? find_package(X11 REQUIRED)
>> ??? find_package(Threads REQUIRED)
>>
>> ??? set(LIB_GLAD_INC_PATH
>> ??? ??? ${OUTPUT_PATH}/glad/include
>> ??? ??? ${OPENGL_INCLUDE_DIR}
>> ??? ??? ${X11_INCLUDE_DIR}
>> ??? )
>>
>> ??? set(LIB_GLAD_LIB_PATH
>> ??? ??? ${OUTPUT_PATH}/glad/lib
>> ??? ??? ${OPENGL_LIBRARIES}
>> ??? ??? ${X11_LIBRARIES}
>> ??? )
>>
>> ??? set(LIB_GLAD_STATIC_LIBS
>> ??? ??? glad
>> ??? ??? m
>> ??? ??? rt
>> ??? ??? ${CMAKE_DL_LIBS}
>> ??? ??? OpenGL::GL
>> ??? ??? Threads::Threads
>> ??? ??? X11::X11
>> ??? ??? X11::Xxf86vm
>> ??? ??? X11::Xi
>> ??? ??? X11::Xrandr
>> ??? ??? X11::Xcursor
>> ??? ??? X11::Xinerama
>> ??? )
>>
>> ??? cmake_print_variables(OUTPUT_PATH)
>> ??? ExternalProject_Add(external_glad
>> ??? ??? PREFIX ${CMAKE_BINARY_DIR}/glad-log
>> ??? ??? GIT_REPOSITORY ${GLAD_REPO}
>> ??? ??? GIT_TAG ${GLAD_TAG}
>> ??? ??? GIT_PROGRESS true
>> ??? ??? GIT_SHALLOW True
>> ??? ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad
>> ??? ??? UPDATE_COMMAND ""
>> ??? ??? PATCH_COMMAND ""
>> ??? ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad
>> ??? ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE}
>> -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/glad -DGLAD_INSTALL=True
>> ??? ??? #CONFIGURE_COMMAND ""
>> ??? ??? INSTALL_COMMAND ""
>> ??? )
>>
>> ENDIF()
>>
>>
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------
>>

lib_glad_example_cbasic.cmake

second file included

>> IF(WITH_LIB_GLAD AND WITH_LIB_GLAD_EXAMPLE_CBASIC)
>>
>> ??? add_executable(LIB_GLAD_EXAMPLE_CBASIC
>> ${LIB_GLAD_EXAMPLE_CBASIC_SRC})
>> ??? set(CMAKE_C_COMPILER ${LIB_GLAD_EXAMPLE_CBASIC_COMPILER})
>>
>> ??? cmake_print_variables(LIB_GLAD_INC_PATH)
>> ??? target_include_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
>> ${LIB_GLAD_INC_PATH})
>> ??? target_link_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
>> ${LIB_GLAD_LIB_PATH})
>> ??? target_link_libraries(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
>> ${LIB_GLAD_STATIC_LIBS})
>>
>> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG
>> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG})
>> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FALGS_RELEASE
>> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_RELEASE})
>>
>> ??? cmake_print_variables(LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH)
>> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
>> OUTPUT_NAME_RELEASE ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE})
>> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
>> OUTPUT_NAME_DEBUG ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_DEBUG})
>> ??? add_dependencies(LIB_GLAD_EXAMPLE_CBASIC
>> ${LIB_GLAD_EXAMPLE_CBASIC_DEPS})
>> ??? install(
>> ??? ??? TARGETS LIB_GLAD_EXAMPLE_CBASIC
>> ??? ??? RUNTIME DESTINATION ${LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH}
>> ??? )
>>
>>
>> ENDIF()
>>
>> and here is the example build file lib_glad_example_cbasic.cmake:
>>
>> # i tried to remove the IF but it's the same result
>>
>> if(WITH_LIB_GLAD AND WITH_LIB_GLAD_EXAMPLE_CBASIC)
>>
>> ??? message(STATUS "---> Building example WITH_LIB_GLAD_EXAMPLE_CBASIC")
>>
>> ??? add_executable(LIB_GLAD_EXAMPLE_CBASIC
>> ${LIB_GLAD_EXAMPLE_CBASIC_SRC})
>> ??? set(CMAKE_C_COMPILER ${LIB_GLAD_EXAMPLE_CBASIC_COMPILER})
>>
>> ??? cmake_print_variables(LIB_GLAD_INC_PATH)
>> ??? target_include_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
>> ${LIB_GLAD_INC_PATH})
>> ??? target_link_directories(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
>> ${LIB_GLAD_LIB_PATH})
>> ??? target_link_libraries(LIB_GLAD_EXAMPLE_CBASIC PRIVATE
>> ${LIB_GLAD_STATIC_LIBS})
>>
>> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG
>> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_DEBUG})
>> ??? set(LIB_GLAD_EXAMPLE_CBASIC_C_FALGS_RELEASE
>> ${LIB_GLAD_EXAMPLE_CBASIC_C_FLAGS_RELEASE})
>>
>> ??? cmake_print_variables(LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH)
>> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
>> OUTPUT_NAME_RELEASE ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE})
>> ??? set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
>> OUTPUT_NAME_DEBUG ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_DEBUG})
>> ??? add_dependencies(LIB_GLAD_EXAMPLE_CBASIC
>> ${LIB_GLAD_EXAMPLE_CBASIC_DEPS})
>> ??? install(
>> ??? ??? TARGETS LIB_GLAD_EXAMPLE_CBASIC
>> ??? ??? RUNTIME DESTINATION ${LIB_GLAD_EXAMPLE_CBASIC_INSTALL_PATH}
>> ??? )
>> ENDIF()
>>
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> Now my problem is that the variable CMAKE_BUILD_TYPE automaticaly is set
>> to debug but i'm using cmake 3.14 with the line:
>>
>> # avoid having empty buildtype
>> IF(NOT DEFINED CMAKE_BUILD_TYPE)
>> ??? set(CMAKE_BUILD_TYPE Release CACHE STRING "The build type of the
>> project. (default:Release)")
>> ENDIF()
>>
>> and the build_tool directory from the ExternalProject_Add is never
>> installed but it is tried to compile the example file. It worked before
>> i'm confused
>> that something because of the order of how things are working is making
>> me trouble.
>>
>> I hope someone can help me out here, it would be the rest work of the
>> puzzle to make things work uniquely for my libs and their examples.
>>
>> best regrads!
>>

From workbench at gmx.at  Thu Jun  6 13:37:52 2019
From: workbench at gmx.at (Steven Truppe)
Date: Thu, 6 Jun 2019 19:37:52 +0200
Subject: [CMake] Strange properties issue
In-Reply-To: <1c0954b7-73c0-42b1-ef83-087bf2a0f95f@gmx.at>
References: <57dfed98-5f38-f517-556d-53b93ba96218@gmx.at>
 <b9859ff1-a7c4-2f32-cec8-31dc4ac2832c@gmx.at>
 <1c0954b7-73c0-42b1-ef83-087bf2a0f95f@gmx.at>
Message-ID: <d488e4a8-73a2-f85c-d23c-0668bf961d9f@gmx.at>

Hi again,

i solved most of the problems, i have a single issue left: i have two
files, in one file i do:

set(WITH_LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE "demo")

and in the next file i include i have:

set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
OUTPUT_NAME_RELEASE ${LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE}) .

And as a result after make install i get:

-- Set runtime path of
"/media/stuv/linux-projects/programming/bsEdit/build_files/Debug/examples/glad_basic/LIB_GLAD_EXAMPLE_CBASIC"
to ""

And the filename of the build file is LIB_GLAD_EXAMPLE_CBASIC ...


best regards.



From workbench at gmx.at  Thu Jun  6 13:51:38 2019
From: workbench at gmx.at (Steven Truppe)
Date: Thu, 6 Jun 2019 19:51:38 +0200
Subject: [CMake] Strange properties issue
In-Reply-To: <d488e4a8-73a2-f85c-d23c-0668bf961d9f@gmx.at>
References: <57dfed98-5f38-f517-556d-53b93ba96218@gmx.at>
 <b9859ff1-a7c4-2f32-cec8-31dc4ac2832c@gmx.at>
 <1c0954b7-73c0-42b1-ef83-087bf2a0f95f@gmx.at>
 <d488e4a8-73a2-f85c-d23c-0668bf961d9f@gmx.at>
Message-ID: <412de599-9d47-d0d0-7f3a-140f6bb579d6@gmx.at>


On 06.06.19 19:37, Steven Truppe wrote:
> Hi again,
>
> i solved most of the problems, i have a single issue left: i have two
> files, in one file i do:
>
> set(WITH_LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE "demo")
>
> and in the next file i include i have:
>
> set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
> OUTPUT_NAME_RELEASE
> ${WITH_LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE}) .
>
> And as a result after make install i get:
>
> -- Set runtime path of
> "/media/stuv/linux-projects/programming/bsEdit/build_files/Debug/examples/glad_basic/LIB_GLAD_EXAMPLE_CBASIC"
>
> to ""
>
> And the filename of the build file is LIB_GLAD_EXAMPLE_CBASIC ...
>
>
> best regards.
>
>

From workbench at gmx.at  Thu Jun  6 14:12:28 2019
From: workbench at gmx.at (Steven Truppe)
Date: Thu, 6 Jun 2019 20:12:28 +0200
Subject: [CMake] Strange properties issue
In-Reply-To: <412de599-9d47-d0d0-7f3a-140f6bb579d6@gmx.at>
References: <57dfed98-5f38-f517-556d-53b93ba96218@gmx.at>
 <b9859ff1-a7c4-2f32-cec8-31dc4ac2832c@gmx.at>
 <1c0954b7-73c0-42b1-ef83-087bf2a0f95f@gmx.at>
 <d488e4a8-73a2-f85c-d23c-0668bf961d9f@gmx.at>
 <412de599-9d47-d0d0-7f3a-140f6bb579d6@gmx.at>
Message-ID: <2dce9d09-95c5-daf1-5d46-2b84da7209ae@gmx.at>

I missed the property - it's DEBUG_OUTPUT_NAME and RELEASE_OUTPUT_NAME,
sry..

On 06.06.19 19:51, Steven Truppe wrote:
>
> On 06.06.19 19:37, Steven Truppe wrote:
>> Hi again,
>>
>> i solved most of the problems, i have a single issue left: i have two
>> files, in one file i do:
>>
>> set(WITH_LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE "demo")
>>
>> and in the next file i include i have:
>>
>> set_target_properties(LIB_GLAD_EXAMPLE_CBASIC PROPERTIES
>> OUTPUT_NAME_RELEASE
>> ${WITH_LIB_GLAD_EXAMPLE_CBASIC_OUTPUT_NAME_RELEASE}) .
>>
>> And as a result after make install i get:
>>
>> -- Set runtime path of
>> "/media/stuv/linux-projects/programming/bsEdit/build_files/Debug/examples/glad_basic/LIB_GLAD_EXAMPLE_CBASIC"
>>
>>
>> to ""
>>
>> And the filename of the build file is LIB_GLAD_EXAMPLE_CBASIC ...
>>
>>
>> best regards.
>>
>>

From ggarra13 at gmail.com  Fri Jun  7 09:42:11 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Fri, 7 Jun 2019 10:42:11 -0300
Subject: [CMake] CMake | CMake/CPack do not print out messages as they
 progress (#19343)
In-Reply-To: <note_581122@gitlab.kitware.com>
References: <reply-0798f3ef1b2ad15fbb6587e8623f1845@gitlab.kitware.com>
 <issue_78050@gitlab.kitware.com> <note_581122@gitlab.kitware.com>
Message-ID: <e09ddca5-2ab1-426f-4f96-3bf3113e06b3@gmail.com>

I found out the problem was an old ninja version.  I am closing the bug 
report.


El 06/06/19 a las 12:27, Brad King escribi?:
> GitLab
>
> I tried CMake 3.14.5 and 3.15.0-rc1 on your example. They both behave 
> the same. Running |ninja bundle| shows incremental output from cpack. 
> Alternatively running |ninja -v bundle| shows |[0/1] cd ... && 
> /.../bin/cpack -C Release --config /.../BundleConfig.cmake| followed 
> by incremental output.
>
> ?
> Reply to this email directly or view it on GitLab 
> <https://gitlab.kitware.com/cmake/cmake/issues/19343#note_581122>.
> You're receiving this email because of your account on 
> gitlab.kitware.com. If you'd like to receive fewer emails, you can 
> unsubscribe 
> <https://gitlab.kitware.com/sent_notifications/0798f3ef1b2ad15fbb6587e8623f1845/unsubscribe> 
> from this thread or adjust your notification settings.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190607/84b76ed6/attachment.html>

From kyle.edwards at kitware.com  Fri Jun  7 18:05:51 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 07 Jun 2019 18:05:51 -0400
Subject: [CMake] CMake Release Candidate Builds Available for Ubuntu
Message-ID: <1559945151.3051.23.camel@kitware.com>

All,

I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.

If you would like to receive release candidate builds, follow the
instructions at https://apt.kitware.com/?to add the release candidate
repository to your installation. (Please note that the release
candidates are optional and opt-in - if you don't explicitly add the
release candidate repository, you will only receive production builds.)

In addition, starting with this release candidate, we are now offering
32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the
same as 64-bit - just add the repository to your installation and
install it.

Happy coding!

Kyle

From workbench at gmx.at  Sat Jun  8 08:47:52 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sat, 8 Jun 2019 14:47:52 +0200
Subject: [CMake] Troubles with ExternalProject_Add.
Message-ID: <5775872a-8d71-77a5-bcb3-2b667f4472c3@gmx.at>

Hi everyone,

I've troubles with ExternalProject_Add:

when i do build the library? manualy (clone the repo and build it with
mkdir build;cd build; cmake -DCMAKE_BUILD_TYPE:String=Release
-DGLAD_INSTALL=ON -DCMAKE_INSTALL_PREFIX=/home/stuv/glad_examples) it
does work and i've the installation at /home/stuv/glad_examples.


But the external project add seems to miss an argument because he
doesn't install anything.

Here the code of ExternalProject_Add:

ExternalProject_Add(external_glad
 ??? ??? PREFIX ${CMAKE_BINARY_DIR}/glad
 ??? ??? GIT_REPOSITORY ${GLAD_REPO}
 ??? ??? GIT_TAG ${GLAD_TAG}
 ??? ??? GIT_PROGRESS true
 ??? ??? GIT_SHALLOW True
 ??? ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad-src
 ??? ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad-download
 ??? ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} -DGLAD_INSTALL=ON -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/glad

)

I hope someone here does see my problem.


best regards!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190608/3bb9b19e/attachment.html>

From workbench at gmx.at  Sat Jun  8 08:57:33 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sat, 8 Jun 2019 14:57:33 +0200
Subject: [CMake] Troubles with ExternalProject_Add.
In-Reply-To: <5775872a-8d71-77a5-bcb3-2b667f4472c3@gmx.at>
References: <5775872a-8d71-77a5-bcb3-2b667f4472c3@gmx.at>
Message-ID: <69384551-73cc-832d-debb-20d59ca0987b@gmx.at>

Found the error, thank you anyway? -? you guys are allways a good way to
get help about cmake, i'm starting to understand cmake slowly but it's
getting easier and easier, cmake is a great build system.


best regards!

On 08.06.19 14:47, Steven Truppe wrote:
>
> Hi everyone,
>
> I've troubles with ExternalProject_Add:
>
> when i do build the library? manualy (clone the repo and build it with
> mkdir build;cd build; cmake -DCMAKE_BUILD_TYPE:String=Release
> -DGLAD_INSTALL=ON -DCMAKE_INSTALL_PREFIX=/home/stuv/glad_examples) it
> does work and i've the installation at /home/stuv/glad_examples.
>
>
> But the external project add seems to miss an argument because he
> doesn't install anything.
>
> Here the code of ExternalProject_Add:
>
> ExternalProject_Add(external_glad
>  ??? ??? PREFIX ${CMAKE_BINARY_DIR}/glad
>  ??? ??? GIT_REPOSITORY ${GLAD_REPO}
>  ??? ??? GIT_TAG ${GLAD_TAG}
>  ??? ??? GIT_PROGRESS true
>  ??? ??? GIT_SHALLOW True
>  ??? ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad-src
>  ??? ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad-download
>  ??? ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} -DGLAD_INSTALL=ON -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/glad
> )
>
> I hope someone here does see my problem.
>
>
> best regards!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190608/d2242098/attachment.html>

From vinay.kotegowder at gmail.com  Sat Jun  8 16:28:55 2019
From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder)
Date: Sun, 9 Jun 2019 01:58:55 +0530
Subject: [CMake] Trouble with running cmake on MinGW
Message-ID: <CAE3QRuM_LFxRLST1y5nmm1QxtNoKbo1=AG1Jti3vxV+dgPmHOw@mail.gmail.com>

Hi Everyone,

I am trying to run cmake project on MinGW.
I get the below error:
[ 91%] Linking C executable test_m001.secure.elf.exe
c:/progra~2/gnutoo~1/72018-~1/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld.exe:
unrecognized option '--major-image-version'
c:/progra~2/gnutoo~1/72018-~1/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld.exe:
use the --help option for usage information

I have set
set(CMAKE_SYSTEM_NAME Generic)
set(CMKE_SYSTEM_PROCESSOR ARM) in my toolchain file.

Can someone see my problem?

Regards,
Vinay

From workbench at gmx.at  Sat Jun  8 18:18:08 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 00:18:08 +0200
Subject: [CMake] Question about config_file.
Message-ID: <60317551-2b42-b62b-dd46-6e2663cacf3d@gmx.at>

Hi everyone,

currently i'm trying to build my doxygen documentation from my
CMakeLists.txt file. I found the following example that seems to be
correct:

######################
## bsBuildDoxygen() ##
######################
macro(bsBuildDocs)
	if(GENERATE_DOCS)
		# check if Doxygen is installed
		find_package(Doxygen)
		if(DOXYGEN_FOUND)
			# set input and output files
			set(DOXYGEN_IN ${CMAKE_CURRENT_SOURCE_DIR}/doc/manual/Doxyfile.in)
			set(DOXYGEN_OUT ${CMAKE_CURRENT_SOURCE_DIR}/doc/manual/Doxyfile)

			# request to configure the file
			configure_file(${DOXYGEN_IN} ${DOXYGEN_OUT} @ONLY)
			message("Doxygen build started")

			# note the option ALL which allows to build the docs together with the application
			add_custom_target( doc_doxygen ALL
				COMMAND ${DOXYGEN_EXECUTABLE} ${DOXYGEN_OUT}
				WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
				COMMENT "Generating API documentation with Doxygen"
				VERBATIM )
		else()
		  message("Doxygen need to be installed to generate the doxygen documentation")
		endif()
	endif()
endmacro()

Now my question is about the configure_file command. what is Doxygen.in
and what is the configure_file command for ?


best regards!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190609/73ab8107/attachment.html>

From workbench at gmx.at  Sat Jun  8 18:25:25 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 00:25:25 +0200
Subject: [CMake] Question about getting git branch name.
Message-ID: <a16e3138-af55-3f1a-6086-765093095cea@gmx.at>

Hi everyone,

i want to have code lines like:

#define BUILD_VERSION

and the BUILD_VERSION should be the name of the actual branch the code
was compiled with, this way i can create a branch for each version and
name it like 0.1 so each version i'm using for release is an own branch.

I found many examples that shows me the branch name (like git status)
but i don't know a way to get only the name of the current branch so i
can for example execute_process to get the revision number into a
variable and then use add_definition(..) to add it as a compile definition.


best regards!


From d3ck0r at gmail.com  Sat Jun  8 18:34:41 2019
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 8 Jun 2019 15:34:41 -0700
Subject: [CMake] Question about getting git branch name.
In-Reply-To: <a16e3138-af55-3f1a-6086-765093095cea@gmx.at>
References: <a16e3138-af55-3f1a-6086-765093095cea@gmx.at>
Message-ID: <CAA2GJqU44ndDOTyhWiDpyHDM8OqNgbw+i1EKRNjTQjSyEzsYNQ@mail.gmail.com>

On Sat, Jun 8, 2019 at 3:25 PM Steven Truppe <workbench at gmx.at> wrote:

> Hi everyone,
>
> i want to have code lines like:
>
> #define BUILD_VERSION
>
> and the BUILD_VERSION should be the name of the actual branch the code
> was compiled with, this way i can create a branch for each version and
> name it like 0.1 so each version i'm using for release is an own branch.
>
> I found many examples that shows me the branch name (like git status)
>
git branch
Hmm this shows a list of things, have to extract the one with a * on the
beginning... cam probably use CMAKE list functions on the output.


EXECUTE_PROCESS(WORKING_DIRECTORY ${CMAKE_SOURCE_DIR} COMMAND git rev-list
--max-count=1 HEAD OUTPUT_VARIABLE CURRENT_REPO_REVISION )

gives me the last hash...

but i don't know a way to get only the name of the current branch so i
> can for example execute_process to get the revision number into a
> variable and then use add_definition(..) to add it as a compile definition.
>
>
> best regards!
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190608/f0eac476/attachment.html>

From workbench at gmx.at  Sun Jun  9 01:01:51 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 07:01:51 +0200
Subject: [CMake] Question about a simple macro.
Message-ID: <d31a42c6-7f3e-6b21-e8c8-9d6fe83143c2@gmx.at>

Hi everyone,

i'm a c,c++,asm and a few other languages, but i still have troubles
with macros and their arguments.

As a simple example i would like to have a macro that list(APPEND the
two passed arguments), here the code i tried:

https://wandbox.org/permlink/WQZGty9PQaOz3422.


Let's forget about the list(APPEND) line, i just need an example that
prints me out the first and the second argument and i'm not able to get
it right. Would someone please explain to me how i can do this right ?
I've read the book but that didn't helped me completely.

I hope someone here is so nice to me to explain to me how i can write
the bsMergeFlags macro and explains me what i'm doing wrong and how to
correct it.

I played around alot but can't get it right.


best regards!



From workbench at gmx.at  Sun Jun  9 01:20:11 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 07:20:11 +0200
Subject: [CMake] Question about a simple macro.
In-Reply-To: <d31a42c6-7f3e-6b21-e8c8-9d6fe83143c2@gmx.at>
References: <d31a42c6-7f3e-6b21-e8c8-9d6fe83143c2@gmx.at>
Message-ID: <3813a307-9d81-7aa5-4ed6-1c3afe6a55b9@gmx.at>

Do i need cmake_parse_arguments ??

On 09.06.19 07:01, Steven Truppe wrote:
> Hi everyone,
>
> i'm a c,c++,asm and a few other languages, but i still have troubles
> with macros and their arguments.
>
> As a simple example i would like to have a macro that list(APPEND the
> two passed arguments), here the code i tried:
>
> https://wandbox.org/permlink/WQZGty9PQaOz3422.
>
>
> Let's forget about the list(APPEND) line, i just need an example that
> prints me out the first and the second argument and i'm not able to get
> it right. Would someone please explain to me how i can do this right ?
> I've read the book but that didn't helped me completely.
>
> I hope someone here is so nice to me to explain to me how i can write
> the bsMergeFlags macro and explains me what i'm doing wrong and how to
> correct it.
>
> I played around alot but can't get it right.
>
>
> best regards!
>
>

From workbench at gmx.at  Sun Jun  9 02:26:33 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 08:26:33 +0200
Subject: [CMake] Question about a simple macro.
In-Reply-To: <3813a307-9d81-7aa5-4ed6-1c3afe6a55b9@gmx.at>
References: <d31a42c6-7f3e-6b21-e8c8-9d6fe83143c2@gmx.at>
 <3813a307-9d81-7aa5-4ed6-1c3afe6a55b9@gmx.at>
Message-ID: <60a40eab-6766-cb93-360b-59951e81b5c7@gmx.at>

ARGV1 gives me the first list entry of my first arguments, but i don't
know how i can access the hole list.


best regards!

On 09.06.19 07:20, Steven Truppe wrote:
> Do i need cmake_parse_arguments ??
>
> On 09.06.19 07:01, Steven Truppe wrote:
>> Hi everyone,
>>
>> i'm a c,c++,asm and a few other languages, but i still have troubles
>> with macros and their arguments.
>>
>> As a simple example i would like to have a macro that list(APPEND the
>> two passed arguments), here the code i tried:
>>
>> https://wandbox.org/permlink/WQZGty9PQaOz3422.
>>
>>
>> Let's forget about the list(APPEND) line, i just need an example that
>> prints me out the first and the second argument and i'm not able to get
>> it right. Would someone please explain to me how i can do this right ?
>> I've read the book but that didn't helped me completely.
>>
>> I hope someone here is so nice to me to explain to me how i can write
>> the bsMergeFlags macro and explains me what i'm doing wrong and how to
>> correct it.
>>
>> I played around alot but can't get it right.
>>
>>
>> best regards!
>>
>>

From workbench at gmx.at  Sun Jun  9 02:41:41 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 08:41:41 +0200
Subject: [CMake] Question about a simple macro.
In-Reply-To: <60a40eab-6766-cb93-360b-59951e81b5c7@gmx.at>
References: <d31a42c6-7f3e-6b21-e8c8-9d6fe83143c2@gmx.at>
 <3813a307-9d81-7aa5-4ed6-1c3afe6a55b9@gmx.at>
 <60a40eab-6766-cb93-360b-59951e81b5c7@gmx.at>
Message-ID: <cb00716b-0c37-150a-7502-4070ac22eb7d@gmx.at>

OK, i don't realy understand why it does work but i got it working:

include(CMakePrintHelpers)
macro(bsMergeFlags flags_to_add flags)
 ??? set(flags_to_add ${flags_to_add} ${ARGN} )
 ??? cmake_print_variables(flags_to_add)

 ??? message(STATUS "bsMergeFlags ${flags_to_add}")
 ??? list(APPEND flags ${tmp})
 ??? message(STATUS "------------")
endmacro()

Now my problem is that the content of flags_to_add is correct when i use
cmake_print_variables but not when i try to use it in a message() call.


I think i do miss some very important part when it comes to variables -
i'm now studying the hole chapter again, hopefully i understand it then.


I hope you guys can help me.


best regards!


On 09.06.19 08:26, Steven Truppe wrote:
> ARGV1 gives me the first list entry of my first arguments, but i don't
> know how i can access the hole list.
>
>
> best regards!
>
> On 09.06.19 07:20, Steven Truppe wrote:
>> Do i need cmake_parse_arguments ??
>>
>> On 09.06.19 07:01, Steven Truppe wrote:
>>> Hi everyone,
>>>
>>> i'm a c,c++,asm and a few other languages, but i still have troubles
>>> with macros and their arguments.
>>>
>>> As a simple example i would like to have a macro that list(APPEND the
>>> two passed arguments), here the code i tried:
>>>
>>> https://wandbox.org/permlink/WQZGty9PQaOz3422.
>>>
>>>
>>> Let's forget about the list(APPEND) line, i just need an example that
>>> prints me out the first and the second argument and i'm not able to get
>>> it right. Would someone please explain to me how i can do this right ?
>>> I've read the book but that didn't helped me completely.
>>>
>>> I hope someone here is so nice to me to explain to me how i can write
>>> the bsMergeFlags macro and explains me what i'm doing wrong and how to
>>> correct it.
>>>
>>> I played around alot but can't get it right.
>>>
>>>
>>> best regards!
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190609/45fa0e5b/attachment.html>

From workbench at gmx.at  Sun Jun  9 03:11:00 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 09:11:00 +0200
Subject: [CMake] Question about a simple macro.
In-Reply-To: <cb00716b-0c37-150a-7502-4070ac22eb7d@gmx.at>
References: <d31a42c6-7f3e-6b21-e8c8-9d6fe83143c2@gmx.at>
 <3813a307-9d81-7aa5-4ed6-1c3afe6a55b9@gmx.at>
 <60a40eab-6766-cb93-360b-59951e81b5c7@gmx.at>
 <cb00716b-0c37-150a-7502-4070ac22eb7d@gmx.at>
Message-ID: <e3196c99-ef1e-e3c1-7147-38a6da2b8408@gmx.at>

How on earth can i create a variables out of the string flags_to_add ???



On 09.06.19 08:41, Steven Truppe wrote:
>
> OK, i don't realy understand why it does work but i got it working:
>
> include(CMakePrintHelpers)
> macro(bsMergeFlags flags_to_add flags)
>  ??? set(flags_to_add ${flags_to_add} ${ARGN} )
>  ??? cmake_print_variables(flags_to_add)
>
>  ??? message(STATUS "bsMergeFlags ${flags_to_add}")
>  ??? list(APPEND flags ${tmp})
>  ??? message(STATUS "------------")
> endmacro()
>
> Now my problem is that the content of flags_to_add is correct when i
> use cmake_print_variables but not when i try to use it in a message()
> call.
>
>
> I think i do miss some very important part when it comes to variables
> - i'm now studying the hole chapter again, hopefully i understand it then.
>
>
> I hope you guys can help me.
>
>
> best regards!
>
>
> On 09.06.19 08:26, Steven Truppe wrote:
>> ARGV1 gives me the first list entry of my first arguments, but i don't
>> know how i can access the hole list.
>>
>>
>> best regards!
>>
>> On 09.06.19 07:20, Steven Truppe wrote:
>>> Do i need cmake_parse_arguments ??
>>>
>>> On 09.06.19 07:01, Steven Truppe wrote:
>>>> Hi everyone,
>>>>
>>>> i'm a c,c++,asm and a few other languages, but i still have troubles
>>>> with macros and their arguments.
>>>>
>>>> As a simple example i would like to have a macro that list(APPEND the
>>>> two passed arguments), here the code i tried:
>>>>
>>>> https://wandbox.org/permlink/WQZGty9PQaOz3422.
>>>>
>>>>
>>>> Let's forget about the list(APPEND) line, i just need an example that
>>>> prints me out the first and the second argument and i'm not able to
>>>> get
>>>> it right. Would someone please explain to me how i can do this right ?
>>>> I've read the book but that didn't helped me completely.
>>>>
>>>> I hope someone here is so nice to me to explain to me how i can write
>>>> the bsMergeFlags macro and explains me what i'm doing wrong and how to
>>>> correct it.
>>>>
>>>> I played around alot but can't get it right.
>>>>
>>>>
>>>> best regards!
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190609/85367791/attachment.html>

From workbench at gmx.at  Sun Jun  9 06:30:18 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 9 Jun 2019 12:30:18 +0200
Subject: [CMake] Question about a simple macro.
In-Reply-To: <e3196c99-ef1e-e3c1-7147-38a6da2b8408@gmx.at>
References: <d31a42c6-7f3e-6b21-e8c8-9d6fe83143c2@gmx.at>
 <3813a307-9d81-7aa5-4ed6-1c3afe6a55b9@gmx.at>
 <60a40eab-6766-cb93-360b-59951e81b5c7@gmx.at>
 <cb00716b-0c37-150a-7502-4070ac22eb7d@gmx.at>
 <e3196c99-ef1e-e3c1-7147-38a6da2b8408@gmx.at>
Message-ID: <8ec6fa87-2d63-5109-9682-1e806f6159d4@gmx.at>

Problem solved - thanks anyway...

On 09.06.19 09:11, Steven Truppe wrote:
>
> How on earth can i create a variables out of the string flags_to_add ???
>
>
>
> On 09.06.19 08:41, Steven Truppe wrote:
>>
>> OK, i don't realy understand why it does work but i got it working:
>>
>> include(CMakePrintHelpers)
>> macro(bsMergeFlags flags_to_add flags)
>>  ??? set(flags_to_add ${flags_to_add} ${ARGN} )
>>  ??? cmake_print_variables(flags_to_add)
>>
>>  ??? message(STATUS "bsMergeFlags ${flags_to_add}")
>>  ??? list(APPEND flags ${tmp})
>>  ??? message(STATUS "------------")
>> endmacro()
>>
>> Now my problem is that the content of flags_to_add is correct when i
>> use cmake_print_variables but not when i try to use it in a message()
>> call.
>>
>>
>> I think i do miss some very important part when it comes to variables
>> - i'm now studying the hole chapter again, hopefully i understand it
>> then.
>>
>>
>> I hope you guys can help me.
>>
>>
>> best regards!
>>
>>
>> On 09.06.19 08:26, Steven Truppe wrote:
>>> ARGV1 gives me the first list entry of my first arguments, but i don't
>>> know how i can access the hole list.
>>>
>>>
>>> best regards!
>>>
>>> On 09.06.19 07:20, Steven Truppe wrote:
>>>> Do i need cmake_parse_arguments ??
>>>>
>>>> On 09.06.19 07:01, Steven Truppe wrote:
>>>>> Hi everyone,
>>>>>
>>>>> i'm a c,c++,asm and a few other languages, but i still have troubles
>>>>> with macros and their arguments.
>>>>>
>>>>> As a simple example i would like to have a macro that list(APPEND the
>>>>> two passed arguments), here the code i tried:
>>>>>
>>>>> https://wandbox.org/permlink/WQZGty9PQaOz3422.
>>>>>
>>>>>
>>>>> Let's forget about the list(APPEND) line, i just need an example that
>>>>> prints me out the first and the second argument and i'm not able
>>>>> to get
>>>>> it right. Would someone please explain to me how i can do this
>>>>> right ?
>>>>> I've read the book but that didn't helped me completely.
>>>>>
>>>>> I hope someone here is so nice to me to explain to me how i can write
>>>>> the bsMergeFlags macro and explains me what i'm doing wrong and
>>>>> how to
>>>>> correct it.
>>>>>
>>>>> I played around alot but can't get it right.
>>>>>
>>>>>
>>>>> best regards!
>>>>>
>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190609/ea510967/attachment.html>

From petr.kmoch at gmail.com  Mon Jun 10 04:52:45 2019
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 10 Jun 2019 10:52:45 +0200
Subject: [CMake] Question about config_file.
In-Reply-To: <60317551-2b42-b62b-dd46-6e2663cacf3d@gmx.at>
References: <60317551-2b42-b62b-dd46-6e2663cacf3d@gmx.at>
Message-ID: <CAKohaZfXFreODOgaN8C=a+8UZOvh++Scju4L6U4-sDFvKfaqog@mail.gmail.com>

Hi Steven.

"what is the configure_file command for?"

https://cmake.org/cmake/help/latest/command/configure_file.html

"what is Doxygen.in?"

Check its contents at wherever you found the example for details, but it
should be a template for the Doxygen configuration file (the config file
read by Doxygen).

Petr

On Sun, 9 Jun 2019 at 00:18, Steven Truppe <workbench at gmx.at> wrote:

> Hi everyone,
>
> currently i'm trying to build my doxygen documentation from my
> CMakeLists.txt file. I found the following example that seems to be
> correct:
>
> ######################
> ## bsBuildDoxygen() ##
> ######################
> macro(bsBuildDocs)
> 	if(GENERATE_DOCS)
> 		# check if Doxygen is installed
> 		find_package(Doxygen)
> 		if(DOXYGEN_FOUND)
> 			# set input and output files
> 			set(DOXYGEN_IN ${CMAKE_CURRENT_SOURCE_DIR}/doc/manual/Doxyfile.in)
> 			set(DOXYGEN_OUT ${CMAKE_CURRENT_SOURCE_DIR}/doc/manual/Doxyfile)
>
> 			# request to configure the file
> 			configure_file(${DOXYGEN_IN} ${DOXYGEN_OUT} @ONLY)
> 			message("Doxygen build started")
>
> 			# note the option ALL which allows to build the docs together with the application
> 			add_custom_target( doc_doxygen ALL
> 				COMMAND ${DOXYGEN_EXECUTABLE} ${DOXYGEN_OUT}
> 				WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
> 				COMMENT "Generating API documentation with Doxygen"
> 				VERBATIM )
> 		else()
> 		  message("Doxygen need to be installed to generate the doxygen documentation")
> 		endif()
> 	endif()
> endmacro()
>
> Now my question is about the configure_file command. what is Doxygen.in
> and what is the configure_file command for ?
>
>
> best regards!
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190610/a9e64f91/attachment.html>

From juan.e.sanchez at gmail.com  Mon Jun 10 09:10:39 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Mon, 10 Jun 2019 08:10:39 -0500
Subject: [CMake] Question about getting git branch name.
In-Reply-To: <a16e3138-af55-3f1a-6086-765093095cea@gmx.at>
References: <a16e3138-af55-3f1a-6086-765093095cea@gmx.at>
Message-ID: <CAEHOsR1LcNNq4-uhzxZGVj4ARSoWPtRNTTRwDuBA9_6o=8+emQ@mail.gmail.com>

Hello,

https://stackoverflow.com/questions/1417957/show-just-the-current-branch-in-git

suggests:

git rev-parse --abbrev-ref HEAD

Regards,

Juan


On Sat, Jun 8, 2019 at 5:25 PM Steven Truppe <workbench at gmx.at> wrote:

> Hi everyone,
>
> i want to have code lines like:
>
> #define BUILD_VERSION
>
> and the BUILD_VERSION should be the name of the actual branch the code
> was compiled with, this way i can create a branch for each version and
> name it like 0.1 so each version i'm using for release is an own branch.
>
> I found many examples that shows me the branch name (like git status)
> but i don't know a way to get only the name of the current branch so i
> can for example execute_process to get the revision number into a
> variable and then use add_definition(..) to add it as a compile definition.
>
>
> best regards!
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190610/d42e8601/attachment.html>

From staley at lanl.gov  Mon Jun 10 22:31:02 2019
From: staley at lanl.gov (Staley, Martin Frank)
Date: Tue, 11 Jun 2019 02:31:02 +0000
Subject: [CMake] Individualized compile_commands.json per executable target?
Message-ID: <07b3b5a723204351be1950336b59ad8a@lanl.gov>

I'm using the Clang/LLMV APIs to build a code analysis tool that gives my users some additional analysis of their C++ codes, above and beyond what the compiler, proper, provides.

With a set(CMAKE_EXPORT_COMPILE_COMMANDS ON) in CMakeLists.txt, cmake emits a "compilation database" file, compile_commands.json, that contains exact compilation commands for all relevant source files. The .json can be consumed by my analysis tool to get what it needs. Except....

Here's the problem. (And I've tried various googles, but nothing panned out.) compile_commands.json contains data for *all* source files involved in *any* executable for which cmake emits Makefile rules. My analysis tool needs input that reflects those (and only those) source files that are involved in any *one* of the (generally more than one) executables.

EXAMPLE. Say I have some general C++ constructs in a.cc, b.cc, and c.cc, and two C++ executables (roughly speaking, with a main()): foo.cc and bar.cc. Assume further that, linkage-wise, foo.cc needs the material from a.cc and b.cc (but not c.cc), while bar.cc needs the material from b.cc and c.cc (but not a.cc). These dependencies are of course programmed into a CMakeLists.txt.

In this situation, cmake will emit a compile_commands.json that has commands for all five sources: {a.cc, b.cc, c.cc, foo.cc, bar.cc}. But my analysis tool, run thereon, doesn't know how to divvy up the various elements, and it ends up reporting, among other things, the moral equivalent of multiply-defined symbol errors.

Ideally, I'd love to have a way that Cmake could emit, say, foo.json containing only the compile commands for {a.cc, b.cc, foo.cc}, and a bar.json containing only the commands for {b.cc, c.cc, bar.cc}. Basically, individualized compilation databases for each executable target.

There are, of course, alternatives. Given additional input, my tool could pull (only) the proper entries from the current, aggregated compile_commands.json. Or, post-cmake, I could allow for a dry-run verbose make of a single executable, and parse out the requisite information. For users, however, and for simplicity's sake, I'm hoping for something more direct. CMake has what I need, in some form - it must, in order to create the Makefile! So, life would be absolutely fabulous if this existing knowledge could be used to create executable-specific .json databases as outlined above.

Is this in fact available, and my googling skills aren't up to par? If it isn't, might it be considered for a future CMake release?


--
Martin Staley
CCS-7, Applied Computer Science
Mail Stop B287
Los Alamos National Laboratory
Los Alamos, NM 87545
Office: 03/508/122
Phone: 1-505-667-7108

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190611/69f9a8d0/attachment.html>

From eric.noulard at gmail.com  Tue Jun 11 03:42:09 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 11 Jun 2019 09:42:09 +0200
Subject: [CMake] Individualized compile_commands.json per executable
 target?
In-Reply-To: <07b3b5a723204351be1950336b59ad8a@lanl.gov>
References: <07b3b5a723204351be1950336b59ad8a@lanl.gov>
Message-ID: <CAPASGLqkMJ2gy1TOCPMxAknMBDMKKLvDa8LpHGUcncFEoP5_Qw@mail.gmail.com>

Le mar. 11 juin 2019 ? 05:16, Staley, Martin Frank via CMake <
cmake at cmake.org> a ?crit :

> I'm using the Clang/LLMV APIs to build a code analysis tool that gives my
> users some additional analysis of their C++ codes, above and beyond what
> the compiler, proper, provides.
>
> With a set(CMAKE_EXPORT_COMPILE_COMMANDS ON) in CMakeLists.txt, cmake
> emits a "compilation database" file, compile_commands.json, that contains
> exact compilation commands for all relevant source files. The .json can be
> consumed by my analysis tool to get what it needs. Except....
>
> Here's the problem. (And I've tried various googles, but nothing panned
> out.) compile_commands.json contains data for *all* source files involved
> in *any* executable for which cmake emits Makefile rules. My analysis tool
> needs input that reflects those (and only those) source files that are
> involved in any *one* of the (generally more than one) executables.
>
> EXAMPLE. Say I have some general C++ constructs in a.cc, b.cc, and c.cc,
> and two C++ executables (roughly speaking, with a main()): foo.cc and
> bar.cc. Assume further that, linkage-wise, foo.cc needs the material from
> a.cc and b.cc (but not c.cc), while bar.cc needs the material from b.cc and
> c.cc (but not a.cc). These dependencies are of course programmed into a
> CMakeLists.txt.
>
> In this situation, cmake will emit a compile_commands.json that has
> commands for all five sources: {a.cc, b.cc, c.cc, foo.cc, bar.cc}. But my
> analysis tool, run thereon, doesn't know how to divvy up the various
> elements, and it ends up reporting, among other things, the moral
> equivalent of multiply-defined symbol errors.
>
> Ideally, I'd love to have a way that Cmake could emit, say, foo.json
> containing only the compile commands for {a.cc, b.cc, foo.cc}, and a
> bar.json containing only the commands for {b.cc, c.cc, bar.cc}. Basically,
> individualized compilation databases for each executable target.
>
> There are, of course, alternatives. Given additional input, my tool could
> pull (only) the proper entries from the current, aggregated
> compile_commands.json. Or, post-cmake, I could allow for a dry-run verbose
> make of a single executable, and parse out the requisite information. For
> users, however, and for simplicity's sake, I'm hoping for something more
> direct. CMake has what I need, in some form - it must, in order to create
> the Makefile! So, life would be absolutely fabulous if this existing
> knowledge could be used to create executable-specific .json databases as
> outlined above.
>

> Is this in fact available, and my googling skills aren't up to par?
>

This is not exactly what you are looking for but you may certainly use the
CMake file-api:
https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html#manual:cmake-file-api(7)
in order to get what you want (namelly the list of files for a given target)

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190611/cb7b9ef1/attachment.html>

From d3ck0r at gmail.com  Wed Jun 12 06:10:23 2019
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 12 Jun 2019 03:10:23 -0700
Subject: [CMake] CMake is Converting lists to strings
Message-ID: <CAA2GJqXgGiNxrmpMpO8JfWrE8SqB-v82_07wxhNWXfQ4ziiVLg@mail.gmail.com>

I'm collecting sources and includes into a parent scope variable, and then
attempting to use that variable to reference the right sources.
Sources get added to the list as ../(theirpath)/(source) so in the parent
level I can simply replace "../" with "" and then they are relative in the
right place.
This works; as far as, the includes, sources and defines get all collected
into the top level, but when i try to remove the ../ the list gets
converted into a string.

# Create a list of things
set( SIMPLE_LIST -I../lib1/include -I../lib2/include -I../lib3/include )
# set a variable using that list...
  set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
# this outputs
COMMAND:echo;-I../lib1/include;-I../lib2/include;-I../lib3/include
  message( "COMMAND:${AMALG_COMMAND}")

# replace ../ with nothing
STRING( REPLACE "../" "" SIMPLE_LIST ${SIMPLE_LIST} )
# re-set a variable with the eventual command to run
  set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
# this outputs COMMAND:echo;-Ilib1/include -Ilib2/include -Ilib3/include
  message( "COMMAND:${AMALG_COMMAND}")

When that final command actually gets run in a
  add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/out.c   COMMAND
${AMALG_COMMAND}  )

Then the command is 'echo "-Ilib1/include -Ilib2/include -Ilib3/include"'
which is incorrect.


I tried first LIST(JOIN) but that defiantly makes a string and doesn't help.
string(REPLACE " " ";" SIMPLE_LIST ${SIMPLE_LIST})  to try and reverse it
back to a list doesn't seem to help...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190612/7f43e8fe/attachment.html>

From d3ck0r at gmail.com  Wed Jun 12 06:22:30 2019
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 12 Jun 2019 03:22:30 -0700
Subject: [CMake] CMake is Converting lists to strings
In-Reply-To: <CAA2GJqXgGiNxrmpMpO8JfWrE8SqB-v82_07wxhNWXfQ4ziiVLg@mail.gmail.com>
References: <CAA2GJqXgGiNxrmpMpO8JfWrE8SqB-v82_07wxhNWXfQ4ziiVLg@mail.gmail.com>
Message-ID: <CAA2GJqVdw1TV08RF_ngfu4ypYOStQNPPOEngvPMx+E+=sdpGMA@mail.gmail.com>

I know... just need to rebuild a new list... something like....

 set( _ALL_INCLUDES )
foreach( INC ${ALL_INCLUDES})
    string(REPLACE "../" "" INC ${INC})
    LIST( APPEND _ALL_INCLUDES ${INC} )
endforeach( INC )
set( ALL_INCLUDES ${_ALL_INCLUDES})

On Wed, Jun 12, 2019 at 3:10 AM J Decker <d3ck0r at gmail.com> wrote:

> I'm collecting sources and includes into a parent scope variable, and then
> attempting to use that variable to reference the right sources.
> Sources get added to the list as ../(theirpath)/(source) so in the parent
> level I can simply replace "../" with "" and then they are relative in the
> right place.
> This works; as far as, the includes, sources and defines get all collected
> into the top level, but when i try to remove the ../ the list gets
> converted into a string.
>
> # Create a list of things
> set( SIMPLE_LIST -I../lib1/include -I../lib2/include -I../lib3/include )
> # set a variable using that list...
>   set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
> # this outputs
> COMMAND:echo;-I../lib1/include;-I../lib2/include;-I../lib3/include
>   message( "COMMAND:${AMALG_COMMAND}")
>
> # replace ../ with nothing
> STRING( REPLACE "../" "" SIMPLE_LIST ${SIMPLE_LIST} )
> # re-set a variable with the eventual command to run
>   set( AMALG_COMMAND echo ${SIMPLE_LIST}  )
> # this outputs COMMAND:echo;-Ilib1/include -Ilib2/include -Ilib3/include
>   message( "COMMAND:${AMALG_COMMAND}")
>
> When that final command actually gets run in a
>   add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/out.c   COMMAND
> ${AMALG_COMMAND}  )
>
> Then the command is 'echo "-Ilib1/include -Ilib2/include -Ilib3/include"'
> which is incorrect.
>
>
> I tried first LIST(JOIN) but that defiantly makes a string and doesn't
> help.
> string(REPLACE " " ";" SIMPLE_LIST ${SIMPLE_LIST})  to try and reverse it
> back to a list doesn't seem to help...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190612/df8d605d/attachment.html>

From marc.chevrier at gmail.com  Wed Jun 12 06:34:12 2019
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Wed, 12 Jun 2019 12:34:12 +0200
Subject: [CMake] CMake is Converting lists to strings
In-Reply-To: <CAA2GJqVdw1TV08RF_ngfu4ypYOStQNPPOEngvPMx+E+=sdpGMA@mail.gmail.com>
References: <CAA2GJqXgGiNxrmpMpO8JfWrE8SqB-v82_07wxhNWXfQ4ziiVLg@mail.gmail.com>
 <CAA2GJqVdw1TV08RF_ngfu4ypYOStQNPPOEngvPMx+E+=sdpGMA@mail.gmail.com>
Message-ID: <03c92b27-36fc-4832-b5b1-690cb3a7e568@Spark>

You are wrongly using the STRING(REPLACE ?) command.

The right way to use it to avoid list conversion is to expand the list inside?quotes (to preserve list items separators):

STRING (REPLACE "../" "" SIMPLE_LIST "${SIMPLE_LIST}")

Without the quotes, all list elements are concatenated in the result string (see documentation).

Another possibility is using LIST(TRANSFORM ?):

LIST(TRANSFORM SIMPLE_LIST REPLACE ??^\\.\\./" ?"")
Le 12 juin 2019 ? 12:22 +0200, J Decker <d3ck0r at gmail.com>, a ?crit :
> I know... just need to rebuild a new list... something like....
>
> ?set( _ALL_INCLUDES )
> foreach( INC ${ALL_INCLUDES})
> ? ? string(REPLACE "../" "" INC ${INC})
> ? ? LIST( APPEND _ALL_INCLUDES ${INC} )
> endforeach( INC )
> set( ALL_INCLUDES ${_ALL_INCLUDES})
>
> > On Wed, Jun 12, 2019 at 3:10 AM J Decker <d3ck0r at gmail.com> wrote:
> > > I'm collecting sources and includes into a parent scope variable, and then attempting to use that variable to reference the right sources.
> > > Sources get added to the list as ../(theirpath)/(source) so in the parent level I can simply replace "../" with "" and then they are relative in the right place.
> > > This works; as far as, the includes, sources and defines get all collected into the top level, but when i try to remove the ../ the list gets converted into a string.
> > >
> > > # Create a list of things
> > > set( SIMPLE_LIST -I../lib1/include -I../lib2/include -I../lib3/include )
> > > # set a variable using that list...
> > > ? set( AMALG_COMMAND echo ${SIMPLE_LIST} ?)
> > > # this outputs COMMAND:echo;-I../lib1/include;-I../lib2/include;-I../lib3/include
> > > ? message( "COMMAND:${AMALG_COMMAND}")
> > >
> > > # replace ../ with nothing
> > > STRING( REPLACE "../" "" SIMPLE_LIST ${SIMPLE_LIST} )
> > > # re-set a variable with the eventual command to run
> > > ? set( AMALG_COMMAND echo ${SIMPLE_LIST} ?)
> > > # this outputs COMMAND:echo;-Ilib1/include -Ilib2/include -Ilib3/include
> > > ? message( "COMMAND:${AMALG_COMMAND}")
> > >
> > > When that final command actually gets run in a
> > > ? add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/out.c? ?COMMAND ${AMALG_COMMAND}? )
> > >
> > > Then the command is 'echo "-Ilib1/include -Ilib2/include -Ilib3/include"' which is incorrect.
> > >
> > >
> > > I tried first LIST(JOIN) but that defiantly makes a string and doesn't help.
> > > string(REPLACE " " ";" SIMPLE_LIST ${SIMPLE_LIST})? to try and reverse it back to a list doesn't seem to help...
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190612/6521f1ef/attachment.html>

From jstrecker-cmake at kosada.com  Wed Jun 12 14:43:08 2019
From: jstrecker-cmake at kosada.com (Jaymie Strecker)
Date: Wed, 12 Jun 2019 14:43:08 -0400
Subject: [CMake] How do you test partial rebuilds?
In-Reply-To: <F4C4317F-6878-45E2-B865-E8BBE6EB8909@kosada.com>
References: <F4C4317F-6878-45E2-B865-E8BBE6EB8909@kosada.com>
Message-ID: <AD10E402-CC5E-46EB-95D1-4827CCED97A7@kosada.com>

The solution we arrived at was to write a https://behat.org/ <https://behat.org/> backend to perform automated tests of our incremental builds.  The Behat backend copies the project's source tree to a temporary folder, then runs a scripted test suite on it, which looks like this:

   Feature: Incremental builds
   Check that modifying certain source files causes certain build steps to be performed (or not performed).

      Scenario: Editing a core type header
         Given a completed build
         When  I edit type/integer.h
         And   I build

         Then  it should update lib/MyFramework.framework/Headers/integer.h
         And   it should update lib/MyFramework.framework/MyFramework
         And   it should update bin/MyApp.app/Contents/Frameworks/MyFramework.framework/Headers/integer.h
         And   it should update bin/MyApp.app/Contents/Frameworks/MyFramework.framework/MyFramework
         And   it should update the compiler's cache

      Scenario: ?

   Feature: Compiler developer mode
   Check that compiler developer mode properly reduces build dependencies,
   to reduce edit-compile-run cycle time when working on the compiler.

      Scenario: Enabling compiler developer mode
         Given a completed build
         When  I run CMake with arguments "-DCOMPILER_DEVELOPER=ON"
         And   I build
         Then  it shouldn't do anything

      Scenario: Editing a compiler source file when in compiler developer mode
         Given a completed build
         When  I edit compiler/compiler.cc <http://compiler.cc/>
         And   I build

         Then  it should update lib/libMyCompiler.a
         And   it should update bin/my-compiler

         But   it shouldn't update the compiler's cache
         And   it shouldn't update bin/something-compiled-using-my-compiler

      Scenario: ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190612/3c1eb8c9/attachment.html>

From thorsten.schmitz.bn.90 at gmail.com  Thu Jun 13 13:35:48 2019
From: thorsten.schmitz.bn.90 at gmail.com (Thorsten Hofer-Schmitz)
Date: Thu, 13 Jun 2019 19:35:48 +0200
Subject: [CMake] Cross-Compiling with CMake and QtCreator
Message-ID: <ae0fe19a-076d-bbf7-86fc-5926de378082@gmail.com>

Hi,

I want to compile a program for Android. I work on Windows 10. Because I
recently reinstalled my OS everything isn't older than two month. I
Installed everything using Qt's, Android Studio's (and for Windows 
Visual Studio's) installers/SDK Manager, to prevent mistakes I might 
have made.

I'm not new to programming, but I haven't worked much with build systems
until now, alsways used what QtCreator/VS offers. But I want to do more 
and after some research I decided to go with CMake.

So I made a new project in QtCreator (empty QtQuick project template).
Using qmake works fine for both Windows and Android, so the toolchains
should all be fine so far. But when I make the same empty project as 
CMake project I get errors for Android. For Windows it works fine so far.

At first CMake didn't find Ninja for Android (but did find it for
Windows). So I added the it's location to PATH.

Now it could find Ninja, but I got

           The C++ compiler


"C:/Android/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe"

           is not able to compile a simple test program.

I searched on google, and aside from a lot of posts that didn't help at
all, I found this:


https://stackoverflow.com/questions/53633705/cmake-the-c-compiler-is-not-able-to-compile-a-simple-test-program

suggesting it's caused by CMake trying to run an Android application on
Windows, and to add

           set (CMAKE_C_COMPILER_WORKS 1)
           set (CMAKE_CXX_COMPILER_WORKS 1)

before project() to omit the test. And it now changed the error to

           No known features for CXX compiler

           "Clang"

           version 8.0.2.

Again, I googled. But all I could find was related to old bugs or other
IDE's/OS's.

So I hope to get some help here now.

Best regards

Thorsten

From marc.herbert at gmail.com  Thu Jun 13 13:53:23 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Thu, 13 Jun 2019 10:53:23 -0700
Subject: [CMake] Question about getting git branch name.
In-Reply-To: <a16e3138-af55-3f1a-6086-765093095cea@gmx.at>
References: <a16e3138-af55-3f1a-6086-765093095cea@gmx.at>
Message-ID: <CA+rkZbhgcPg_HkQAiETUOu3jhY=xHOKc_y0baU77yx-dRHfCNw@mail.gmail.com>

Try: git describe --all or git describe --all --dirty --long
git help describe

PS: a git branch is effectively a *moving* tag so for a BUILD_VERSION it
seems wrong to rely on branches (--all) instead of tags. I think you mean
BUILD_BRANCH instead of BUILD_VERSION.

Le sam. 8 juin 2019 ? 15:25, Steven Truppe <workbench at gmx.at> a ?crit :

> Hi everyone,
>
> i want to have code lines like:
>
> #define BUILD_VERSION
>
> and the BUILD_VERSION should be the name of the actual branch the code
> was compiled with, this way i can create a branch for each version and
> name it like 0.1 so each version i'm using for release is an own branch.
>
> I found many examples that shows me the branch name (like git status)
> but i don't know a way to get only the name of the current branch so i
> can for example execute_process to get the revision number into a
> variable and then use add_definition(..) to add it as a compile definition.
>
>
> best regards!
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190613/93963973/attachment.html>

From marc.herbert at gmail.com  Thu Jun 13 14:06:04 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Thu, 13 Jun 2019 11:06:04 -0700
Subject: [CMake] In add_subdirectory( binary_dir),
 binary_dir/ is just a decoy when there's no sub-target
In-Reply-To: <CA+rkZbiK9na=PKn27r-+X14z=n-4CN5H7xd4cYTHUO_JAZau3A@mail.gmail.com>
References: <CA+rkZbiK9na=PKn27r-+X14z=n-4CN5H7xd4cYTHUO_JAZau3A@mail.gmail.com>
Message-ID: <CA+rkZbjRgQUor5R4oHE8SmKR+P7TR7U+OdGVLJTYaJR80Whk8Q@mail.gmail.com>

Ping?

I'd like to file a bug but I don't know what is the intended behavior:
1. Should binary_dir work even when no target?
2. Should CMake warn/error that binary_dir is not supported unless targets
are used?

Marc

Le mar. 4 juin 2019 ? 12:05, Marc Herbert <marc.herbert at gmail.com> a ?crit :

> tl;dr: should there be at least one target per CMakeLists.txt?
>
> https://cmake.org/cmake/help/v3.14/command/add_subdirectory.html
> > add_subdirectory(source_dir [binary_dir] )
> > "The binary_dir specifies the directory in which to place the output
> files. [...] If binary_dir is not specified, the value of source_dir,
> before expanding any relative path, will be used (the typical usage)."
>
> I found this part of the documentation to be correct ONLY when the
> subdirectory defines and uses its own "sub-"target(s). If the subdirectory
> refers to higher main targets instead then binary_dir/ is just a decoy: the
> subdirectory build happens elsewhere. binary_dir is a decoy whether it's
> explicit or default. It exists but there are only totally generic and
> unused files there.
>
> Example:
>
> mainsrc/
> ??? CMakeLists.txt
> ??? inmodule
> ?   ??? CMakeLists.txt
> ?   ??? infile.c
> ??? mainfile.c
>
>
> # mainsrc/CMakeLists.txt
> add_executable(mainexe mainfile.c)
> add_subdirectory(inmodule [ decoy_binary_dir ] )
>
> # mainsrc/inmodule/CMakeLists.txt
> target_sources(mainexe PRIVATE infile.c) # <= direct reference, no
> sub-target
>
>
> cmake -GNinja -B build -S mainsrc && ninja -C build
>
> build
> ??? CMakeFiles
> ?   ???
> ?   ??? mainexe.dir
> ?   ?   ???
> ?   ?   ???
> ?   ?   ??? inmodule       <= ACTUAL binary_dir!
> ?   ?   ?   ??? infile.c.o
> ?   ?   ??? mainfile.c.o
> ?   ?   ???
> ?   ?   :
> ?   ???
> ?   :
> ??? inmodule       <= decoy with unused, boilerplate files and no
> reference to any code
> ?   ??? CMakeFiles/
> ?   ??? cmake_install.cmake
>
>
> The midly irritating part is that cmake complains about the lack of a
> binary_dir argument if the module is an _out-of-tree_ subdirectory:
>
> CMake Error at CMakeLists.txt:5 (add_subdirectory):
>   add_subdirectory not given a binary directory but the given source
>   directory "~/cmake-test/outmodule" is not a subdirectory of
>   "~/cmake-test/maindir".  When specifying an out-of-tree source
>   a binary directory must be explicitly specified.
>
> That request makes sense of course except... when given that binary_dir
> argument it requested, it's still becomes a decoy as described above.
> This is the actual (and funny) binary_dir /in this out-of-tree case:
> build
> ??? CMakeFiles
> ?   ??? mainexe.dir
> ?   ?   ??? home
> ?   ?       ??? joe
> ?   ?           ??? cmake-test
> ?   ?               ??? outmodule
> ?   ?                   ??? outfile.c.o
>
>
>
> Reproduced with cmake version 3.14.4. No difference between make and ninja.
>
> Researching the interwebs most people, tutorials and other documents seem
> to assume (at least) one target per CMakeLists.txt. Should such a
> recommendation be made more official to avoid the sort of confusion above?
> Could this recommendation avoid other, unrelated problems I haven't
> experienced? Yet?
>
> Marc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190613/a23dc027/attachment.html>

From chuck.atkins at kitware.com  Fri Jun 14 09:08:29 2019
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Fri, 14 Jun 2019 09:08:29 -0400
Subject: [CMake] General question about variable scope.
In-Reply-To: <7cab1ae5-cea7-9865-f5b4-7a890e0bdea1@gmx.at>
References: <7cab1ae5-cea7-9865-f5b4-7a890e0bdea1@gmx.at>
Message-ID: <CAOXZzG5dZ5zC5Kn_=ELTAf-fnpQZ+3bvNP=j+-tQe2R2rb3wfg@mail.gmail.com>

So, a couple things:

	    string(TOUPPER ${lib} lib_upper)
> 	    set(WITH_LIB_${lib_upper}_EXAMPLES "")
>
> This needs to be outside the foreach loop.  It's getting reset to empty on
every iteration rather than accumulating results

		list(APPEND ${WITH_LIB_${lib_upper}_EXAMPLES} ${CMAKE_MATCH_1})
>
> Don't de-reference the first argument, just use the variable name itself,
i.e.:
list(APPEND WITH_LIB_${lib_upper}_EXAMPLES ${CMAKE_MATCH_1})

This is also well suited to a function, which are generally preferred over
macros as it will avoid polluting the current variable scope with temporary
variables:

function(bsBuildLibExamples lib)
  string(TOUPPER ${lib} lib_upper)
  set(all_lib_examples)
  get_cmake_property(all_vars VARIABLES)
  foreach(var IN LISTS all_vars)
    if(var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-z]+)$")
      list(APPEND all_lib_examples ${CMAKE_MATCH_1})
    endif()
  endforeach()
  set(WITH_LIB_${lib_upper}_EXAMPLES "${all_lib_examples}" PARENT_SCOPE)
endmacro()

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190614/f39e3767/attachment-0001.html>

From afuller at teradici.com  Fri Jun 14 11:58:23 2019
From: afuller at teradici.com (Andrew Fuller)
Date: Fri, 14 Jun 2019 15:58:23 +0000
Subject: [CMake] CMake Release Candidate Builds Available for Ubuntu
In-Reply-To: <1559945151.3051.23.camel@kitware.com>
References: <1559945151.3051.23.camel@kitware.com>
Message-ID: <MWHPR19MB10724C7076F0B2B53245E35FD5EE0@MWHPR19MB1072.namprd19.prod.outlook.com>

Thanks for the RCs, Kyle (and the rest of the CMake crew).

I tried 3.15~rc1 and it seems to have been built without https support file(DOWNLOAD https://foo/bar) gives a status "1;Unsupported protocol".  This is with version  3.15.0~rc1-0kitware2 amd64 running on Bionic.
Version 3.14.5-0kitware1ubuntu18.04.1 runs just fine out of the box.

Cheers,
-Andrew
________________________________
From: CMake <cmake-bounces at cmake.org> on behalf of Kyle Edwards via CMake <cmake at cmake.org>
Sent: June 7, 2019 3:05 PM
To: CMake
Subject: [CMake] CMake Release Candidate Builds Available for Ubuntu

All,

I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.

If you would like to receive release candidate builds, follow the
instructions at https://apt.kitware.com/ to add the release candidate
repository to your installation. (Please note that the release
candidates are optional and opt-in - if you don't explicitly add the
release candidate repository, you will only receive production builds.)

In addition, starting with this release candidate, we are now offering
32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the
same as 64-bit - just add the repository to your installation and
install it.

Happy coding!

Kyle
--

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:
https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190614/72920b1c/attachment.html>

From william at williamzeitler.com  Sat Jun 15 15:33:38 2019
From: william at williamzeitler.com (William Zeitler)
Date: Sat, 15 Jun 2019 12:33:38 -0700
Subject: [CMake] Mingw64: add a statically linked library adds libstdc++
 dependency
Message-ID: <c7918768-f0bf-5aa6-973c-58ad42b61145@williamzeitler.com>

I want to accomplish a c++ executable that links to another c++ library 
of my own without a libstdc++ dependency. I can create such a c++ 
executable without the library without difficulty. But as soon as I link 
it to my library, the executable now has a libstdc++ dependency. A 
requirement is to NOT need to copy libstdc++6.dll (or any other .dll) 
onto Windows.

I'm building on Linux (Centos 7) using the latest mingw64 
(x86_64-w64-mingw32-gcc (GCC) 4.9.3), cross compiling to Windows. 
Building on MSYS2/MingW has the same unwanted result.

In the example below, two lines are marked "COMMENT ME OUT": one in 
hello_c/main.cpp and the other in hello_c/CMakeLists.txt. If you comment 
these out, the reference to the hello_lib library is removed; the 
project builds and the executable executes on Windows 10 without a 
libstdc++ dependency. If you uncomment the two lines, the function in 
the hello_lib library is linked in; the project builds, but won't 
execute on Windows 10 due to the libstdc++ dependency. (Note: in 
powershell it silently fails, in an old-school dos/cmd box it displays 
an error message.)

The example has this structure (contents below):

* hello_lib/library.cpp
* hello_lib/library.h
* hello_lib/CMakeLists.txt
* hello_c/main.cpp
* hello_c/CMakeLists.xt
* buildme.sh
* toolchain.cmake

###### BEGIN CODE ######
## hello_lib/library.h:
int hello();

## hello_lib/library.cpp:
#include "library.h"
int hello() {
 ??? return 666;
}

## hello_lib CMakeLists.txt:
cmake_minimum_required(VERSION 3.13)
project(hello_lib)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -static -static-libgcc 
-static-libstdc++")
add_library(hello_lib STATIC library.cpp)

## hello_c/main.cpp:
#include <iostream>
#include "../hello_lib/library.h"
int main() {
 ??? std::cout << "Hello, world" << std::endl;
 ??? //COMMENT ME OUT:
 ??? printf("x = %d\n", hello());
 ??? return 0;
}

## hello_c CMakeLists.txt:
cmake_minimum_required(VERSION 3.13)
project(hello_c)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -static -static-libgcc 
-static-libstdc++")
link_directories(../hello_lib/cmake-build-debug)
add_executable(hello_c main.cpp)
# COMMENT ME OUT:
target_link_libraries(hello_c -static-libgcc -static-libstdc++ 
libhello_lib.a)

## buildme.sh:
#!/bin/bash
set -e
for i in hello_lib hello_c
do
 ??? rm -rf $i/cmake-build-debug
 ??? mkdir $i/cmake-build-debug
 ??? pushd $i/cmake-build-debug
 ??? # For building Win64 on Linux (with MinW64):
 ??? cmake .. -DCMAKE_TOOLCHAIN_FILE="../toolchain.cmake" 
-DCMAKE_BUILD_TYPE=Debug
 ??? # For building Win64 on Win64/MSYS2/MinW64:
 ??? #cmake .. -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Debug
 ??? # For building Linux on Linux
 ??? #cmake .. -DCMAKE_BUILD_TYPE=Debug
 ??? make
 ??? popd
done

## toolchain.cmake:
set(CMAKE_SYSTEM_NAME Windows)
set(TOOLCHAIN_PREFIX x86_64-w64-mingw32)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g++)
set(CMAKE_RC_COMPILER ${TOOLCHAIN_PREFIX}-windres)
set(CMAKE_FIND_ROOT_PATH /usr/${TOOLCHAIN_PREFIX})

###### END CODE ######

With both MingW64 on Linux, and MingW64/MSYS2 on Windows 10, I get the 
libstdc++ dependency when I link with the 'hello_lib' library. In both 
cases if I comment out the reference to hello_lib, the libstdc++ 
dependency is eliminated.

I would be very grateful for your insight!

William Zeitler



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190615/a1495959/attachment.html>

From paul at mad-scientist.net  Sat Jun 15 19:22:04 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 15 Jun 2019 19:22:04 -0400
Subject: [CMake] Why do executables link static libs that shared libs were
 built from?
Message-ID: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>

I have a situation where I create a number of static libraries, then I
create a shared library from them, then I create an executable from the
shared library.

This seems straightforward, but I can't get it do work as I want.  The
behavior of STATIC -> SHARED for target property inheritance seems
incorrect to me.

I'm using CMake 3.14.5 on GNU/Linux for this test.

I need the compile properties of the static library (include
directories etc.) to be public for all users of the shared library as
well.  But obviously I don't want users of the shared library to also
link the static library!!  That defeats the whole purpose of the shared
library.

If I set up like this:

  $ touch foo.c bar.c
  $ echo 'int main() { return 0; }' > run.c

then write my CMakeFiles.txt like this:

  cmake_minimum_required(VERSION 3.13)
  project(Test C)

  add_library(foo STATIC foo.c)
  target_include_directories(foo PUBLIC /tmp)

  add_library(bar SHARED bar.c)
  target_link_libraries(bar PUBLIC foo)

  add_executable(run run.c)
  target_link_libraries(run PUBLIC bar)

Then, I DO get the -I/tmp forwarded up to run.c:

  cc -I/tmp -o CMakeFiles/run.dir/run.c.o -c run.c
     ^^^^^^

But libfoo.a is ALSO added to my link line, which is really wrong!

  cc CMakeFiles/run.dir/run.c.o  -o run -Wl,-rpath,. libbar.so libfoo.a
                                                               ^^^^^^^^

On the other hand if I change the link of foo to be PRIVATE instead of
PUBLIC:

  target_link_libraries(bar PRIVATE foo)

then the link doesn't include libfoo.a, which is good, but I also don't
have the -I/tmp when I compile run.c, which is wrong:

  cc -o CMakeFiles/run.dir/run.c.o -c run.c
  cc CMakeFiles/run.dir/run.c.o -o run -Wl,-rpath,. libbar.so

Does this seem wrong to anyone else?  Is there some trick to it?

Or do I have to resort to by-hand forwarding of build properties rather
than relying on a straightforward target_link_libraries() line?


From smeenai at fb.com  Sun Jun 16 00:02:47 2019
From: smeenai at fb.com (Shoaib Meenai)
Date: Sun, 16 Jun 2019 04:02:47 +0000
Subject: [CMake] Multiple exports for a target installation
Message-ID: <C739DF5E-E0DE-41C6-B6CF-25F23FE12FDF@fb.com>

Is it possible to associate a target with multiple exports? For example, if I'm building a project where I want to create multiple export sets, but there's some overlap in targets between those sets. I tried passing multiple EXPORT options to the install(TARGETS) signature but I just got an error: install TARGETS given unknown argument "EXPORT".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190616/f25b1e50/attachment-0001.html>

From craig.scott at crascit.com  Sun Jun 16 01:43:25 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 15 Jun 2019 22:43:25 -0700
Subject: [CMake] Multiple exports for a target installation
In-Reply-To: <C739DF5E-E0DE-41C6-B6CF-25F23FE12FDF@fb.com>
References: <C739DF5E-E0DE-41C6-B6CF-25F23FE12FDF@fb.com>
Message-ID: <CA+dygYk+OPb8MJQbQd1QRNSKQMCVaRbowSCVZepn-2Ejna9g4Q@mail.gmail.com>

On Sat, Jun 15, 2019 at 9:03 PM Shoaib Meenai <smeenai at fb.com> wrote:

> Is it possible to associate a target with multiple exports? For example,
> if I'm building a project where I want to create multiple export sets, but
> there's some overlap in targets between those sets. I tried passing
> multiple EXPORT options to the install(TARGETS) signature but I just got an
> error: install TARGETS given unknown argument "EXPORT".
>

Typically, you'd want your export sets to not be overlapping and to contain
no cyclic dependencies. If you have a target in multiple export sets, it
suggests that you probably should factor out that target to a separate
export set that other exports then depend on. That said, if you have a
scenario that legitimately requires a target in multiple export sets, then
you would need to use multiple install() commands to achieve this,
specifying a different export set for each one.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190615/244af691/attachment.html>

From craig.scott at crascit.com  Sun Jun 16 02:10:07 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 15 Jun 2019 23:10:07 -0700
Subject: [CMake] Why do executables link static libs that shared libs
 were built from?
In-Reply-To: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>
References: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>
Message-ID: <CA+dygYk0JnAciM_CcqbOS8GEjfsoYs-PuQr+8R_rDfxGfJ9gfQ@mail.gmail.com>

On Sat, Jun 15, 2019 at 5:01 PM Paul Smith <paul at mad-scientist.net> wrote:

> I have a situation where I create a number of static libraries, then I
> create a shared library from them, then I create an executable from the
> shared library.
>
> This seems straightforward, but I can't get it do work as I want.  The
> behavior of STATIC -> SHARED for target property inheritance seems
> incorrect to me.
>
> I'm using CMake 3.14.5 on GNU/Linux for this test.
>
> I need the compile properties of the static library (include
> directories etc.) to be public for all users of the shared library as
> well.  But obviously I don't want users of the shared library to also
> link the static library!!  That defeats the whole purpose of the shared
> library.
>
> If I set up like this:
>
>   $ touch foo.c bar.c
>   $ echo 'int main() { return 0; }' > run.c
>
> then write my CMakeFiles.txt like this:
>
>   cmake_minimum_required(VERSION 3.13)
>   project(Test C)
>
>   add_library(foo STATIC foo.c)
>   target_include_directories(foo PUBLIC /tmp)
>
>   add_library(bar SHARED bar.c)
>   target_link_libraries(bar PUBLIC foo)
>
>   add_executable(run run.c)
>   target_link_libraries(run PUBLIC bar)
>
> Then, I DO get the -I/tmp forwarded up to run.c:
>
>   cc -I/tmp -o CMakeFiles/run.dir/run.c.o -c run.c
>      ^^^^^^
>
> But libfoo.a is ALSO added to my link line, which is really wrong!
>
>   cc CMakeFiles/run.dir/run.c.o  -o run -Wl,-rpath,. libbar.so libfoo.a
>                                                                ^^^^^^^^
>
> On the other hand if I change the link of foo to be PRIVATE instead of
> PUBLIC:
>
>   target_link_libraries(bar PRIVATE foo)
>
> then the link doesn't include libfoo.a, which is good, but I also don't
> have the -I/tmp when I compile run.c, which is wrong:
>
>   cc -o CMakeFiles/run.dir/run.c.o -c run.c
>   cc CMakeFiles/run.dir/run.c.o -o run -Wl,-rpath,. libbar.so
>
> Does this seem wrong to anyone else?  Is there some trick to it?
>

The behaviour is correct according to what you are telling CMake to do. If
you use PUBLC in a target_link_libraries() call, you are saying that
anything that links to your shared library should also link to the static
library. PRIVATE would mean that the shared library uses the static library
internally but doesn't expose anything from the static library in the
shared library's interface or header files. If your executable needs to
know about the static library in any way (which means it includes any of
the static library's headers directly or any of the shared library's
headers pull them in), then the static library is no longer a private
dependency and has to be PUBLIC.



> Or do I have to resort to by-hand forwarding of build properties rather
> than relying on a straightforward target_link_libraries() line?
>

Look at your interfaces and header files carefully. Can you avoid referring
to anything from the static library in any of the shared library's public
headers (or any headers that those public headers pull in)? If so, then do
that and you can use target_link_libraries(bar PRIVATE foo). None of the
transitive properties of foo should be needed then either, so you'd have
nothing left to forward on. If you can't avoid it, then the static library
really is a public dependency and anything linking to bar should rightly
also be linking to foo.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190615/b507ad45/attachment.html>

From paul at mad-scientist.net  Sun Jun 16 12:04:22 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sun, 16 Jun 2019 12:04:22 -0400
Subject: [CMake] Why do executables link static libs that shared libs
 were built from?
In-Reply-To: <CA+dygYk0JnAciM_CcqbOS8GEjfsoYs-PuQr+8R_rDfxGfJ9gfQ@mail.gmail.com>
References: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>
 <CA+dygYk0JnAciM_CcqbOS8GEjfsoYs-PuQr+8R_rDfxGfJ9gfQ@mail.gmail.com>
Message-ID: <9caced6d44501dae40657d8a32be2933743899ea.camel@mad-scientist.net>

Let me just mention up-front that I spent about 2 weeks earlier this
year completely converting our circa-2011 cmake environment to ultra-
modern cmake: switching completely to TLL, interfaces, removing
virtually all if-statements and converting them into generator
expressions, etc.  So I'm very familiar with CMake's model for PRIVATE,
PUBLIC, and INTERFACE and how inheritance works.

And, I see the paradigm you're operating under where a shared library
provides a single "interface" that is public.

But, that's not the only way to use shared libraries.  I'm trying to
collect a number of static libraries with different interfaces into a
single shared library that can be linked with executables (in my case I
have 220 unit test programs which, when linked statically, not only
take a very long time and a lot of memory, but use about 45G of disk
space per build--I am collecting these into a shared library that can
be linked with our unit tests.  In my testing this reduces the size of
a sample unit test executable from 400M down to about 8M).

So: I need my shared library to export a combination of ALL the public
interfaces of the static libraries it was built from, but not,
obviously, export the static libraries themselves.


On Sat, 2019-06-15 at 23:10 -0700, Craig Scott wrote:
> The behaviour is correct according to what you are telling CMake to
> do. If you use PUBLC in a target_link_libraries() call, you are
> saying that anything that links to your shared library should also
> link to the static library.

That simply does not make sense, from the point of view of how a
program and a linker work (I understand it's how CMake works).

Let me work backwards, starting with a fact that hopefully we can all
agree on:

   It is NEVER appropriate to put a static library into the
   INTERFACE_LINK_LIBRARIES of a shared library.

I'd be interested to hear counter-arguments, but even if there are any
reasons for it my position is that in those very rare cases you should
be listing the static library in the TLL of the executable directly.

If we can agree on that, then using the current rules of CMake
inheritance this implies that we can NEVER add a static library as a
PUBLIC TLL for a shared library.

Which seems, to me, quite ridiculous because why shouldn't you want to
allow INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, and
INTERFACE_COMPILE_DIRECTORIES of the static library to be inherited by
the shared library into its PUBLIC interface?  That seems like a quite
reasonable thing to want to do.


From eric.noulard at gmail.com  Sun Jun 16 15:42:30 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Sun, 16 Jun 2019 21:42:30 +0200
Subject: [CMake] Why do executables link static libs that shared libs
 were built from?
In-Reply-To: <9caced6d44501dae40657d8a32be2933743899ea.camel@mad-scientist.net>
References: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>
 <CA+dygYk0JnAciM_CcqbOS8GEjfsoYs-PuQr+8R_rDfxGfJ9gfQ@mail.gmail.com>
 <9caced6d44501dae40657d8a32be2933743899ea.camel@mad-scientist.net>
Message-ID: <CAPASGLobZs7FC2ruR=WAEb3zmEM9u3aJPW7dM_1v9DHs4NNjtg@mail.gmail.com>

Le dim. 16 juin 2019 ? 18:26, Paul Smith <paul at mad-scientist.net> a ?crit :

> Let me just mention up-front that I spent about 2 weeks earlier this
> year completely converting our circa-2011 cmake environment to ultra-
> modern cmake: switching completely to TLL, interfaces, removing
> virtually all if-statements and converting them into generator
> expressions, etc.  So I'm very familiar with CMake's model for PRIVATE,
> PUBLIC, and INTERFACE and how inheritance works.
>
> And, I see the paradigm you're operating under where a shared library
> provides a single "interface" that is public.
>
> But, that's not the only way to use shared libraries.  I'm trying to
> collect a number of static libraries with different interfaces into a
> single shared library that can be linked with executables (in my case I
> have 220 unit test programs which, when linked statically, not only
> take a very long time and a lot of memory, but use about 45G of disk
> space per build--I am collecting these into a shared library that can
> be linked with our unit tests.  In my testing this reduces the size of
> a sample unit test executable from 400M down to about 8M).
>

Correct me if I'm wrong but I guess that if your goal is to "collect" all
those static libs *into* a shared
lib then what you need is to make your STATIC libs,  OBJECT libs and then I
think you'll get what you expect.
I.e. in your CMakeLists.txt
replace
add_library(foo STATIC foo.c)
with
add_library(foo OBJECT foo.c)

Otherwise (at least in the way CMake currently works) any symbols defined
in foo.a STATIC lib will *stay* in it. So in the end when you link an
executable
using bar.so SHARED lib only (which is using foo.a) then you won't have the
symbol
you need from foo unless foo.a is added to the link line ? Am I right ?


> So: I need my shared library to export a combination of ALL the public
> interfaces of the static libraries it was built from, but not,
> obviously, export the static libraries themselves.
>

But how can you do that without either:

1) adding the static lib to any link line (including the one using bar)
2) *merging* foo.a *into* bar.so which should be what you achieve by
    making foo an OBJECT lib.



> On Sat, 2019-06-15 at 23:10 -0700, Craig Scott wrote:
> > The behaviour is correct according to what you are telling CMake to
> > do. If you use PUBLC in a target_link_libraries() call, you are
> > saying that anything that links to your shared library should also
> > link to the static library.
>
> That simply does not make sense, from the point of view of how a
> program and a linker work (I understand it's how CMake works).
>
> Let me work backwards, starting with a fact that hopefully we can all
> agree on:
>
>    It is NEVER appropriate to put a static library into the
>    INTERFACE_LINK_LIBRARIES of a shared library.
>
> I'd be interested to hear counter-arguments, but even if there are any
> reasons for it my position is that in those very rare cases you should
> be listing the static library in the TLL of the executable directly.
>

Correct me if I'm wrong but you are saying that TLL(bar.so foo.a)  should
merge foo.a into bar.so ?
But TLL(myexe foo.a) should add foo.a in the link line of myexe?


> If we can agree on that, then using the current rules of CMake
> inheritance this implies that we can NEVER add a static library as a
> PUBLIC TLL for a shared library.
>

Exactly my point. I understand what you say, but if ever CMake was doing
that
you simply couldn't switch (GLOBALLY) from SHARED to STATIC
using https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
is a single SHARED lib was explicitely specified.

My opinion is that CMake may handle TLL(SHARED STATIC) differently than
TLL(SHARED SHARED) but forbidding the first would be a major headache when
you want to go from STATIC to SHARED lib one step after another (I have a
concrete
example in mind in a legacy project).

Even if I agree that this is a very bad idea
"to put a static library into the INTERFACE_LINK_LIBRARIES of a shared
library"

it currently works with CMake a may be saving a lot of time to many people
switching
gradually from a legacy build system doing just that.


> Which seems, to me, quite ridiculous because why shouldn't you want to
> allow INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, and
> INTERFACE_COMPILE_DIRECTORIES of the static library to be inherited by
> the shared library into its PUBLIC interface?  That seems like a quite
> reasonable thing to want to do.
>

I don't follow, it seems to be that case when the shared lib TLL publicly
to the static lib?
I really think think the behavior you are expecting already works if you
replace your static lib with object lib.
https://cmake.org/cmake/help/v3.14/command/target_link_libraries.html#linking-object-libraries

But may be I missed something?

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190616/db6c77c4/attachment.html>

From paul at mad-scientist.net  Sun Jun 16 19:15:45 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sun, 16 Jun 2019 19:15:45 -0400
Subject: [CMake] Why do executables link static libs that shared libs
 were built from?
In-Reply-To: <CAPASGLobZs7FC2ruR=WAEb3zmEM9u3aJPW7dM_1v9DHs4NNjtg@mail.gmail.com>
References: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>
 <CA+dygYk0JnAciM_CcqbOS8GEjfsoYs-PuQr+8R_rDfxGfJ9gfQ@mail.gmail.com>
 <9caced6d44501dae40657d8a32be2933743899ea.camel@mad-scientist.net>
 <CAPASGLobZs7FC2ruR=WAEb3zmEM9u3aJPW7dM_1v9DHs4NNjtg@mail.gmail.com>
Message-ID: <75c531eebd3741e31bac7174b52a47801e099867.camel@mad-scientist.net>

On Sun, 2019-06-16 at 21:42 +0200, Eric Noulard wrote:
> Le dim. 16 juin 2019 ? 18:26, Paul Smith <paul at mad-scientist.net> a
> ?crit :
> > But, that's not the only way to use shared libraries.  I'm trying
> > to collect a number of static libraries with different interfaces
> > into a single shared library that can be linked with executables. 
> 
> Correct me if I'm wrong but I guess that if your goal is to "collect"
> all those static libs *into* a shared lib then what you need is to
> make your STATIC libs,  OBJECT libs and then I think you'll get what
> you expect.

Yep, I'm familiar with OBJECT libs and if I could use them they would
give the correct behavior, you're right.  Unfortunately it's not the
case that OBJECT libraries are completely "drop-in" replaceable for
STATIC libraries, and they cannot be substituted in my environment.

See, for one example:
https://gitlab.kitware.com/cmake/cmake/issues/19388

I am not able to rework my system comprehensively enough to remove all
mutual references between all my current libraries.  And there are
other issues where OBJECT libraries aren't the equivalent of STATIC
libraries.

> Otherwise (at least in the way CMake currently works) any symbols
> defined in foo.a STATIC lib will *stay* in it. So in the end when you
> link an executable using bar.so SHARED lib only (which is using
> foo.a) then you won't have the symbol you need from foo unless foo.a
> is added to the link line ? Am I right?

No, that's not right.

The visibility of symbols depends on how your code is compiled and has
nothing to do with cmake and whether cmake links into a shared or
static library.

On POSIX systems (gcc and clang), all symbols are public by default
regardless of whether you are compiling them for a static or shared
library.

On Windows it's all more complicated, but in my situation I've added
the WINDOWS_EXPORT_ALL_SYMBOLS property to my libraries.

> But how can you do that without either:
>  
> 1) adding the static lib to any link line (including the one using bar)
> 2) *merging* foo.a *into* bar.so which should be what you achieve by
>     making foo an OBJECT lib.

I'm not sure what you mean by "merging foo.a into bar.so": you can't
merge something into a shared library any more than you can merge
something into an executable.  By putting "foo" into the TLL of "bar",
I've added the static library to the creation of the shared library:

  cc -shared -o bar.so bar.o libfoo.a

Now when bar.so is created it will have the required contents of
libfoo.a in it.
 
> > If we can agree on that, then using the current rules of CMake
> > inheritance this implies that we can NEVER add a static library as
> > a PUBLIC TLL for a shared library.
> 
> Exactly my point. I understand what you say, but if ever CMake was
> doing that you simply couldn't switch (GLOBALLY) from SHARED to
> STATIC using 
> https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
> is a single SHARED lib was explicitely specified.

I wasn't familiar with that option, but I don't think it makes a
difference whether the libraries are made SHARED via this option or
whether they are made SHARED via direct specification: the behavior is
the same.

> My opinion is that CMake may handle TLL(SHARED STATIC) differently
> than TLL(SHARED SHARED) but forbidding the first would be a major
> headache when you want to go from STATIC to SHARED lib one step after
> another (I have a concrete example in mind in a legacy project).

I didn't say it should be forbidden!!

I said that as cmake is currently implemented it doesn't make sense to
do it, implying that cmake might want to change its behavior in this
area to be more useful.


However, after more investigation I see that I was wrong about how
linkers resolve symbols at least in POSIX systems (I'm not sure about
DLLs on Windows... I haven't gotten there yet).

For some reason I remembered that a linker would prefer symbols found
in static libraries over those found in shared libraries, but in fact
the linker will always choose the implementation of the symbol in the
first library it's defined in regardless of the type of library.

So, as long as the shared library appears first on the link line it
shouldn't matter that the static library also appears there.

I still think it's incorrect to add the static library to the link
line, but (at least for linkers with semantics as above) it probably
doesn't actually hurt anything.


From doenges at mvtec.com  Mon Jun 17 05:16:48 2019
From: doenges at mvtec.com (=?UTF-8?Q?Eric_D=c3=b6nges?=)
Date: Mon, 17 Jun 2019 11:16:48 +0200
Subject: [CMake] Mingw64: add a statically linked library adds libstdc++
 dependency
In-Reply-To: <c7918768-f0bf-5aa6-973c-58ad42b61145@williamzeitler.com>
References: <c7918768-f0bf-5aa6-973c-58ad42b61145@williamzeitler.com>
Message-ID: <326582ce-8dbc-5069-1f05-c43266ee5cac@mvtec.com>

On 15.06.19 21:33, William Zeitler wrote:
> In the example below, two lines are marked "COMMENT ME OUT": one in
> hello_c/main.cpp and the other in hello_c/CMakeLists.txt. If you comment
> these out, the reference to the hello_lib library is removed; the
> project builds and the executable executes on Windows 10 without a
> libstdc++ dependency. If you uncomment the two lines, the function in
> the hello_lib library is linked in; the project builds, but won't
> execute on Windows 10 due to the libstdc++ dependency. (Note: in
> powershell it silently fails, in an old-school dos/cmd box it displays
> an error message.)

I think your problem is that CMAKE_CXX_FLAGS are only used when
compiling, not linking, so your hello_lib is linked without the "-static
-static-libgcc -static-libstdc++" options and thus links against the
shared libstdc++. You could try either of the following:

1) Add a "target_link_libraries(hello_lib -static-libgcc
-static-libstdc++)".

2) Add "string(APPEND CMAKE_SHARED_LINKER_FLAGS "-static-libgcc
-static-libstdc++)" to your project. Note that this will probably need
to be done before defining any of your (library) targets. Also note that
this will link any shared library in your project with the static
libstdc++, which may or may not be what you want.

Disclaimer - I haven't tried if any of this actually solves your
problem; I just think it should.

From eric.noulard at gmail.com  Mon Jun 17 05:43:27 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 17 Jun 2019 11:43:27 +0200
Subject: [CMake] Why do executables link static libs that shared libs
 were built from?
In-Reply-To: <75c531eebd3741e31bac7174b52a47801e099867.camel@mad-scientist.net>
References: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>
 <CA+dygYk0JnAciM_CcqbOS8GEjfsoYs-PuQr+8R_rDfxGfJ9gfQ@mail.gmail.com>
 <9caced6d44501dae40657d8a32be2933743899ea.camel@mad-scientist.net>
 <CAPASGLobZs7FC2ruR=WAEb3zmEM9u3aJPW7dM_1v9DHs4NNjtg@mail.gmail.com>
 <75c531eebd3741e31bac7174b52a47801e099867.camel@mad-scientist.net>
Message-ID: <CAPASGLohYvmuwD+xWVU-aidZKjzRgt=OkZj_KYZm5MM+7P2GqQ@mail.gmail.com>

Le lun. 17 juin 2019 ? 02:01, Paul Smith <paul at mad-scientist.net> a ?crit :

> On Sun, 2019-06-16 at 21:42 +0200, Eric Noulard wrote:
> > Le dim. 16 juin 2019 ? 18:26, Paul Smith <paul at mad-scientist.net> a
> > ?crit :
> > > But, that's not the only way to use shared libraries.  I'm trying
> > > to collect a number of static libraries with different interfaces
> > > into a single shared library that can be linked with executables.
> >
> > Correct me if I'm wrong but I guess that if your goal is to "collect"
> > all those static libs *into* a shared lib then what you need is to
> > make your STATIC libs,  OBJECT libs and then I think you'll get what
> > you expect.
>
> Yep, I'm familiar with OBJECT libs and if I could use them they would
> give the correct behavior, you're right.  Unfortunately it's not the
> case that OBJECT libraries are completely "drop-in" replaceable for
> STATIC libraries, and they cannot be substituted in my environment.
>
> See, for one example:
> https://gitlab.kitware.com/cmake/cmake/issues/19388
>
> I am not able to rework my system comprehensively enough to remove all
> mutual references between all my current libraries.  And there are
> other issues where OBJECT libraries aren't the equivalent of STATIC
> libraries.
>

Yes right.


> > Otherwise (at least in the way CMake currently works) any symbols
> > defined in foo.a STATIC lib will *stay* in it. So in the end when you
> > link an executable using bar.so SHARED lib only (which is using
> > foo.a) then you won't have the symbol you need from foo unless foo.a
> > is added to the link line ? Am I right?
>
> No, that's not right.
>
> The visibility of symbols depends on how your code is compiled and has
> nothing to do with cmake and whether cmake links into a shared or
> static library.
>
> On POSIX systems (gcc and clang), all symbols are public by default
> regardless of whether you are compiling them for a static or shared
> library.
>
> On Windows it's all more complicated, but in my situation I've added
> the WINDOWS_EXPORT_ALL_SYMBOLS property to my libraries.
>

Yes you are right and I know that, but AFAIK when (with CMake) you TLL a
shared lib to a static lib. You do not end up with any of the static lib
symbol in the shared lib.
At least none of them are visible with nm. (I did only test that on Linux).

> But how can you do that without either:
> >
> > 1) adding the static lib to any link line (including the one using bar)
> > 2) *merging* foo.a *into* bar.so which should be what you achieve by
> >     making foo an OBJECT lib.
>
> I'm not sure what you mean by "merging foo.a into bar.so": you can't
> merge something into a shared library any more than you can merge
> something into an executable.  By putting "foo" into the TLL of "bar",
> I've added the static library to the creation of the shared library:
>
>   cc -shared -o bar.so bar.o libfoo.a
>
> Now when bar.so is created it will have the required contents of
> libfoo.a in it.
>

You mean that the part of libfoo.a which is actually used by some part of
bar.o gets in bar.so
or any [exported] symbol found in libfoo.a gets in bar.so with the same
export rule?

My test showed me something different but I'll check again, I must have
done something wrong.


> > If we can agree on that, then using the current rules of CMake
> > > inheritance this implies that we can NEVER add a static library as
> > > a PUBLIC TLL for a shared library.
> >
> > Exactly my point. I understand what you say, but if ever CMake was
> > doing that you simply couldn't switch (GLOBALLY) from SHARED to
> > STATIC using
> > https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
> > is a single SHARED lib was explicitely specified.
>
> I wasn't familiar with that option, but I don't think it makes a
> difference whether the libraries are made SHARED via this option or
> whether they are made SHARED via direct specification: the behavior is
> the same.
>
> > My opinion is that CMake may handle TLL(SHARED STATIC) differently
> > than TLL(SHARED SHARED) but forbidding the first would be a major
> > headache when you want to go from STATIC to SHARED lib one step after
> > another (I have a concrete example in mind in a legacy project).
>
> I didn't say it should be forbidden!!
>
> I said that as cmake is currently implemented it doesn't make sense to
> do it, implying that cmake might want to change its behavior in this
> area to be more useful.
>

OK now I get your point, thank you for clarifying.


> However, after more investigation I see that I was wrong about how
> linkers resolve symbols at least in POSIX systems (I'm not sure about
> DLLs on Windows... I haven't gotten there yet).
>
> For some reason I remembered that a linker would prefer symbols found
> in static libraries over those found in shared libraries, but in fact
> the linker will always choose the implementation of the symbol in the
> first library it's defined in regardless of the type of library.
>

Yes that's right, note however that this behavior may vary between linkers
(GNU ld, gold, llvm LLD, ...) as their respective speed:
See e.g. https://lld.llvm.org/#performance
I know that LLD advertise to be a "drop-in" replacement for ld but I have
some nasty legacy project
example which show this to be wrong, but that another story.


> So, as long as the shared library appears first on the link line it
> shouldn't matter that the static library also appears there.
>
> I still think it's incorrect to add the static library to the link
> line, but (at least for linkers with semantics as above) it probably
> doesn't actually hurt anything.
>

This may be true w.r.t. the semantic, but it may (from my experience) vary
concerning the link performance,
but again this is another subject.

If there is effectively no need to have static lib on the line because a
shared lib depending on this static lib was
already linked to it, then it ought to be suppressed and not rely on some
linker policy to tidy up the whole set
of shared and static libs.

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190617/e6f8f378/attachment.html>

From jlmxyz.forums at gmail.com  Mon Jun 17 09:39:59 2019
From: jlmxyz.forums at gmail.com (jl forums)
Date: Mon, 17 Jun 2019 15:39:59 +0200
Subject: [CMake] getting compiler's include paths
Message-ID: <CALU1LNwaixGaRpdmZBLQSR46k0D5K5GmwLLMpajF4qj7cbgf_w@mail.gmail.com>

Hi,
I want to create a full tag file and for this require to know the compiler
full include path...  there is a way to had custom includes path but didn't
found any variables for the include path....
for example :
$ gcc-8 -v -x c -E /dev/null
Using built-in specs.
[....]
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/x86_64-linux-gnu/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
[...]

$ gcc -v -x c -E /dev/null
Using built-in specs.
[...]
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/x86_64-linux-gnu/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
[...]

I tried to


get_target_property(moggle_interface_includes FileSync
INTERFACE_INCLUDE_DIRECTORIES)
message("Moggle interface includes: ${moggle_interface_includes}")

get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES)
message("MOTOR includes ${motor_includes}")

but I get

Moggle interface includes: moggle_interface_includes-NOTFOUND
MOTOR includes motor_includes-NOTFOUND


there is also some issue because cmake strip dependencies from system's
include, which means that updating a system software won't cause rebuild
and consider that the build is uptodate, causing unexpected results
seems that there is ways to workaround this :
https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake
but this is ugly... would be better to let the user choose with an option

thanks and regards
JLM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190617/28270bcb/attachment.html>

From osmanzakir90 at hotmail.com  Mon Jun 17 09:47:58 2019
From: osmanzakir90 at hotmail.com (Osman Zakir)
Date: Mon, 17 Jun 2019 13:47:58 +0000
Subject: [CMake] Specifying name of library file on CMake command line?
Message-ID: <SG2PR06MB3158C3C3F145C9ADB51BE944D3EB0@SG2PR06MB3158.apcprd06.prod.outlook.com>

I want to know how to specify the name of a library I file I want to link against.  How do I do this?  I wanted to build a library with a static runtime and static libs; it requires linking against a Boost library which I did build with static runtime but when I tried to build it, I had linker errors because the dynamic version of the library was used instead of the static one.  I want to somehow make it use the static one.  So yeah, how do I do this?  Is there a way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190617/e5414649/attachment-0001.html>

From kyle.edwards at kitware.com  Mon Jun 17 09:49:39 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Mon, 17 Jun 2019 09:49:39 -0400
Subject: [CMake] Specifying name of library file on CMake command line?
In-Reply-To: <SG2PR06MB3158C3C3F145C9ADB51BE944D3EB0@SG2PR06MB3158.apcprd06.prod.outlook.com>
References: <SG2PR06MB3158C3C3F145C9ADB51BE944D3EB0@SG2PR06MB3158.apcprd06.prod.outlook.com>
Message-ID: <1560779379.3727.1.camel@kitware.com>

On Mon, 2019-06-17 at 13:47 +0000, Osman Zakir wrote:
> I want to know how to specify the name of a library I file I want to
> link against.? How do I do this?? I wanted to build a library with a
> static runtime and static libs; it requires linking against a Boost
> library which I did build with static runtime but when I tried to
> build it, I had linker errors because the dynamic version of the
> library was used instead of the static one.? I want to somehow make
> it use the static one.? So yeah, how do I do this?? Is there a way?

Are you using the FindBoost module?

https://cmake.org/cmake/help/v3.14/module/FindBoost.html?

Kyle

From paul at mad-scientist.net  Mon Jun 17 10:34:44 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Mon, 17 Jun 2019 10:34:44 -0400
Subject: [CMake] Why do executables link static libs that shared libs
 were built from?
In-Reply-To: <CAPASGLohYvmuwD+xWVU-aidZKjzRgt=OkZj_KYZm5MM+7P2GqQ@mail.gmail.com>
References: <b28b0a446d7db606b89df09f4aeb714974e48e08.camel@mad-scientist.net>
 <CA+dygYk0JnAciM_CcqbOS8GEjfsoYs-PuQr+8R_rDfxGfJ9gfQ@mail.gmail.com>
 <9caced6d44501dae40657d8a32be2933743899ea.camel@mad-scientist.net>
 <CAPASGLobZs7FC2ruR=WAEb3zmEM9u3aJPW7dM_1v9DHs4NNjtg@mail.gmail.com>
 <75c531eebd3741e31bac7174b52a47801e099867.camel@mad-scientist.net>
 <CAPASGLohYvmuwD+xWVU-aidZKjzRgt=OkZj_KYZm5MM+7P2GqQ@mail.gmail.com>
Message-ID: <6ceaa25441e9073642cc98ca29ddeb4627b82478.camel@mad-scientist.net>

On Mon, 2019-06-17 at 11:43 +0200, Eric Noulard wrote:
> Yes you are right and I know that, but AFAIK when (with CMake) you
> TLL a shared lib to a static lib. You do not end up with any of the
> static lib symbol in the shared lib.

That can't be true, unless cmake is adding fancy linker options to the
command line (it doesn't :)).  The decision of what goes into the
library is up to how the linker works and what flags it's given.

However, note I said "it will have the _required_ contents" (emphasis
added).  As you noted, the .so will only pull in symbols from the .a
which are needed to link the .so.  That may not be all the symbols in
the .a, so in your test make sure you have that reference.

Alternatively you can configure the link of the shared library to use
"whole archive" mode which pulls in the entire contents of the .a
regardless of whether they are referenced.

> > I've added the static library to the creation of the shared
> > library:
> > 
> >   cc -shared -o bar.so bar.o libfoo.a
> > 
> > Now when bar.so is created it will have the required contents of
> > libfoo.a in it.
> 
> You mean that the part of libfoo.a which is actually used by some
> part of bar.o gets in bar.so or any [exported] symbol found in
> libfoo.a gets in bar.so with the same export rule?

The former (the part that is actually used).  However again, you can
force the linker to include everything, even unused symbols.

> If there is effectively no need to have static lib on the line
> because a shared lib depending on this static lib was already linked
> to it, then it ought to be suppressed and not rely on some linker
> policy to tidy up the whole set of shared and static libs.

I did come across a real problem that I don't know how to solve, caused
by this behavior.

I'm going to start a new thread about it since this one is long and
convoluted.


From smeenai at fb.com  Mon Jun 17 20:29:26 2019
From: smeenai at fb.com (Shoaib Meenai)
Date: Tue, 18 Jun 2019 00:29:26 +0000
Subject: [CMake] Multiple exports for a target installation
In-Reply-To: <CA+dygYk+OPb8MJQbQd1QRNSKQMCVaRbowSCVZepn-2Ejna9g4Q@mail.gmail.com>
References: <C739DF5E-E0DE-41C6-B6CF-25F23FE12FDF@fb.com>
 <CA+dygYk+OPb8MJQbQd1QRNSKQMCVaRbowSCVZepn-2Ejna9g4Q@mail.gmail.com>
Message-ID: <8C4B0CF6-5C86-43C8-8C8A-E21C37EDB51A@fb.com>

Thank you!

When you say having an export set that the other exports then depend on, do you mean the COMPONENT option of the install(EXPORT) signature, or something else? (Sadly the project I?m working with is still on CMake 3.4.3, whose documentation says something very different for the COMPONENT option than the latest version, but I?ll cross that bridge when I get to it.)

From: Craig Scott <craig.scott at crascit.com>
Date: Saturday, June 15, 2019 at 10:43 PM
To: Shoaib Meenai <smeenai at fb.com>
Cc: "cmake at cmake.org" <cmake at cmake.org>
Subject: Re: [CMake] Multiple exports for a target installation



On Sat, Jun 15, 2019 at 9:03 PM Shoaib Meenai <smeenai at fb.com<mailto:smeenai at fb.com>> wrote:
Is it possible to associate a target with multiple exports? For example, if I'm building a project where I want to create multiple export sets, but there's some overlap in targets between those sets. I tried passing multiple EXPORT options to the install(TARGETS) signature but I just got an error: install TARGETS given unknown argument "EXPORT".

Typically, you'd want your export sets to not be overlapping and to contain no cyclic dependencies. If you have a target in multiple export sets, it suggests that you probably should factor out that target to a separate export set that other exports then depend on. That said, if you have a scenario that legitimately requires a target in multiple export sets, then you would need to use multiple install() commands to achieve this, specifying a different export set for each one.


--
Craig Scott
Melbourne, Australia
https://crascit.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__crascit.com&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=on4z0WGnwFnkVmDOCqIFdWlFaYpovsd4phHIcUgPrpk&s=xtBD4V4zZnM8lf5f41WOQ8MblhgMCye_s3uF7xbq_Hc&e=>

Get the hand-book for every CMake user: Professional CMake: A Practical Guide<https://urldefense.proofpoint.com/v2/url?u=https-3A__crascit.com_professional-2Dcmake_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=on4z0WGnwFnkVmDOCqIFdWlFaYpovsd4phHIcUgPrpk&s=_55JCkwuEWq36iPA22_aJhSbndgvG-h07aMzraCTUuw&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190618/2fc519a5/attachment.html>

From william at williamzeitler.com  Mon Jun 17 20:56:37 2019
From: william at williamzeitler.com (William Zeitler)
Date: Mon, 17 Jun 2019 17:56:37 -0700
Subject: [CMake] Mingw64: add a statically linked library adds libstdc++
 dependency
In-Reply-To: <326582ce-8dbc-5069-1f05-c43266ee5cac@mvtec.com>
References: <c7918768-f0bf-5aa6-973c-58ad42b61145@williamzeitler.com>
 <326582ce-8dbc-5069-1f05-c43266ee5cac@mvtec.com>
Message-ID: <4ec781e2-4c8d-1597-69a3-a6142e040fac@williamzeitler.com>

What finally worked was:

set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstd++ 
${CMAKE_CXX_STANDARD_LIBRARIES})

if(MINGW)
 ??? set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} 
-Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive")
endif()

Thanks!

On 6/17/19 02:16, Eric D?nges wrote:
> On 15.06.19 21:33, William Zeitler wrote:
>> In the example below, two lines are marked "COMMENT ME OUT": one in
>> hello_c/main.cpp and the other in hello_c/CMakeLists.txt. If you comment
>> these out, the reference to the hello_lib library is removed; the
>> project builds and the executable executes on Windows 10 without a
>> libstdc++ dependency. If you uncomment the two lines, the function in
>> the hello_lib library is linked in; the project builds, but won't
>> execute on Windows 10 due to the libstdc++ dependency. (Note: in
>> powershell it silently fails, in an old-school dos/cmd box it displays
>> an error message.)
> I think your problem is that CMAKE_CXX_FLAGS are only used when
> compiling, not linking, so your hello_lib is linked without the "-static
> -static-libgcc -static-libstdc++" options and thus links against the
> shared libstdc++. You could try either of the following:
>
> 1) Add a "target_link_libraries(hello_lib -static-libgcc
> -static-libstdc++)".
>
> 2) Add "string(APPEND CMAKE_SHARED_LINKER_FLAGS "-static-libgcc
> -static-libstdc++)" to your project. Note that this will probably need
> to be done before defining any of your (library) targets. Also note that
> this will link any shared library in your project with the static
> libstdc++, which may or may not be what you want.
>
> Disclaimer - I haven't tried if any of this actually solves your
> problem; I just think it should.

From themiwi at gmail.com  Tue Jun 18 05:45:29 2019
From: themiwi at gmail.com (Michael Wild)
Date: Tue, 18 Jun 2019 11:45:29 +0200
Subject: [CMake] Problem with AUTOMOC on WIN32
Message-ID: <CAALQ5r=XVTzLCUKQ=q9gQ5RviOzAcUbhgkuAUTg=_5McoQMWLw@mail.gmail.com>

Dear all

It's a very long time I last posted here, so please be kind :-)

I currently am having a very hard time to get AUTOMOC to work properly
on WIN32 for the case where I have some Qt classes in a DLL that I
link to an executable. In this case, the header gets included by both,
the corresponding *.cpp file in the DLL and the importing *.cpp file
in the executable. The problem is now that the AUTOMOC feature runs
moc twice on the same header, once for the DLL and once for the
executable, resulting in an inconsistent linkage because for the DLL
the moc'ed sources are dllexport but for the executable they are
dllimport.

I put together a minimal example exhibiting the problem:
https://github.com/themiwi/qt_cmake_automoc_test/

Is this a bug in CMake? IMHO moc should be only run on headers for
targets where the corresponding source file is compiled in. Or am I
just being incredibly stupid and completely miss an obvious point?

Of course I could revert to qt5_wrap_cpp() as demonstrated in the
develop branch of above example, but I'd rather not because that adds
considerable complexity and makes configuration much slower in a
real-world project.

Cheers

Michael

From david.aldrich.ntml at gmail.com  Tue Jun 18 06:53:17 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Tue, 18 Jun 2019 11:53:17 +0100
Subject: [CMake] How to specify debug version of CRT library for Visual
 Studio generator?
Message-ID: <CAJK_iegFsMQYTJVBUb=+d1CFSpRnZHUes8wGYMduTGhahqtHTA@mail.gmail.com>

I have a simple CMake project that builds an executable using Visual Studio
2017:

#==============================================

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)

################### Variables. ####################
# Change if you want modify path or other values. #
###################################################

set(PROJECT_NAME CPlaneTest)
# Output Variables
set(OUTPUT_DEBUG Debug/bin)
set(OUTPUT_RELEASE Release/bin)
# Folders files
set(CPP_DIR_1 ./)
set(CPP_DIR_2 ./)
set(CPP_DIR_3 ./)
set(CPP_DIR_4 ./)
set(HEADER_DIR_1 )

############## CMake Project ################
#        The main options of project        #
#############################################

project(${PROJECT_NAME} CXX)

# Define Release by default.
if(NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "Release")
  message(STATUS "Build type not specified: Use Release by default.")
endif(NOT CMAKE_BUILD_TYPE)

# Definition of Macros
add_definitions(
   -D_CONSOLE
   -DUNICODE
   -D_UNICODE
)

############## Artefacts Output #################
# Defines outputs , depending Debug or Release. #
#################################################

if(CMAKE_BUILD_TYPE STREQUAL "Debug")
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
  set(CMAKE_EXECUTABLE_OUTPUT_DIRECTORY
"${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
else()
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
  set(CMAKE_EXECUTABLE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
endif()

################# Flags ################
# Defines Flags for Windows and Linux. #
########################################

if(MSVC)
   #set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3 /MD
/Od /Zi /EHsc")
   set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od /Oi
/Gy /Zi /EHsc")
   set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3 /GL
/Od /Oi /Gy /Zi /EHsc")
endif(MSVC)
if(NOT MSVC)
   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
   if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
       set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
   endif()
endif(NOT MSVC)

################ Files ################
#   --   Add files to project.   --   #
#######################################

file(GLOB SRC_FILES
    ${CPP_DIR_1}/*.cpp
    ${CPP_DIR_2}/*.cpp
    ${CPP_DIR_3}/*.cpp
    ${CPP_DIR_4}/*.cpp
    ${HEADER_DIR_1}/*.h
)

# Add executable to build.
add_executable(${PROJECT_NAME}
   ${SRC_FILES}
)

if(MSVC)
   target_link_libraries(${PROJECT_NAME} ws2_32.lib )
endif(MSVC)

#=====================================

The Release build succeeds but the Debug build fails with linker errors
such as:

[build] CPlaneTest.obj : error LNK2001: unresolved external symbol
__imp___CrtDbgReport

I think this is because the linker is not using the debug version of CRT (C
Run-time Library).

Should CMake select the debug build of CRT automatically or do I need to
specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190618/dd88a7f9/attachment-0001.html>

From craig.scott at crascit.com  Tue Jun 18 08:45:27 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 18 Jun 2019 22:45:27 +1000
Subject: [CMake] CMake now available to Linux users as a snap
Message-ID: <CA+dygY=hg72qht+fLQkiK6H3pW7JCOPJ9v4MQd+dfbBzsS8ifQ@mail.gmail.com>

Hi all. For those of you working on Linux, I'm pleased to announce that
CMake is now available as a snap. This can be a great way to conveniently
keep up with the latest CMake releases, even on Linux distributions that
are no longer updating their own CMake packages. You can find a brief blog
post about it here:

https://crascit.com/2019/06/18/cmake-now-available-as-a-snap/

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190618/d8651f26/attachment.html>

From doenges at mvtec.com  Tue Jun 18 10:06:50 2019
From: doenges at mvtec.com (=?UTF-8?Q?Eric_D=c3=b6nges?=)
Date: Tue, 18 Jun 2019 16:06:50 +0200
Subject: [CMake] How to specify debug version of CRT library for Visual
 Studio generator?
In-Reply-To: <CAJK_iegFsMQYTJVBUb=+d1CFSpRnZHUes8wGYMduTGhahqtHTA@mail.gmail.com>
References: <CAJK_iegFsMQYTJVBUb=+d1CFSpRnZHUes8wGYMduTGhahqtHTA@mail.gmail.com>
Message-ID: <03f04e8f-0427-4136-661c-5bc4ffd2aac4@mvtec.com>

On 18.06.19 12:53, David Aldrich wrote:
> I have a simple CMake project that builds an executable using Visual
> Studio 2017:


> 
> ################ Files ################
> # ? -- ? Add files to project. ? -- ? #
> #######################################
> 
> file(GLOB SRC_FILES
> ? ? ${CPP_DIR_1}/*.cpp
> ? ? ${CPP_DIR_2}/*.cpp
> ? ? ${CPP_DIR_3}/*.cpp
> ? ? ${CPP_DIR_4}/*.cpp
> ? ? ${HEADER_DIR_1}/*.h
> )
> 
> # Add executable to build.
> add_executable(${PROJECT_NAME}
> ? ?${SRC_FILES}
> )
> 
> if(MSVC)
> ? ?target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> endif(MSVC)
> 
> #=====================================
> 
> The Release build succeeds but the Debug build fails with linker errors
> such as:
> 
> [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> __imp___CrtDbgReport
> 
> I think this is because the linker is not using the debug version of CRT
> (C Run-time Library). ?
> 
> Should CMake select the debug build of CRT automatically or do I need to
> specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
> 

CMake will select the correct CRT automatically if you let it (unless
you want the static CRT, in which case you have to override CMake's
default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG incorrectly:

> if(MSVC)
>    #set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> /MD /Od /Zi /EHsc")
>    set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> /Oi /Gy /Zi /EHsc")
>    set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> /GL /Od /Oi /Gy /Zi /EHsc")
> endif(MSVC)

In case of the setting you've commented out, you are explicitly telling
CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
since you append the /MD, that is what the compiler will actually use.

For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
you want (and also specifies /MD).

I would suggest looking at what flags CMake sets by default (look at the
Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
only setting those flags that CMake doesn't already. For version 3.14,
CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
default (assuming you are using MVSC >= 1310, no Clang toolset):

	/MDd /Zi /Ob0 /Od /GR /EHSC

So in your case, it would probably be enough to

	string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")

As a final recommendation, use string(APPEND <var> ...) (or list(APPEND
<list> ...), if the variable is interpreted as a list) when appending
values to existing variables. This makes your intent clearer.


 - when appending compiler flags, use the "string(APPEND ...)" command
to make is clearer what you are doing).

From robert.maynard at kitware.com  Tue Jun 18 14:08:10 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 18 Jun 2019 14:08:10 -0400
Subject: [CMake] How to specify debug version of CRT library for Visual
 Studio generator?
In-Reply-To: <03f04e8f-0427-4136-661c-5bc4ffd2aac4@mvtec.com>
References: <CAJK_iegFsMQYTJVBUb=+d1CFSpRnZHUes8wGYMduTGhahqtHTA@mail.gmail.com>
 <03f04e8f-0427-4136-661c-5bc4ffd2aac4@mvtec.com>
Message-ID: <CAFzjYVqnBGDio_kBO9mej+Y11UjOtp9ZakBErDJ1A0=pOu8CCA@mail.gmail.com>

Just a heads up, CMake 3.15 is introducing policy 91 which removes the
runtime library from the default set of flags, and instead has targets
establish what runtime they want.

For more information see:
https://cmake.org/cmake/help/v3.15/prop_tgt/MSVC_RUNTIME_LIBRARY.html

On Tue, Jun 18, 2019 at 10:06 AM Eric D?nges <doenges at mvtec.com> wrote:
>
> On 18.06.19 12:53, David Aldrich wrote:
> > I have a simple CMake project that builds an executable using Visual
> > Studio 2017:
>
>
> >
> > ################ Files ################
> > #   --   Add files to project.   --   #
> > #######################################
> >
> > file(GLOB SRC_FILES
> >     ${CPP_DIR_1}/*.cpp
> >     ${CPP_DIR_2}/*.cpp
> >     ${CPP_DIR_3}/*.cpp
> >     ${CPP_DIR_4}/*.cpp
> >     ${HEADER_DIR_1}/*.h
> > )
> >
> > # Add executable to build.
> > add_executable(${PROJECT_NAME}
> >    ${SRC_FILES}
> > )
> >
> > if(MSVC)
> >    target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> > endif(MSVC)
> >
> > #=====================================
> >
> > The Release build succeeds but the Debug build fails with linker errors
> > such as:
> >
> > [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> > __imp___CrtDbgReport
> >
> > I think this is because the linker is not using the debug version of CRT
> > (C Run-time Library).
> >
> > Should CMake select the debug build of CRT automatically or do I need to
> > specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
> >
>
> CMake will select the correct CRT automatically if you let it (unless
> you want the static CRT, in which case you have to override CMake's
> default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG incorrectly:
>
> > if(MSVC)
> >    #set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> > /MD /Od /Zi /EHsc")
> >    set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> > /Oi /Gy /Zi /EHsc")
> >    set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> > /GL /Od /Oi /Gy /Zi /EHsc")
> > endif(MSVC)
>
> In case of the setting you've commented out, you are explicitly telling
> CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
> since you append the /MD, that is what the compiler will actually use.
>
> For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
> to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
> you want (and also specifies /MD).
>
> I would suggest looking at what flags CMake sets by default (look at the
> Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
> only setting those flags that CMake doesn't already. For version 3.14,
> CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
> default (assuming you are using MVSC >= 1310, no Clang toolset):
>
>         /MDd /Zi /Ob0 /Od /GR /EHSC
>
> So in your case, it would probably be enough to
>
>         string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")
>
> As a final recommendation, use string(APPEND <var> ...) (or list(APPEND
> <list> ...), if the variable is interpreted as a list) when appending
> values to existing variables. This makes your intent clearer.
>
>
>  - when appending compiler flags, use the "string(APPEND ...)" command
> to make is clearer what you are doing).
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From alaitsev at gmail.com  Wed Jun 19 01:29:55 2019
From: alaitsev at gmail.com (Innokentiy Alaytsev)
Date: Tue, 18 Jun 2019 22:29:55 -0700 (MST)
Subject: [CMake] Problem with AUTOMOC on WIN32
In-Reply-To: <CAALQ5r=XVTzLCUKQ=q9gQ5RviOzAcUbhgkuAUTg=_5McoQMWLw@mail.gmail.com>
References: <CAALQ5r=XVTzLCUKQ=q9gQ5RviOzAcUbhgkuAUTg=_5McoQMWLw@mail.gmail.com>
Message-ID: <1560922195853-0.post@n2.nabble.com>

Hello!

Are the header files of the shared library (DLL) listed as INTERFACE_SOURCES
for the library target? AFAIK, the only reason for header files to be
processed by AUTOMOC is to be part of the project. The only way that I know
of for adding library headers to the consuming project is by declaring them
as INTERFACE sources of the library target.

Best regards,
Innokentiy Alaytsev



--
Sent from: http://cmake.3232098.n2.nabble.com/

From david.aldrich.ntml at gmail.com  Wed Jun 19 05:29:12 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Wed, 19 Jun 2019 10:29:12 +0100
Subject: [CMake] How to specify debug version of CRT library for Visual
 Studio generator?
In-Reply-To: <03f04e8f-0427-4136-661c-5bc4ffd2aac4@mvtec.com>
References: <CAJK_iegFsMQYTJVBUb=+d1CFSpRnZHUes8wGYMduTGhahqtHTA@mail.gmail.com>
 <03f04e8f-0427-4136-661c-5bc4ffd2aac4@mvtec.com>
Message-ID: <CAJK_iei05zFF2jQbrHTU_jSBr72SdRJon2aQze39qBe93eu63w@mail.gmail.com>

>
> > On Tue, Jun 18, 2019 at 3:07 PM Eric D?nges <doenges at mvtec.com> wrote:
> > On 18.06.19 12:53, David Aldrich wrote:
> > > I have a simple CMake project that builds an executable using Visual
> > > Studio 2017:
> >
> >
> > >
> > > ################ Files ################
> > > #   --   Add files to project.   --   #
> > > #######################################
> > >
> > > file(GLOB SRC_FILES
> > >     ${CPP_DIR_1}/*.cpp
> > >     ${CPP_DIR_2}/*.cpp
> > >     ${CPP_DIR_3}/*.cpp
> > >     ${CPP_DIR_4}/*.cpp
> > >     ${HEADER_DIR_1}/*.h
> > > )
> > >
> > > # Add executable to build.
> > > add_executable(${PROJECT_NAME}
> > >    ${SRC_FILES}
> > > )
> > >
> > > if(MSVC)
> > >    target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> > > endif(MSVC)
> > >
> > > #=====================================
> > >
> > > The Release build succeeds but the Debug build fails with linker errors
> > > such as:
> > >
> > > [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> > > __imp___CrtDbgReport
> > >
> > > I think this is because the linker is not using the debug version of
> CRT
> > > (C Run-time Library).
> > >
> > > Should CMake select the debug build of CRT automatically or do I need
> to
> > > specify it manually? If so, should I do so using
> CMAKE_EXE_LINKER_FLAGS?
> > >
> >
> > CMake will select the correct CRT automatically if you let it (unless
> > you want the static CRT, in which case you have to override CMake's
> > default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG
> incorrectly:
> >
> > > if(MSVC)
> > >    #set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> > > /MD /Od /Zi /EHsc")
> > >    set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> > > /Oi /Gy /Zi /EHsc")
> > >    set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> > > /GL /Od /Oi /Gy /Zi /EHsc")
> > > endif(MSVC)
> >
> > In case of the setting you've commented out, you are explicitly telling
> > CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
> > since you append the /MD, that is what the compiler will actually use.
> >
> > For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
> > to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
> > you want (and also specifies /MD).
> >
> > I would suggest looking at what flags CMake sets by default (look at the
> > Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
> > only setting those flags that CMake doesn't already. For version 3.14,
> > CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
> > default (assuming you are using MVSC >= 1310, no Clang toolset):
> >
> >         /MDd /Zi /Ob0 /Od /GR /EHSC
> >
> > So in your case, it would probably be enough to
> >
> >         string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")
> >
> > As a final recommendation, use string(APPEND <var> ...) (or list(APPEND
> > <list> ...), if the variable is interpreted as a list) when appending
> > values to existing variables. This makes your intent clearer.
> >
> >
> >  - when appending compiler flags, use the "string(APPEND ...)" command
> > to make is clearer what you are doing).
>
> Thanks for your help and advice. I've followed your suggestions and the
> debug
> and release builds are now working correctly. I produced my CMakeLists.txt
> from
> a Visual Studio solution using a conversion utility. I will need to rework
> it to adopt best practices.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190619/0b8cc69d/attachment.html>

From david.aldrich.ntml at gmail.com  Wed Jun 19 05:30:06 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Wed, 19 Jun 2019 10:30:06 +0100
Subject: [CMake] How to specify debug version of CRT library for Visual
 Studio generator?
In-Reply-To: <CAFzjYVqnBGDio_kBO9mej+Y11UjOtp9ZakBErDJ1A0=pOu8CCA@mail.gmail.com>
References: <CAJK_iegFsMQYTJVBUb=+d1CFSpRnZHUes8wGYMduTGhahqtHTA@mail.gmail.com>
 <03f04e8f-0427-4136-661c-5bc4ffd2aac4@mvtec.com>
 <CAFzjYVqnBGDio_kBO9mej+Y11UjOtp9ZakBErDJ1A0=pOu8CCA@mail.gmail.com>
Message-ID: <CAJK_iejgf1fjxXdbbVcc=bggphaiXULX08bvR91yZy8VyQze_Q@mail.gmail.com>

> Just a heads up, CMake 3.15 is introducing policy 91 which removes the
> runtime library from the default set of flags, and instead has targets
> establish what runtime they want.

Thanks for this.

On Tue, Jun 18, 2019 at 7:08 PM Robert Maynard <robert.maynard at kitware.com>
wrote:

> Just a heads up, CMake 3.15 is introducing policy 91 which removes the
> runtime library from the default set of flags, and instead has targets
> establish what runtime they want.
>
> For more information see:
> https://cmake.org/cmake/help/v3.15/prop_tgt/MSVC_RUNTIME_LIBRARY.html
>
> On Tue, Jun 18, 2019 at 10:06 AM Eric D?nges <doenges at mvtec.com> wrote:
> >
> > On 18.06.19 12:53, David Aldrich wrote:
> > > I have a simple CMake project that builds an executable using Visual
> > > Studio 2017:
> >
> >
> > >
> > > ################ Files ################
> > > #   --   Add files to project.   --   #
> > > #######################################
> > >
> > > file(GLOB SRC_FILES
> > >     ${CPP_DIR_1}/*.cpp
> > >     ${CPP_DIR_2}/*.cpp
> > >     ${CPP_DIR_3}/*.cpp
> > >     ${CPP_DIR_4}/*.cpp
> > >     ${HEADER_DIR_1}/*.h
> > > )
> > >
> > > # Add executable to build.
> > > add_executable(${PROJECT_NAME}
> > >    ${SRC_FILES}
> > > )
> > >
> > > if(MSVC)
> > >    target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> > > endif(MSVC)
> > >
> > > #=====================================
> > >
> > > The Release build succeeds but the Debug build fails with linker errors
> > > such as:
> > >
> > > [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> > > __imp___CrtDbgReport
> > >
> > > I think this is because the linker is not using the debug version of
> CRT
> > > (C Run-time Library).
> > >
> > > Should CMake select the debug build of CRT automatically or do I need
> to
> > > specify it manually? If so, should I do so using
> CMAKE_EXE_LINKER_FLAGS?
> > >
> >
> > CMake will select the correct CRT automatically if you let it (unless
> > you want the static CRT, in which case you have to override CMake's
> > default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG
> incorrectly:
> >
> > > if(MSVC)
> > >    #set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> > > /MD /Od /Zi /EHsc")
> > >    set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> > > /Oi /Gy /Zi /EHsc")
> > >    set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> > > /GL /Od /Oi /Gy /Zi /EHsc")
> > > endif(MSVC)
> >
> > In case of the setting you've commented out, you are explicitly telling
> > CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
> > since you append the /MD, that is what the compiler will actually use.
> >
> > For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
> > to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
> > you want (and also specifies /MD).
> >
> > I would suggest looking at what flags CMake sets by default (look at the
> > Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
> > only setting those flags that CMake doesn't already. For version 3.14,
> > CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
> > default (assuming you are using MVSC >= 1310, no Clang toolset):
> >
> >         /MDd /Zi /Ob0 /Od /GR /EHSC
> >
> > So in your case, it would probably be enough to
> >
> >         string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")
> >
> > As a final recommendation, use string(APPEND <var> ...) (or list(APPEND
> > <list> ...), if the variable is interpreted as a list) when appending
> > values to existing variables. This makes your intent clearer.
> >
> >
> >  - when appending compiler flags, use the "string(APPEND ...)" command
> > to make is clearer what you are doing).
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190619/f00e8a93/attachment-0001.html>

From meghna.vasudeva at gmail.com  Wed Jun 19 06:42:29 2019
From: meghna.vasudeva at gmail.com (dexter810)
Date: Wed, 19 Jun 2019 03:42:29 -0700 (MST)
Subject: [CMake] Write CMakeLists.txt for this C++ program
Message-ID: <1560940949778-0.post@n2.nabble.com>

This is the program I want to run, main.cpp:

#include <iostream>
#include "yaracpp/yaracpp.h"

int main() {
    yaracpp::YaraDetector yara;
    yara.addRules(R"(

        rule example {
            strings:
                $s = "Hello"
            condition:
                $s
        })");


    if (yara.analyze("test_file")) {
        for (const auto& rule : yara.getDetectedRules()) {
            std::cout << rule << '\n';
        }
    }
}


When I run this command on the terminal it compiles successfully: 

g++ -Iinclude -Ibuild/deps/yara/src/yara/libyara/include/ -Lbuild/src/
-Lbuild/deps/yara/src/yara/libyara/.libs/ main.cpp -lyaracpp -lyara
-lpthread -lssl -lcrypto

*Approach 1:*
My CMakeLists.txt is:

cmake_minimum_required(VERSION 3.6)
project(main CXX C)

add_executable(main main.cpp)

set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Iinclude
-Ibuild/deps/yara/src/yara/libyara/include -Lbuild/src
-Lbuild/deps/yara/src/yara/libyara/.libs/")


target_link_libraries (main yaracpp yara pthread ssl crypto)


But this was not able to link it properly and threw errors that it cannot
find "yaracpp/yaracpp.h". The references for writing CMakeLists.txt like
this were: 

https://stackoverflow.com/questions/43136418/how-to-add-l-ell-compiler-flag-in-cmake

https://stackoverflow.com/questions/53879422/how-to-set-g-compile-options-in-clion?answertab=oldest#tab-top




--
Sent from: http://cmake.3232098.n2.nabble.com/

From doenges at mvtec.com  Wed Jun 19 07:58:47 2019
From: doenges at mvtec.com (=?UTF-8?Q?Eric_D=c3=b6nges?=)
Date: Wed, 19 Jun 2019 13:58:47 +0200
Subject: [CMake] Write CMakeLists.txt for this C++ program
In-Reply-To: <1560940949778-0.post@n2.nabble.com>
References: <1560940949778-0.post@n2.nabble.com>
Message-ID: <52863f25-e2e8-d596-7bb6-0d8662115f2c@mvtec.com>

On 19.06.19 12:42, dexter810 wrote:
> cmake_minimum_required(VERSION 3.6)
> project(main CXX C)
> 
> add_executable(main main.cpp)
> 
> set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Iinclude
> -Ibuild/deps/yara/src/yara/libyara/include -Lbuild/src
> -Lbuild/deps/yara/src/yara/libyara/.libs/")
> 
> 
> target_link_libraries (main yaracpp yara pthread ssl crypto)
> 
> 
> But this was not able to link it properly and threw errors that it cannot
> find "yaracpp/yaracpp.h". The references for writing CMakeLists.txt like
> this were: 
> 
> https://stackoverflow.com/questions/43136418/how-to-add-l-ell-compiler-flag-in-cmake
> 
> https://stackoverflow.com/questions/53879422/how-to-set-g-compile-options-in-clion?answertab=oldest#tab-top

Since you don't include the error messages from the compiler, we are
reduced to guessing here:

1) Don't add -I flags to compiler command line by modifying the
CMAKE_CXX_FLAGS directly. Instead, use either the include_directories
command (if you want to specify the include directories for multiple
targets), or the target_include_directories command:

	target_include_directories(main PRIVATE
		include build/deps/yara/src/yara/libyara/include)

2) CMAKE_CXX_FLAGS is used for compiling, not linking. One way to get
the linker command line you want is to change

	target_link_libraries (main yaracpp yara pthread ssl crypto)

to

	target_link_libraries (main
		-Lbuild/src build/deps/yara/src/yara/libyara/.libs
		-lyaracpp -lyara pthread ssl crypto)

However, better practice would be to create import targets for the
libraries you want to use. For example (assuming that yaracpp is a
shared library):

	add_library(yaracpp SHARED IMPORTED)
	set_target_properties(yaracpp PROPERTIES
		IMPORTED_LOCATION "build/deps/yara/src/yara/libyara/.libs/libyara.so"
		INTERFACE_INCLUDE_DIRECTORIES "build/deps/yara/src/yara/libyara/include")

Then, you simply add yaracpp to your target_link_libraries command and
can skip the target_include_directories command. Even better practice
would be to use the find_library command to find the libyara library -
this way, your CMakelists.txt would also work for non-Unix target
systems like Windows.

For more information, I highly recommend reading the CMake
documentation, particularly
https://cmake.org/cmake/help/v3.15/manual/cmake-buildsystem.7.html

From meghna.vasudeva at gmail.com  Wed Jun 19 09:36:30 2019
From: meghna.vasudeva at gmail.com (dexter810)
Date: Wed, 19 Jun 2019 06:36:30 -0700 (MST)
Subject: [CMake] Write CMakeLists.txt for this C++ program
In-Reply-To: <52863f25-e2e8-d596-7bb6-0d8662115f2c@mvtec.com>
References: <1560940949778-0.post@n2.nabble.com>
 <52863f25-e2e8-d596-7bb6-0d8662115f2c@mvtec.com>
Message-ID: <1560951390237-0.post@n2.nabble.com>

*Approach 1:*
CMakeLists.txt:

cmake_minimum_required(VERSION 3.6)
project(main CXX C)

add_executable(main main.cpp)

target_include_directories(main PRIVATE
                include build/deps/yara/src/yara/libyara/include) 


 target_link_libraries (main
                -Lbuild/src/ -Lbuild/deps/yara/src/yara/libyara/.libs
                yaracpp yara pthread ssl crypto) 


I got:
*cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX="$(pwd)/install" ..*
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mevasu/yaracpp/build2

*
cmake --build . -- -j $NPROC*
Scanning dependencies of target main
[ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
[100%] Linking CXX executable main
/usr/bin/ld: cannot find -lyaracpp
/usr/bin/ld: cannot find -lyara
collect2: error: ld returned 1 exit status
CMakeFiles/main.dir/build.make:94: recipe for target 'main' failed
make[2]: *** [main] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/main.dir/all' failed
make[1]: *** [CMakeFiles/main.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2


*
Approach 2:*

CMakeLists.txt: 
cmake_minimum_required(VERSION 3.6)
project(main CXX C)

add_executable(main main.cpp)



add_library(yara STATIC IMPORTED)
set_target_properties(yara PROPERTIES
                IMPORTED_LOCATION
"build/deps/yara/src/yara/libyara/.libs/libyara.a"
                INTERFACE_INCLUDE_DIRECTORIES
"build/deps/yara/src/yara/libyara/include")

add_library(yaracpp STATIC IMPORTED)
set_target_properties(yaracpp PROPERTIES
                IMPORTED_LOCATION "build/src/libyaracpp.a"
                INTERFACE_INCLUDE_DIRECTORIES "include")

I got: 

*cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX="$(pwd)/install" ..*
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mevasu/Desktop/yaracpp/build2

*
 cmake --build . -- -j $NPROC*
Scanning dependencies of target main
[ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
/home/mevasu/Desktop/yaracpp/main.cpp:2:10: fatal error: yaracpp/yaracpp.h:
No such file or directory
 #include "yaracpp/yaracpp.h"
          ^~~~~~~~~~~~~~~~~~~
compilation terminated.
CMakeFiles/main.dir/build.make:62: recipe for target
'CMakeFiles/main.dir/main.cpp.o' failed
make[2]: *** [CMakeFiles/main.dir/main.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/main.dir/all' failed
make[1]: *** [CMakeFiles/main.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2


The libraries that I'm trying to link are actually static libraries and from
the link that you gave in the above answer, I encountered:
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
where I tried giving this approach:
*
Approach 3*
CMakeLists.txt:
cmake_minimum_required(VERSION 3.6)
project(main CXX C)

add_executable(main main.cpp)

target_include_directories(main PRIVATE
                include build/deps/yara/src/yara/libyara/include) 


 target_link_libraries (main
                -Lbuild/src/libyaracpp.a
-Lbuild/deps/yara/src/yara/libyara/.libs/libyara.a
                yaracpp yara pthread ssl crypto) 



I got:
*
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX="$(pwd)/install" ..*
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mevasu/yaracpp/build2

*cmake --build . -- -j $NPROC*
Scanning dependencies of target main
[ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
[100%] Linking CXX executable main
/usr/bin/ld: cannot find -lyaracpp
/usr/bin/ld: cannot find -lyara
collect2: error: ld returned 1 exit status
CMakeFiles/main.dir/build.make:94: recipe for target 'main' failed
make[2]: *** [main] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/main.dir/all' failed
make[1]: *** [CMakeFiles/main.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2


Also, inside target_link_libraries() irrespective of putting -lyaracpp and
-lyara or yaracpp and yara, I got the same errors.



--
Sent from: http://cmake.3232098.n2.nabble.com/

From robert.maynard at kitware.com  Wed Jun 19 11:57:00 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 19 Jun 2019 11:57:00 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.15.0-rc2 is ready for testing
Message-ID: <CAFzjYVoxLkMU-XsGqJxZoUz0bXPXLx=L8zaTQXdNRS39u8yHDg@mail.gmail.com>

I am proud to announce the second CMake 3.15 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.15

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.15/release/3.15.html

Some of the more significant changes in CMake 3.15 are:

* The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and
  "MSVC_RUNTIME_LIBRARY" target property were introduced to select the
  runtime library used by compilers targeting the MSVC ABI. See policy
  "CMP0091".

* With MSVC-like compilers the value of "CMAKE_<LANG>_FLAGS" no
  longer contains warning flags like "/W3" by default. See policy
  "CMP0092".

* The "Clang" compiler variant on Windows that targets the MSVC ABI
  but has a GNU-like command line is now supported.

* Preliminary support for the "Swift" language was added to the
  "Ninja" generator.

* The "$<COMPILE_LANG_AND_ID:...>" generator expression was
  introduced to allow specification of compile options for target
  files based on the "CMAKE_<LANG>_COMPILER_ID" and "LANGUAGE" of each
  source file.

* The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID",
  "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE",
  "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching
  one value from a comma-separated list.

* The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell
  "find_package()" calls to look for a package configuration file
  first even if a find module is available.

* The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set
  on Interface Libraries. The headers specified by those properties
  can be installed using the "install(TARGETS)" command by passing the
  "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively.

* The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and
  "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the
  Just My Code feature of the Visual Studio Debugger when compiling
  with MSVC cl 19.05 and higher.

* The "FindBoost" module was reworked to expose a more consistent
  user experience between its ?Config? and ?Module? modes and with
  other find modules in general.

* The "message()" command learned new types: "NOTICE", "VERBOSE",
  "DEBUG" and "TRACE".

* The "export(PACKAGE)" command now does nothing unless enabled via
  "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".


* The "CMAKE_GENERATOR" environment variable was added to specify a
  default generator to use when "cmake(1)" is run without a "-G"
  option.  Additionally, environment variables
  "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and
  "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.

* The "cmake(1)" command gained a new "--install" option. This may
  be used after building a project to run installation without using
  the generated build system or the native build tool.

* The "cmake(1)" command learned a new CLI option "--loglevel".

* The "cmake-server(7)" mode has been deprecated and will be removed
  from a future version of CMake.  Please port clients to use the
  "cmake-file-api(7)" instead.


CMake 3.15 Release Notes
************************

Changes made since CMake 3.14 include the following.


New Features
============


Generators
----------

* The "Xcode" generator now supports per-target schemes. See the
  "CMAKE_XCODE_GENERATE_SCHEME" variable and "XCODE_GENERATE_SCHEME"
  target property.

* The "Green Hills MULTI" generator has been updated:

  * It now supports the "add_custom_command()" and
    "add_custom_target()" commands.

  * It is now available on Linux.


Languages
---------

* Preliminary support for the "Swift" language was added to the
  "Ninja" generator:

  * Use the "SWIFTC" environment variable to specify a compiler.

  * The "Swift_DEPENDENCIES_FILE" target property and
    "Swift_DEPENDENCIES_FILE" source file property were added to
    customize dependency files.

  * The "Swift_MODULE_NAME" target property was added to customize
    the Swift module name.

  * The "Swift_DIAGNOSTICS_FILE" source property was added to
    indicate where to write the serialised Swift diagnostics.

  The Swift support is experimental, not considered stable, and may
  change in future releases of CMake.


Compilers
---------

* The "Clang" compiler variant on Windows that targets the MSVC ABI
  but has a GNU-like command line is now supported.

* Support for the Clang-based ARM compiler was added with compiler
  id "ARMClang".

* Support was added for the IAR compiler architectures Renesas RX,
  RL78, RH850 and Texas Instruments MSP430.

* Support was added for the IAR compilers built for Linux (IAR
  BuildLx).


Command-Line
------------

* The "CMAKE_GENERATOR" environment variable was added to specify a
  default generator to use when "cmake(1)" is run without a "-G"
  option.  Additionally, environment variables
  "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and
  "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.

* The "cmake(1)" "--build" tool "--target" parameter gained support
  for multiple targets, e.g. "cmake --build . --target Library1
  Library2". It now also has a short form "-t" alias, e.g. "cmake
  --build . -t Library1 Library2".

* The "cmake(1)" command gained a new "--install" option. This may
  be used after building a project to run installation without using
  the generated build system or the native build tool.

* The "cmake(1)" command learned a new CLI option "--loglevel".

* The "cmake(1)" "-E remove_directory" command-line tool learned to
  support removing multiple directories.

* The "cmake(1)" "-E tar" tool has been improved:

  * It now continues adding files to an archive even if some of the
    files are not readable.  This behavior is more consistent with the
    classic "tar" tool.

  * It now parses all flags, and if an invalid flag was provided, a
    warning is issued.

  * It now displays an error if no action flag was specified, along
    with a list of possible actions: "t" (list), "c" (create) or "x"
    (extract).

  * It now supports extracting ("-x") or listing ("-t") only
    specific files or directories.

  * It now supports Zstandard compression with a "--zstd" option.
    Zstandard was designed to give a compression ratio comparable to
    that of the DEFLATE (zip) algorithm, but faster, especially for
    decompression.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  gained a new "JOB_POOL" option that works with the "Ninja" generator
  to set the pool variable on the build statement.

* The "add_library()" command "ALIAS" option learned to support
  import libraries of the "UNKNOWN" type.

* The "cmake_parse_arguments()" command gained an additional
  "<prefix>_KEYWORDS_MISSING_VALUES" output variable to report keyword
  arguments that were given by the caller with no values.

* The "execute_process()" command gained a "COMMAND_ECHO" option and
  supporting "CMAKE_EXECUTE_PROCESS_COMMAND_ECHO" variable to enable
  echoing of the command-line string before execution.

* The "file(INSTALL)" command learned a new argument,
  "FOLLOW_SYMLINK_CHAIN", which can be used to recursively resolve and
  install symlinks.

* "list()" learned new sub-commands: "PREPEND", "POP_FRONT" and
  "POP_BACK".

* The "message()" command learned new types: "NOTICE", "VERBOSE",
  "DEBUG" and "TRACE".

* The "string()" learned a new sub-command "REPEAT".


Variables
---------

* The "CMAKE_CROSSCOMPILING_EMULATOR" variable and corresponding
  "CROSSCOMPILING_EMULATOR" target property learned to support
  arguments to the emulator.

* The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell
  "find_package()" calls to look for a package configuration file
  first even if a find module is available.

* The "CMAKE_FRAMEWORK" variable was added to initialize the
  "FRAMEWORK" property on all targets.

* The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and
  "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the
  Just My Code feature of the Visual Studio Debugger when compiling
  with MSVC cl 19.05 and higher.

* The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and
  "MSVC_RUNTIME_LIBRARY" target property were introduced to select the
  runtime library used by compilers targeting the MSVC ABI. See policy
  "CMP0091".

* The "CMAKE_PROJECT_INCLUDE" and "CMAKE_PROJECT_INCLUDE_BEFORE"
  variables were added to allow injection of custom code at the sites
  of "project()" calls without knowing the project name a priori.


Properties
----------

* The "ADDITIONAL_CLEAN_FILES" target property and
  "ADDITIONAL_CLEAN_FILES" directory property were added. They allow
  to register additional files that should be removed during the clean
  stage.

* The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set
  on Interface Libraries. The headers specified by those properties
  can be installed using the "install(TARGETS)" command by passing the
  "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively.

* The "VS_PACKAGE_REFERENCES" target property was added to tell
  Visual Studio Generators to add references to "nuget" packages.

* The "VS_PROJECT_IMPORT" target property was added to allow managed
  Visual Studio project files to import external ".props" files.

* The "VS_NO_SOLUTION_DEPLOY" target property was added to tell
  Visual Studio Generators whether to deploy an artifact to the WinCE
  or Windows Phone target device.


Modules
-------

* The "FindBoost" module was reworked to expose a more consistent
  user experience between its ?Config? and ?Module? modes and with
  other find modules in general.

  * A new imported target "Boost::headers" is now defined (same as
    "Boost::boost").

  * New output variables "Boost_VERSION_MACRO",
    "Boost_VERSION_MAJOR", "Boost_VERSION_MINOR",
    "Boost_VERSION_PATCH", and "Boost_VERSION_COUNT" were added.

  * The "QUIET" argument passed to "find_package()" is no longer
    ignored in config mode.  Note that the CMake package shipped with
    Boost "1.70.0" ignores the "QUIET" argument passed to
    "find_package()".  This is fixed in the next Boost release.

  * The input switch "Boost_DETAILED_FAILURE_MSG" was removed.

  * "Boost_VERSION" now reports the version in "x.y.z" format in
    module mode.  See policy "CMP0093".

* The "FindCups" module now provides imported targets.

* The "FindEnvModules" module was added to use Lua- and TCL-based
  environment modules in CTest Scripts.

* The "FindGLEW" module now provides an interface more consistent
  with what upstream GLEW provides in its own CMake package files.

* The "FindPkgConfig" now populates "INTERFACE_LINK_OPTIONS"
  property of imported targets with other (non-library) linker flags.

* The "FindPostgreSQL" module learned to find debug and release
  variants separately.

* Modules "FindPython3", "FindPython2" and "FindPython" gained
  additional lookup strategies and controls, and a new default. See
  policy "CMP0094".

* Modules "FindPython", "FindPython2" and "FindPython3" gain a new
  target (respectively "Python::Module", "Python2::Module" and
  "Python3::Module") which can be used to develop Python modules.

* Modules "FindPython3", "FindPython2" and "FindPython" gain
  capability to control how virtual environments are handled.

* The "UseSWIG" module learned to manage alternate library names by
  passing "-interface <library_name>" for "python" language or
  "-dllimport <library_name>" for "CSharp" language to the "SWIG"
  compiler.


Generator Expressions
---------------------

* The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID",
  "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE",
  "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching
  one value from a comma-separated list.

* The "$<CUDA_COMPILER_ID:...>" and "$<CUDA_COMPILER_VERSION:...>"
  "generator expressions" were added.

* The "$<COMPILE_LANG_AND_ID:...>" generator expression was
  introduced to allow specification of compile options for target
  files based on the "CMAKE_<LANG>_COMPILER_ID" and "LANGUAGE" of each
  source file.

* A "$<FILTER:list,INCLUDE|EXCLUDE,regex>" "generator expression"
  has been added.

* A "$<REMOVE_DUPLICATES:list>" "generator expression" has been
  added.

* The "$<SHELL_PATH:...>" "generator expression" gained support for
  a list of paths.

* New "$<TARGET_FILE*>" "generator expressions" were added to
  retrieve the prefix, base name, and suffix of the file names of
  various artifacts:

  * "$<TARGET_FILE_PREFIX:...>"

  * "$<TARGET_FILE_BASE_NAME:...>"

  * "$<TARGET_FILE_SUFFIX:...>"

  * "$<TARGET_LINKER_FILE_PREFIX:...>"

  * "$<TARGET_LINKER_FILE_BASE_NAME:...>"

  * "$<TARGET_LINKER_FILE_SUFFIX:...>"

  * "$<TARGET_PDB_FILE_BASE_NAME:...>"

* The "$<TARGET_OBJECTS:...>" "generator expression" is now
  supported on "SHARED", "STATIC", "MODULE" libraries and executables.


CTest
-----

* The "ctest_submit()" command learned a new option: "BUILD_ID".
  This can be used to store the ID assigned to this build by CDash to
  a variable.

* The "ctest_update()" command learned to honor a new variable:
  "CTEST_UPDATE_VERSION_OVERRIDE". This can be used to specify the
  current version of your source tree rather than using the update
  command to discover the current version that is checked out.


CPack
-----

* The "CPack IFW Generator" gained a new
  "CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer
  stylesheet.


Deprecated and Removed Features
===============================

* The "cmake-server(7)" mode has been deprecated and will be removed
  from a future version of CMake.  Please port clients to use the
  "cmake-file-api(7)" instead.

* The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now
  deprecated.  Use the "ADDITIONAL_CLEAN_FILES" directory property
  instead.

* The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered
  deprecated. Support still exists but will be removed in future
  versions.

* The "export(PACKAGE)" command now does nothing unless enabled via
  "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".

* The "Xcode" generator now requires at least Xcode 5.

* An explicit deprecation diagnostic was added for policy "CMP0066"
  ("CMP0065" and below were already deprecated). The "cmake-
  policies(7)" manual explains that the OLD behaviors of all policies
  are deprecated and that projects should port to the NEW behaviors.


Other Changes
=============

* CMake learned how to compile C++14 with the IBM AIX XL compiler
  and the SunPro compiler and to compile C++20 with the AppleClang
  compiler.

* With MSVC-like compilers the value of "CMAKE_<LANG>_FLAGS" no
  longer contains warning flags like "/W3" by default. See policy
  "CMP0092".

* IBM Clang-based XL compilers that define "__ibmxl__" now use the
  compiler id "XLClang" instead of "XL".  See policy "CMP0089".

* The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were
  changed to ignore empty arguments with a warning instead of treating
  them as a relative path and removing the contents of the current
  directory.


----------------------------------------------------------------------------
Changes made since CMake 3.15.0-rc1:

Alexander Grund (5):
  Tests.FindBoost: Don't use BoostConfig in MODULE test
  Tests.RunCMake.FindBoost: Fix example BoostConfig
  FindBoost: Don't overwrite Boost_${_comp}_FOUND
  FindBoost: Add legacy variables and targets for compatibility
  FindBoost: Add tests for legacy variables

Alexander Neumann (1):
  FindBLAS: Add second try for OpenBLAS with thread libraries.

Brad King (8):
  Help: Document XLClang compiler id
  fileapi: Factor out helper to construct a version object
  cmake: Simplify implementation of -E capabilities
  cmake: Teach -E capabilities to report supported fileapi requests
  cmake-gui: Update Qt copyright holder in About dialog
  fileapi: Suppress lint warning about non-move with old jsoncpp
  Help: Document what project() calls use CMAKE_PROJECT_INCLUDE and friends
  CMake 3.15.0-rc2

Craig Scott (2):
  Help: Trivial typo and grammar fixes for FindEnvModules
  Help: Move ADDITIONAL_MAKE_CLEAN_FILES dir prop to deprecated section

Cristian Adam (1):
  find_package: Fixed CMAKE_FIND_PACKAGE_PREFER_CONFIG Module fallback

Marc Chevrier (1):
  Android: ensure PIE behavior is consistent regardless CMP0083 policy

Mathieu Malaterre (1):
  CPack/NuGet: Find nuget tool on case sensitive file system

Robert Maynard (1):
  FindMPI: Store imported target link flags as a list instead of a string

Rolf Eike Beer (1):
  CheckCXXSymbolExists: reference to CheckCXXSourceCompiles instead of C version

Sebastian Holtermann (2):
  Autogen: Fix header detection for paths with symbolic links
  Help: Improve ADDITIONAL_CLEAN_FILES documentation

From doenges at mvtec.com  Wed Jun 19 18:48:56 2019
From: doenges at mvtec.com (=?UTF-8?Q?Eric_D=c3=b6nges?=)
Date: Thu, 20 Jun 2019 00:48:56 +0200
Subject: [CMake] Write CMakeLists.txt for this C++ program
In-Reply-To: <1560951390237-0.post@n2.nabble.com>
References: <1560940949778-0.post@n2.nabble.com>
 <52863f25-e2e8-d596-7bb6-0d8662115f2c@mvtec.com>
 <1560951390237-0.post@n2.nabble.com>
Message-ID: <9f903729-b7eb-fb14-c6e6-47e9f8b9387d@mvtec.com>

On 19.06.19 15:36, dexter810 wrote:

> *Approach 1:*
> CMakeLists.txt:
> 
> cmake_minimum_required(VERSION 3.6)
> project(main CXX C)
> 
> add_executable(main main.cpp)
> 
> target_include_directories(main PRIVATE
>                 include build/deps/yara/src/yara/libyara/include) 
> 
> 
>  target_link_libraries (main
>                 -Lbuild/src/ -Lbuild/deps/yara/src/yara/libyara/.libs
>                 yaracpp yara pthread ssl crypto) 

I've done a little testing - the reason this approach doesn't work is
because when CMake calls the linker, the current directory is not the
source directory, but the build directory. For this approach to work you
would need to write:

target_include_directories(main PRIVATE
	${CMAKE_CURRENT_SOURCE_DIR}/include
	${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/include)

target_link_libraries (main
	-L${CMAKE_CURRENT_SOURCE_DIR}/build/src/
	-L${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/.libs
    yaracpp yara pthread ssl crypto)

> *
> Approach 2:*
> 
> CMakeLists.txt: 
> cmake_minimum_required(VERSION 3.6)
> project(main CXX C)
> 
> add_executable(main main.cpp)
> 
> 
> 
> add_library(yara STATIC IMPORTED)
> set_target_properties(yara PROPERTIES
>                 IMPORTED_LOCATION
> "build/deps/yara/src/yara/libyara/.libs/libyara.a"
>                 INTERFACE_INCLUDE_DIRECTORIES
> "build/deps/yara/src/yara/libyara/include")
> 
> add_library(yaracpp STATIC IMPORTED)
> set_target_properties(yaracpp PROPERTIES
>                 IMPORTED_LOCATION "build/src/libyaracpp.a"
>                 INTERFACE_INCLUDE_DIRECTORIES "include")

This cannot work because you forgot the

target_link_libraries(main yara yaracpp pthread ssl crypto)

CMake is not psychic, you need to explicitly tell it which libraries
main will be needing.

> Approach 3*
> CMakeLists.txt:
> cmake_minimum_required(VERSION 3.6)
> project(main CXX C)
> 
> add_executable(main main.cpp)
> 
> target_include_directories(main PRIVATE
>                 include build/deps/yara/src/yara/libyara/include) 
> 
> 
>  target_link_libraries (main
>                 -Lbuild/src/libyaracpp.a
> -Lbuild/deps/yara/src/yara/libyara/.libs/libyara.a
>                 yaracpp yara pthread ssl crypto) 

This approach cannot work because the -L option tells the compiler in
which (additional) directory to look for libraries. If you want to use
the full path to the library, you would use:

target_link_libraries (main
	build/src/libyaracpp.a
	build/deps/yara/src/yara/libyara/.libs/libyara.a
	yaracpp yara pthread ssl crypto)

> Also, inside target_link_libraries() irrespective of putting -lyaracpp and
> -lyara or yaracpp and yara, I got the same errors.

I believe CMake will automatically add the -l if you specify an argument
to target_link_libraries that is not a CMake target itself and not an
absolute path when building for Unix-like systems.

From doenges at mvtec.com  Wed Jun 19 18:53:28 2019
From: doenges at mvtec.com (=?UTF-8?Q?Eric_D=c3=b6nges?=)
Date: Thu, 20 Jun 2019 00:53:28 +0200
Subject: [CMake] Write CMakeLists.txt for this C++ program
In-Reply-To: <9f903729-b7eb-fb14-c6e6-47e9f8b9387d@mvtec.com>
References: <1560940949778-0.post@n2.nabble.com>
 <52863f25-e2e8-d596-7bb6-0d8662115f2c@mvtec.com>
 <1560951390237-0.post@n2.nabble.com>
 <9f903729-b7eb-fb14-c6e6-47e9f8b9387d@mvtec.com>
Message-ID: <68a4b271-4e4d-518a-f429-69ad54c68f05@mvtec.com>

To correct myself:

On 20.06.19 00:48, Eric D?nges wrote:
> 
> target_link_libraries (main
> 	build/src/libyaracpp.a
> 	build/deps/yara/src/yara/libyara/.libs/libyara.a
> 	yaracpp yara pthread ssl crypto)
> 

This of course should be

target_link_libraries (main
 	build/src/libyaracpp.a
 	build/deps/yara/src/yara/libyara/.libs/libyara.a
 	pthread ssl crypto)

From themiwi at gmail.com  Thu Jun 20 04:49:40 2019
From: themiwi at gmail.com (Michael Wild)
Date: Thu, 20 Jun 2019 10:49:40 +0200
Subject: [CMake] CMake Digest, Vol 182, Issue 32
In-Reply-To: <mailman.488.1560936618.2626.cmake@cmake.org>
References: <mailman.488.1560936618.2626.cmake@cmake.org>
Message-ID: <CAALQ5rm+4YJ5Zuwz9hxQyG=V+Wv9L7DZw8mGt=nhJiz6NF3TGQ@mail.gmail.com>

On Wed, Jun 19, 2019 at 11:30 AM Innokentiy Alaytsev wrote:
> Hello!
>
> Are the header files of the shared library (DLL) listed as INTERFACE_SOURCES
> for the library target? AFAIK, the only reason for header files to be
> processed by AUTOMOC is to be part of the project. The only way that I know
> of for adding library headers to the consuming project is by declaring them
> as INTERFACE sources of the library target.
>
> Best regards,
> Innokentiy Alaytsev

Hi Innokentiy

Thanks, your answer gave me the hint I needed. And yes, I was being stupid :-)

Problem was that I used `target_sources( PRIVATE mywindow.cpp PUBLIC
mywindow.h )` misinterpreting what `PUBLIC` does. I figured it would
add it to the `PUBLIC_HEADER` property; I would never have imagined
that it causes the `mywindow.h` header to be added as a source to the
targets that link against the library! So, I should do some RTFM on
all the new shiny features in CMake...

Kind regards

Michael

From kris.f.thielemans at gmail.com  Thu Jun 20 07:21:10 2019
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Thu, 20 Jun 2019 12:21:10 +0100
Subject: [CMake] ExternalProjectAdd and patch on Windows
Message-ID: <01c701d5275a$43992eb0$cacb8c10$@gmail.com>

Hi all

 

I have a superbuild project where I need to patch a library (HDF5) after
download. In Windows, there's no "patch" or "sed" command, and  this has to
run on other people's computer. I can almost achieve what I want in
Powershell like so

 

get-content ConfigureChecks.cmake

| %{$_ -replace "H5_HAVE_TIMEZONE 1","H5_HAVE_TIMEZONE 0"} > xx;move-item
-Force xx ConfigureChecks.cmake

 

(all on 1 line).

 

Unfortunately, Powershell has now converted the file in some other encoding
(I guess UTF-8), which doesn't make sense for the subsequent compilation.

 

Supposing I could resolved that, I have trouble passing this to
PATCH_COMMAND. I tried

 

  ExternalProject_Add(${proj}

   ${${proj}_EP_ARGS}

    .

    PATCH_COMMAND powershell -Command "get-content ConfigureChecks.cmake |
%{$_ -replace \"H5_HAVE_TIMEZONE 1\",\"H5_HAVE_TIMEZONE 0\"} > xx; move-item
-Force xx ConfigureChecks.cmake "

   .

   )

 

But the semi-colon doesn't seem to work

 

2>  Performing patch step for 'HDF5'

2>  ForEach-Object : Cannot bind parameter 'RemainingScripts'. Cannot
convert the "move-item" value of type

2>  "System.String" to type "System.Management.Automation.ScriptBlock".

2>  At line:1 char:50

2>  + ... cks.cmake | %{$_ -replace "H5_HAVE_TIMEZONE 1","H5_HAVE_TIMEZONE
0"}  ...

2>  +
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2>      + CategoryInfo          : InvalidArgument: (:) [ForEach-Object],
ParameterBindingException

2>      + FullyQualifiedErrorId :
CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.ForEachObjectCo
mmand

 

 

Trying to split it up as 2 commands (for instance the first powershell and
the next cmd, but I could have used powershell as well)

 

    PATCH_COMMAND

      powershell -Command "get-content ConfigureChecks.cmake | %{$_ -replace
\"H5_HAVE_TIMEZONE 1\",\"H5_HAVE_TIMEZONE 0\"} > xx"

      move /Y xx ConfigureChecks.cmake

 

gives almost the same error message (but now with "move" as opposed to
"move-item")

 

Anyone any suggestions?

 

Many thanks

Kris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190620/144d01c2/attachment.html>

From cristian.adam at gmail.com  Thu Jun 20 07:28:06 2019
From: cristian.adam at gmail.com (Cristian Adam)
Date: Thu, 20 Jun 2019 13:28:06 +0200
Subject: [CMake] ExternalProjectAdd and patch on Windows
In-Reply-To: <01c701d5275a$43992eb0$cacb8c10$@gmail.com>
References: <01c701d5275a$43992eb0$cacb8c10$@gmail.com>
Message-ID: <CA+u+m-KZ_=2jNr1LG-s32Rfyx66SF5-EA1-BS5H_4T5VLL7h6Q@mail.gmail.com>

Hi,

If the users have git installed, you could try find_program(git...), and
then "git apply", which should work to apply patches.

Cheers,
Cristian.

On Thu, Jun 20, 2019 at 1:21 PM Kris Thielemans <kris.f.thielemans at gmail.com>
wrote:

> Hi all
>
>
>
> I have a superbuild project where I need to patch a library (HDF5) after
> download. In Windows, there?s no ?patch? or ?sed? command, and  this has to
> run on other people?s computer. I can almost achieve what I want in
> Powershell like so
>
>
>
> get-content ConfigureChecks.cmake
>
> | %{$_ -replace "H5_HAVE_TIMEZONE 1","H5_HAVE_TIMEZONE 0"} > xx;move-item
> -Force xx ConfigureChecks.cmake
>
>
>
> (all on 1 line).
>
>
>
> Unfortunately, Powershell has now converted the file in some other
> encoding (I guess UTF-8), which doesn?t make sense for the subsequent
> compilation.
>
>
>
> Supposing I could resolved that, I have trouble passing this to
> PATCH_COMMAND. I tried
>
>
>
>   ExternalProject_Add(${proj}
>
>    ${${proj}_EP_ARGS}
>
>     ?
>
>     PATCH_COMMAND powershell -Command ?get-content ConfigureChecks.cmake |
> %{$_ -replace \"H5_HAVE_TIMEZONE 1\",\"H5_HAVE_TIMEZONE 0\"} > xx;
> move-item -Force xx ConfigureChecks.cmake ?
>
>    ?
>
>    )
>
>
>
> But the semi-colon doesn?t seem to work
>
>
>
> 2>  Performing patch step for 'HDF5'
>
> 2>  ForEach-Object : Cannot bind parameter 'RemainingScripts'. Cannot
> convert the "move-item" value of type
>
> 2>  "System.String" to type "System.Management.Automation.ScriptBlock".
>
> 2>  At line:1 char:50
>
> 2>  + ... cks.cmake | %{$_ -replace "H5_HAVE_TIMEZONE 1","H5_HAVE_TIMEZONE
> 0"}  ...
>
> 2>  +
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> 2>      + CategoryInfo          : InvalidArgument: (:) [ForEach-Object],
> ParameterBindingException
>
> 2>      + FullyQualifiedErrorId :
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.ForEachObjectCommand
>
>
>
>
>
> Trying to split it up as 2 commands (for instance the first powershell and
> the next cmd, but I could have used powershell as well)
>
>
>
>     PATCH_COMMAND
>
>       powershell -Command "get-content ConfigureChecks.cmake | %{$_
> -replace \"H5_HAVE_TIMEZONE 1\",\"H5_HAVE_TIMEZONE 0\"} > xx"
>
>       move /Y xx ConfigureChecks.cmake
>
>
>
> gives almost the same error message (but now with ?move? as opposed to
> ?move-item?)
>
>
>
> Anyone any suggestions?
>
>
>
> Many thanks
>
> Kris
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190620/8eeb663e/attachment-0001.html>

From david.aldrich.ntml at gmail.com  Thu Jun 20 11:39:34 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Thu, 20 Jun 2019 16:39:34 +0100
Subject: [CMake] How to specify Redhat Developer Toolset compiler?
Message-ID: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>

My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:

$ /usr/bin/x86_64-redhat-linux-g++ --version
x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

I have a very simple CMakeLists.txt:

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
project(hello_world LANGUAGES CXX)

add_executable(hello_world "")

target_sources(hello_world
  PRIVATE
    main.cpp
    Message.hpp
    Message.cpp)

I also have Redhat Developer Toolset 7 installed which I can enable in my
bash shell:

$ scl enable devtoolset-7 bash
$ which g++
/opt/rh/devtoolset-7/root/usr/bin/g++
$ g++ --version
g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)

How can I get CMake to use the later version of g++ instead of 4.8.5?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190620/dca676e3/attachment.html>

From Andreas-Naumann at gmx.net  Thu Jun 20 11:51:37 2019
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Thu, 20 Jun 2019 17:51:37 +0200
Subject: [CMake] How to specify Redhat Developer Toolset compiler?
In-Reply-To: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
References: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
Message-ID: <e04c3f12-385f-5c53-49b6-4411925fd519@gmx.net>

You could set the environment variables CXX and CC such that they point
to your toolset compiler

Am 20.06.19 um 17:39 schrieb David Aldrich:
> My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:
>
> $ /usr/bin/x86_64-redhat-linux-g++ --version
> x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
>
> I have a very simple CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
> project(hello_world LANGUAGES CXX)
>
> add_executable(hello_world "")
>
> target_sources(hello_world
> ? PRIVATE
> ? ? main.cpp
> ? ? Message.hpp
> ? ? Message.cpp)
>
> I also have?Redhat Developer Toolset 7 installed which I can enable in
> my bash shell:
>
> $ scl enable devtoolset-7 bash
> $ which g++
> /opt/rh/devtoolset-7/root/usr/bin/g++
> $ g++ --version
> g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
>
> How can I get CMake to use the later version of g++ instead of 4.8.5?
>
>


From eric.noulard at gmail.com  Thu Jun 20 11:57:46 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 20 Jun 2019 17:57:46 +0200
Subject: [CMake] How to specify Redhat Developer Toolset compiler?
In-Reply-To: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
References: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
Message-ID: <CAPASGLribJUti5DOTu0PO1QC+RYcBoOuzircxPY1-7ejCxsfkw@mail.gmail.com>

I would bet that enabling the toolset before launching CMake will do the
trick.
Otherwise set CC and/or CXX env var to the desired path before launching
CMake.

Le jeu. 20 juin 2019 ? 17:39, David Aldrich <david.aldrich.ntml at gmail.com>
a ?crit :

> My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:
>
> $ /usr/bin/x86_64-redhat-linux-g++ --version
> x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
>
> I have a very simple CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
> project(hello_world LANGUAGES CXX)
>
> add_executable(hello_world "")
>
> target_sources(hello_world
>   PRIVATE
>     main.cpp
>     Message.hpp
>     Message.cpp)
>
> I also have Redhat Developer Toolset 7 installed which I can enable in my
> bash shell:
>
> $ scl enable devtoolset-7 bash
> $ which g++
> /opt/rh/devtoolset-7/root/usr/bin/g++
> $ g++ --version
> g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
>
> How can I get CMake to use the later version of g++ instead of 4.8.5?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190620/89559d03/attachment.html>

From scott at towel42.com  Thu Jun 20 12:23:00 2019
From: scott at towel42.com (Scott Bloom)
Date: Thu, 20 Jun 2019 16:23:00 +0000
Subject: [CMake] How to specify Redhat Developer Toolset compiler?
In-Reply-To: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
References: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
Message-ID: <CY4PR1001MB21826AA9474058D1456F3C79A9E40@CY4PR1001MB2182.namprd10.prod.outlook.com>

We have a similar issue at my company, so the call to /opt/rh/devtoolset-X/enable is done in our bashrc files

Then we use CMAKE_<LANG>_COMPILER_VERSION in our cmake file to make sure its set correctly.

Scott

From: CMake <cmake-bounces at cmake.org> On Behalf Of David Aldrich
Sent: Thursday, June 20, 2019 8:40 AM
To: CMake MailingList <cmake at cmake.org>
Subject: [CMake] How to specify Redhat Developer Toolset compiler?

My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:

$ /usr/bin/x86_64-redhat-linux-g++ --version
x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

I have a very simple CMakeLists.txt:

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
project(hello_world LANGUAGES CXX)

add_executable(hello_world "")

target_sources(hello_world
  PRIVATE
    main.cpp
    Message.hpp
    Message.cpp)

I also have Redhat Developer Toolset 7 installed which I can enable in my bash shell:

$ scl enable devtoolset-7 bash
$ which g++
/opt/rh/devtoolset-7/root/usr/bin/g++
$ g++ --version
g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)

How can I get CMake to use the later version of g++ instead of 4.8.5?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190620/3c3a4225/attachment.html>

From jim.melton at sncorp.com  Thu Jun 20 12:37:23 2019
From: jim.melton at sncorp.com (Jim Melton)
Date: Thu, 20 Jun 2019 16:37:23 +0000
Subject: [CMake] How to specify Redhat Developer Toolset compiler?
In-Reply-To: <e04c3f12-385f-5c53-49b6-4411925fd519@gmx.net>
References: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
 <e04c3f12-385f-5c53-49b6-4411925fd519@gmx.net>
Message-ID: <dc4823e1a10045279da23207a247be91@sncorp.com>

I fought with this and ended up with the below approach. Note that these values are cached, so you must start with a clean build directory before changing. Assuming your desired versions are on your path:

CC=$(which gcc) CXX=$(which g++) cmake3 <other args to cmake>

---
Jim Melton
Principal Software Engineer
Sierra Nevada Corporation


-----Original Message-----
From: CMake <cmake-bounces at cmake.org> On Behalf Of Andreas Naumann
Sent: Thursday, June 20, 2019 09:52
To: CMake MailingList <cmake at cmake.org>
Subject: [EXTERNAL] Re: [CMake] How to specify Redhat Developer Toolset compiler?

You could set the environment variables CXX and CC such that they point to your toolset compiler

Am 20.06.19 um 17:39 schrieb David Aldrich:
> My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:
>
> $ /usr/bin/x86_64-redhat-linux-g++ --version x86_64-redhat-linux-g++ 
> (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
>
> I have a very simple CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5 FATAL_ERROR) project(hello_world 
> LANGUAGES CXX)
>
> add_executable(hello_world "")
>
> target_sources(hello_world
> ? PRIVATE
> ? ? main.cpp
> ? ? Message.hpp
> ? ? Message.cpp)
>
> I also have?Redhat Developer Toolset 7 installed which I can enable in 
> my bash shell:
>
> $ scl enable devtoolset-7 bash
> $ which g++
> /opt/rh/devtoolset-7/root/usr/bin/g++
> $ g++ --version
> g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
>
> How can I get CMake to use the later version of g++ instead of 4.8.5?
>
>

-- 

Powered by www.kitware.com

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

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

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

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

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

CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You.

From patrick.nadeau at autodesk.com  Thu Jun 20 13:30:04 2019
From: patrick.nadeau at autodesk.com (Patrick Nadeau)
Date: Thu, 20 Jun 2019 17:30:04 +0000
Subject: [CMake] Running tests on a nomad cluster
Message-ID: <D9313ADB.13EEB%patrick.nadeau@autodesk.com>

Hi,

We use cmake for one of our projects, which has ~400 tests.  All in all, they take about an hour to run.

What I?d like to do is to submit the tests as batch jobs on our nomad cluster.  This part I can easily do, via some python script or go executable.

What I?m not sure about is how to integrate this with ctest.

What would be the best way to do this with cmake?

Is there some way to run a script of executable in cmake which would act as a stub of the real test executable?

I figure if I just output the same exit code and stdin/stderr streams, it might be possible without too many changes to our cmake scripts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190620/910cadae/attachment.html>

From juan.e.sanchez at gmail.com  Thu Jun 20 13:37:10 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Thu, 20 Jun 2019 12:37:10 -0500
Subject: [CMake] How to specify Redhat Developer Toolset compiler?
In-Reply-To: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
References: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
Message-ID: <CAEHOsR3nfxCSfO29kjQmA8FXijJVCO6bL18vmNRna2A2QQ2xUg@mail.gmail.com>

Hello,

I use a bash script, like this for devtoolset-6.

https://github.com/devsim/devsim/blob/master/scripts/setup_centos_6.sh

Regards,

Juan


On Thu, Jun 20, 2019 at 10:39 AM David Aldrich <david.aldrich.ntml at gmail.com>
wrote:

> My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:
>
> $ /usr/bin/x86_64-redhat-linux-g++ --version
> x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
>
> I have a very simple CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
> project(hello_world LANGUAGES CXX)
>
> add_executable(hello_world "")
>
> target_sources(hello_world
>   PRIVATE
>     main.cpp
>     Message.hpp
>     Message.cpp)
>
> I also have Redhat Developer Toolset 7 installed which I can enable in my
> bash shell:
>
> $ scl enable devtoolset-7 bash
> $ which g++
> /opt/rh/devtoolset-7/root/usr/bin/g++
> $ g++ --version
> g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
>
> How can I get CMake to use the later version of g++ instead of 4.8.5?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190620/4ee82257/attachment-0001.html>

From dmacq at instantiations.com  Thu Jun 20 15:45:55 2019
From: dmacq at instantiations.com (Donald MacQueen [|])
Date: Thu, 20 Jun 2019 15:45:55 -0400
Subject: [CMake] Make Timeout not be a failure
Message-ID: <459d3b8a-9bc3-a5a2-75b8-1bc9e2acaf50@instantiations.com>

I have a test where I start a program that I know will create some 
output that I can test.

But I have no way to kill this program, so I let Ctest kill it with a 
TIMEOUT.

The next step greps the output to see if it worked.

So it would be nice if? PASS_REGULAR_EXPRESSION? could override TIMEOUT 
and not mark the test as failed.

For example:

 ??? set_tests_properties(${importMaps} PROPERTIES 
PASS_REGULAR_EXPRESSION "some string I know I will find")
 ?? ?#???????????????????????????????????????????????????????? this 
^^^^^^^^^^^^^^^^^^^^^^ makes the test pass even if it times out
 ?? ?set_tests_properties(${importMaps} PROPERTIES TIMEOUT 60)

-- 
Donald [|]
A bad day in [] is better than a good day in {}.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From kyle.edwards at kitware.com  Thu Jun 20 15:52:57 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Thu, 20 Jun 2019 15:52:57 -0400
Subject: [CMake] Make Timeout not be a failure
In-Reply-To: <459d3b8a-9bc3-a5a2-75b8-1bc9e2acaf50@instantiations.com>
References: <459d3b8a-9bc3-a5a2-75b8-1bc9e2acaf50@instantiations.com>
Message-ID: <1561060377.3727.8.camel@kitware.com>

On Thu, 2019-06-20 at 15:45 -0400, Donald MacQueen [|] via CMake wrote:
> I have a test where I start a program that I know will create some?
> output that I can test.
> 
> But I have no way to kill this program, so I let Ctest kill it with
> a?
> TIMEOUT.
> 
> The next step greps the output to see if it worked.
> 
> So it would be nice if? PASS_REGULAR_EXPRESSION? could override
> TIMEOUT?
> and not mark the test as failed.
> 
> For example:
> 
> ???? set_tests_properties(${importMaps} PROPERTIES?
> PASS_REGULAR_EXPRESSION "some string I know I will find")
> ??? ?#???????????????????????????????????????????????????????? this?
> ^^^^^^^^^^^^^^^^^^^^^^ makes the test pass even if it times out
> ??? ?set_tests_properties(${importMaps} PROPERTIES TIMEOUT 60)

You could wrap your test in a CMake script that calls execute_process()
with a TIMEOUT argument, and then greps the output of the command for
the desired expression. For example:

CMakeLists.txt:

add_test(NAME mytest COMMAND ${CMAKE_COMMAND} -DMYEXE=${PATH_TO_MYEXE}
-P ${CMAKE_CURRENT_LIST_DIR}/ExecuteTest.cmake)

ExecuteTest.cmake:

execute_process(COMMAND ${PATH_TO_MYEXE} TIMEOUT 60 OUTPUT_VARIABLE
output)
if(NOT output MATCHES "^my_desired_regex$")
? message(FATAL_ERROR "myexe did not produce desired output")
endif()

Hope that helps

Kyle

From dmacq at instantiations.com  Thu Jun 20 16:47:26 2019
From: dmacq at instantiations.com (Donald MacQueen [|])
Date: Thu, 20 Jun 2019 16:47:26 -0400
Subject: [CMake] Make Timeout not be a failure
In-Reply-To: <1561060377.3727.8.camel@kitware.com>
References: <459d3b8a-9bc3-a5a2-75b8-1bc9e2acaf50@instantiations.com>
 <1561060377.3727.8.camel@kitware.com>
Message-ID: <d631f342-bce4-93c0-6522-acb2206b59b3@instantiations.com>

HI Kyle,

Where are the -D and the -P switches of add_test documented?

Thanks for the suggestion.

On 6/20/2019 3:52 PM, Kyle Edwards wrote:
> On Thu, 2019-06-20 at 15:45 -0400, Donald MacQueen [|] via CMake wrote:
>> I have a test where I start a program that I know will create some
>> output that I can test.
>>
>> But I have no way to kill this program, so I let Ctest kill it with
>> a
>> TIMEOUT.
>>
>> The next step greps the output to see if it worked.
>>
>> So it would be nice if? PASS_REGULAR_EXPRESSION? could override
>> TIMEOUT
>> and not mark the test as failed.
>>
>> For example:
>>
>>  ???? set_tests_properties(${importMaps} PROPERTIES
>> PASS_REGULAR_EXPRESSION "some string I know I will find")
>>  ??? ?#???????????????????????????????????????????????????????? this
>> ^^^^^^^^^^^^^^^^^^^^^^ makes the test pass even if it times out
>>  ??? ?set_tests_properties(${importMaps} PROPERTIES TIMEOUT 60)
> You could wrap your test in a CMake script that calls execute_process()
> with a TIMEOUT argument, and then greps the output of the command for
> the desired expression. For example:
>
> CMakeLists.txt:
>
> add_test(NAME mytest COMMAND ${CMAKE_COMMAND} -DMYEXE=${PATH_TO_MYEXE}
> -P ${CMAKE_CURRENT_LIST_DIR}/ExecuteTest.cmake)
>
> ExecuteTest.cmake:
>
> execute_process(COMMAND ${PATH_TO_MYEXE} TIMEOUT 60 OUTPUT_VARIABLE
> output)
> if(NOT output MATCHES "^my_desired_regex$")
>  ? message(FATAL_ERROR "myexe did not produce desired output")
> endif()
>
> Hope that helps
>
> Kyle

-- 
Donald [|]
A bad day in [] is better than a good day in {}.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From kyle.edwards at kitware.com  Thu Jun 20 16:49:58 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Thu, 20 Jun 2019 16:49:58 -0400
Subject: [CMake] Make Timeout not be a failure
In-Reply-To: <d631f342-bce4-93c0-6522-acb2206b59b3@instantiations.com>
References: <459d3b8a-9bc3-a5a2-75b8-1bc9e2acaf50@instantiations.com>
 <1561060377.3727.8.camel@kitware.com>
 <d631f342-bce4-93c0-6522-acb2206b59b3@instantiations.com>
Message-ID: <1561063798.11175.0.camel@kitware.com>

On Thu, 2019-06-20 at 16:47 -0400, Donald MacQueen [|] wrote:
> HI Kyle,
> 
> Where are the -D and the -P switches of add_test documented?

Those are not part of add_test(), they are arguments that get passed to
the CMake executable. See for details:

https://cmake.org/cmake/help/v3.15/manual/cmake.1.html

Kyle

From kris.f.thielemans at gmail.com  Fri Jun 21 03:08:54 2019
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Fri, 21 Jun 2019 08:08:54 +0100
Subject: [CMake] ExternalProjectAdd and patch on Windows
In-Reply-To: <CA+u+m-KZ_=2jNr1LG-s32Rfyx66SF5-EA1-BS5H_4T5VLL7h6Q@mail.gmail.com>
References: <01c701d5275a$43992eb0$cacb8c10$@gmail.com>
 <CA+u+m-KZ_=2jNr1LG-s32Rfyx66SF5-EA1-BS5H_4T5VLL7h6Q@mail.gmail.com>
Message-ID: <02af01d52800$3039e7f0$90adb7d0$@gmail.com>

Thanks Cristian

 

That works wonderfully!

 

Kris

 

From: Cristian Adam 
Sent: 20 June 2019 12:28
To: Kris Thielemans

Cc: CMake Mail List <cmake at cmake.org>
Subject: Re: [CMake] ExternalProjectAdd and patch on Windows

 

Hi,

 

If the users have git installed, you could try find_program(git...), and then "git apply", which should work to apply patches.

 

Cheers,

Cristian.

 

On Thu, Jun 20, 2019 at 1:21 PM Kris Thielemans wrote:

Hi all

 

I have a superbuild project where I need to patch a library (HDF5) after download. In Windows, there?s no ?patch? or ?sed? command, and  this has to run on other people?s computer. I can almost achieve what I want in Powershell like so

 

get-content ConfigureChecks.cmake

| %{$_ -replace "H5_HAVE_TIMEZONE 1","H5_HAVE_TIMEZONE 0"} > xx;move-item -Force xx ConfigureChecks.cmake

 

(all on 1 line).

 

Unfortunately, Powershell has now converted the file in some other encoding (I guess UTF-8), which doesn?t make sense for the subsequent compilation.

 

Supposing I could resolved that, I have trouble passing this to PATCH_COMMAND. I tried

 

  ExternalProject_Add(${proj}

   ${${proj}_EP_ARGS}

    ?

    PATCH_COMMAND powershell -Command ?get-content ConfigureChecks.cmake | %{$_ -replace \"H5_HAVE_TIMEZONE 1\",\"H5_HAVE_TIMEZONE 0\"} > xx; move-item -Force xx ConfigureChecks.cmake ?

   ?

   )

 

But the semi-colon doesn?t seem to work

 

2>  Performing patch step for 'HDF5'

2>  ForEach-Object : Cannot bind parameter 'RemainingScripts'. Cannot convert the "move-item" value of type

2>  "System.String" to type "System.Management.Automation.ScriptBlock".

2>  At line:1 char:50

2>  + ... cks.cmake | %{$_ -replace "H5_HAVE_TIMEZONE 1","H5_HAVE_TIMEZONE 0"}  ...

2>  +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2>      + CategoryInfo          : InvalidArgument: (:) [ForEach-Object], ParameterBindingException

2>      + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.ForEachObjectCommand

 

 

Trying to split it up as 2 commands (for instance the first powershell and the next cmd, but I could have used powershell as well)

 

    PATCH_COMMAND

      powershell -Command "get-content ConfigureChecks.cmake | %{$_ -replace \"H5_HAVE_TIMEZONE 1\",\"H5_HAVE_TIMEZONE 0\"} > xx"

      move /Y xx ConfigureChecks.cmake

 

gives almost the same error message (but now with ?move? as opposed to ?move-item?)

 

Anyone any suggestions?

 

Many thanks

Kris

-- 

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:
https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/8b8c0f81/attachment-0001.html>

From david.aldrich.ntml at gmail.com  Fri Jun 21 04:59:00 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Fri, 21 Jun 2019 09:59:00 +0100
Subject: [CMake] How to specify Redhat Developer Toolset compiler?
In-Reply-To: <CAEHOsR3nfxCSfO29kjQmA8FXijJVCO6bL18vmNRna2A2QQ2xUg@mail.gmail.com>
References: <CAJK_iegod8GP5jzd2bkXLmnUVEfZ=tWPt3OrbA+AdWmhNnkkcQ@mail.gmail.com>
 <CAEHOsR3nfxCSfO29kjQmA8FXijJVCO6bL18vmNRna2A2QQ2xUg@mail.gmail.com>
Message-ID: <CAJK_iegt-EiBpcq0H2H5ExCg10GRoPfSP6gt0azgznDGqwrJAA@mail.gmail.com>

Thanks for all the replies. I decided to set CC and CXX in .bashrc:

source scl_source enable devtoolset-7
export CXX="/opt/rh/devtoolset-7/root/usr/bin/g++"
export CC="/opt/rh/devtoolset-7/root/usr/bin/gcc"

For reference, the FAQ entry is:
https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-do-i-use-a-different-compiler

I wonder why it says to avoid using set()?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/6cd62f69/attachment.html>

From meghna.vasudeva at gmail.com  Fri Jun 21 06:18:44 2019
From: meghna.vasudeva at gmail.com (dexter810)
Date: Fri, 21 Jun 2019 03:18:44 -0700 (MST)
Subject: [CMake] Building a c++ library using CMake in Android Studio
Message-ID: <1561112324899-0.post@n2.nabble.com>

I built this C++ library using CMake 3.10.2 in Ubuntu 18.04 and it was built
successfully. I'm trying to build it using the same CMakeLists.txt and
folder structure in Android Studio which is also using Cmake 3.10.2.

On running inspection results inside Android Studio, inside C++, declaration
order, it gave me several cannot resolve errors, from my understanding when
I built on Ubuntu, my build folder got populated with certain folders and
files which contained the header files, but after building in Android Studio
and looking inside the default build folder I couldn't find anything
remotely similar.
Is the way CMake works in Android Studio different than how CMake works in
say, Ubuntu?



--
Sent from: http://cmake.3232098.n2.nabble.com/

From david.aldrich.ntml at gmail.com  Fri Jun 21 09:19:29 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Fri, 21 Jun 2019 14:19:29 +0100
Subject: [CMake] How to support separate debug and release build directories?
Message-ID: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>

Thanks for the help I have received in the past few days. I am making
incremental improvements to my CMake project and have a new challenge.  I
am running CMake 3.13 on Centos 7.6, targeting make.  My CMake file
successfully builds debug or release targets and puts the executable in an
out-of-source build directory.  I have added debug and release make targets
so I can execute 'make debug' etc.

I now want to support separate target directories: build/debug and
build/release.  I've shown my CMakeLists.txt below. So far I've just added
an attempt to support build/debug:

if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
    message("debug mode")
    set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")

but:

$ cmake3 -DCMAKE_BUILD_TYPE=DEBUG ..

puts the target into build, not build/debug.

I would also like this to work if I use the make targets e.g. make debug.

Here's my full CMakeLists.txt.  Any advice would be appreciated.

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)

if(NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "Release")
  message(STATUS "Build type not specified: Use Release by default")
endif(NOT CMAKE_BUILD_TYPE)

project(hello_world LANGUAGES CXX)    # Among other things, this sets
PROJECT_NAME

add_executable(${PROJECT_NAME} "")

target_include_directories(${PROJECT_NAME}
    PRIVATE
        ${CMAKE_CURRENT_SOURCE_DIR})

target_sources(${PROJECT_NAME}
  PRIVATE
    main.cpp
    Message.cpp)

ADD_CUSTOM_TARGET(debug
  COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Debug ${CMAKE_SOURCE_DIR}
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target all
  COMMENT "Creating the executable in the debug mode.")

ADD_CUSTOM_TARGET(release
  COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${CMAKE_SOURCE_DIR}
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target all
  COMMENT "Creating the executable in the release mode.")

if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
    message("debug mode")
    set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/ff39f1a4/attachment.html>

From markand at malikania.fr  Fri Jun 21 09:26:27 2019
From: markand at malikania.fr (David Demelier)
Date: Fri, 21 Jun 2019 15:26:27 +0200
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
Message-ID: <24cbb5c9-2e9d-23ae-1664-941850b96451@malikania.fr>

Le 21/06/2019 ? 15:19, David Aldrich a ?crit?:
> I now want to support separate target directories: build/debug and 
> build/release.? I've shown my CMakeLists.txt below. So far I've just 
> added an attempt to support build/debug:
> 
> if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
>  ? ? message("debug mode")
>  ? ? set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
> endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")
> 

Do never test CMAKE_BUILD_TYPE in CMakeLists.txt files, it is ignored in 
multiple generators (e.g. Visual Studio).

Just use the appropriate variables that contain suffixes regarding the 
configuration.

e.g

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/debug)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/release)

See [0] for a list with _<CONFIG> variables.

[0]: https://cmake.org/cmake/help/v3.15/manual/cmake-variables.7.html

HTH

-- 
David

From david.aldrich.ntml at gmail.com  Fri Jun 21 09:42:45 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Fri, 21 Jun 2019 14:42:45 +0100
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <24cbb5c9-2e9d-23ae-1664-941850b96451@malikania.fr>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
 <24cbb5c9-2e9d-23ae-1664-941850b96451@malikania.fr>
Message-ID: <CAJK_iegbTPn3UAwfqgMsz7RiQPUz-uDGVJMgxWBvY+1bTEd89Q@mail.gmail.com>

>
> Do never test CMAKE_BUILD_TYPE in CMakeLists.txt files, it is ignored in
> multiple generators (e.g. Visual Studio).
>

Does that mean I shouldn't have this in CMakeLists.txt? :

# Specify a Release build by default
if(NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "Release")
  message(STATUS "Build type not specified: Use Release by default")
endif(NOT CMAKE_BUILD_TYPE)


>
> Just use the appropriate variables that contain suffixes regarding the
> configuration.
>
> e.g
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/debug)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/release)
>
> See [0] for a list with _<CONFIG> variables.
>
> [0]: https://cmake.org/cmake/help/v3.15/manual/cmake-variables.7.html
>
> HTH
>

Thank you. That is working for me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/6c3fd7b7/attachment.html>

From markand at malikania.fr  Fri Jun 21 09:45:40 2019
From: markand at malikania.fr (David Demelier)
Date: Fri, 21 Jun 2019 15:45:40 +0200
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <CAJK_iegbTPn3UAwfqgMsz7RiQPUz-uDGVJMgxWBvY+1bTEd89Q@mail.gmail.com>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
 <24cbb5c9-2e9d-23ae-1664-941850b96451@malikania.fr>
 <CAJK_iegbTPn3UAwfqgMsz7RiQPUz-uDGVJMgxWBvY+1bTEd89Q@mail.gmail.com>
Message-ID: <67eff82c-0ebf-e4ff-5de6-668db0b2f1c9@malikania.fr>

Le 21/06/2019 ? 15:42, David Aldrich a ?crit?:
>     Do never test CMAKE_BUILD_TYPE in CMakeLists.txt files, it is
>     ignored in
>     multiple generators (e.g. Visual Studio).
> 
> Does that mean I shouldn't have this in CMakeLists.txt? :
> 
> # Specify a Release build by default
> if(NOT CMAKE_BUILD_TYPE)
>  ? set(CMAKE_BUILD_TYPE "Release")
>  ? message(STATUS "Build type not specified: Use Release by default")
> endif(NOT CMAKE_BUILD_TYPE)

It may be handy if you're sure that the project will only use single 
generators tools (e.g. make, ninja) otherwise yes it's strongly advised 
to not touch/inspect CMAKE_BUILD_TYPE if your project can be build with 
any kind of generators.

Regards

-- 
David


From braden at endoframe.com  Fri Jun 21 09:33:23 2019
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 21 Jun 2019 09:33:23 -0400
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
Message-ID: <dce32e585838ea595d0297e55691d4954c8f9d48.camel@endoframe.com>

On Fri, 2019-06-21 at 14:19 +0100, David Aldrich wrote:
> Thanks for the help I have received in the past few days. I am making
> incremental improvements to my CMake project and have a new
> challenge.  I am running CMake 3.13 on Centos 7.6, targeting make. 
> My CMake file successfully builds debug or release targets and puts
> the executable in an out-of-source build directory.  I have added
> debug and release make targets so I can execute 'make debug' etc.
> 
> I now want to support separate target directories: build/debug and
> build/release.  I've shown my CMakeLists.txt below. So far I've just
> added an attempt to support build/debug:
> 
> if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
>     message("debug mode")
>     set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/debug)
> endif (CMAKE_BUILD_TYPE EQUAL "DEBUG")
> 
> but:
> 
> $ cmake3 -DCMAKE_BUILD_TYPE=DEBUG ..
> 
> puts the target into build, not build/debug.

The conventional solution to this is to run cmake in the "build/debug"
directory.

> I would also like this to work if I use the make targets e.g. make
> debug.

I think that's outside the scope of the Makefile generator.  For that
generator, CMAKE_BUILD_TYPE is a configuration-wide setting.  If you
want a different configuration, you need a different build directory
(where "build directory" is wherever you run cmake).

-- 
Braden McDaniel <braden at endoframe.com>


From david.aldrich.ntml at gmail.com  Fri Jun 21 10:28:48 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Fri, 21 Jun 2019 15:28:48 +0100
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <dce32e585838ea595d0297e55691d4954c8f9d48.camel@endoframe.com>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
 <dce32e585838ea595d0297e55691d4954c8f9d48.camel@endoframe.com>
Message-ID: <CAJK_ieiNahRWj5Yi8zgyKOifMMyQf_rxK3g9aEyWFaY_D5FggA@mail.gmail.com>

>
> > I would also like this to work if I use the make targets e.g. make
> > debug.
>
> I think that's outside the scope of the Makefile generator.  For that
> generator, CMAKE_BUILD_TYPE is a configuration-wide setting.  If you
> want a different configuration, you need a different build directory
> (where "build directory" is wherever you run cmake).
>

If I don't use make targets (so that user can type 'make debug' etc) the
build command would be more cumbersome:

cmake3 --build -D CMAKE_BUILD_TYPE=Debug .

What would best practice be to provide convenient commands for our
developers to easily build the target ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/df05e05a/attachment.html>

From braden at endoframe.com  Fri Jun 21 10:47:19 2019
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 21 Jun 2019 10:47:19 -0400
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <CAJK_ieiNahRWj5Yi8zgyKOifMMyQf_rxK3g9aEyWFaY_D5FggA@mail.gmail.com>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
 <dce32e585838ea595d0297e55691d4954c8f9d48.camel@endoframe.com>
 <CAJK_ieiNahRWj5Yi8zgyKOifMMyQf_rxK3g9aEyWFaY_D5FggA@mail.gmail.com>
Message-ID: <7b2d439f47066596b5693479bf39737c543633d9.camel@endoframe.com>

On Fri, 2019-06-21 at 15:28 +0100, David Aldrich wrote:
> > > I would also like this to work if I use the make targets e.g.
> > make
> > > debug.
> > 
> > I think that's outside the scope of the Makefile generator.  For
> > that
> > generator, CMAKE_BUILD_TYPE is a configuration-wide setting.  If
> > you
> > want a different configuration, you need a different build
> > directory
> > (where "build directory" is wherever you run cmake).
> 
> If I don't use make targets (so that user can type 'make debug' etc)
> the build command would be more cumbersome:
> 
> cmake3 --build -D CMAKE_BUILD_TYPE=Debug .

Assuming that command actually triggers a reconfigure (when previously
configured with a different CMAKE_BUILD_TYPE), you'll most likely hose
incremental builds of the other build type(s).  (And if it doesn't
trigger a reconfigure in that case, it's pretty certainly not doing
what you want.)

> What would best practice be to provide convenient commands for our
> developers to easily build the target ?

For the Makefile generator, best practice is to use separate build
directories (i.e., places where you run cmake) for different
configurations (i.e., different settings recorded during the
configuration step).

If you want to provide developers with some known set(s) of
configuration settings, I suggest wrapper scripts that invoke cmake
with those settings.

-- 
Braden McDaniel <braden at endoframe.com>


From kris.f.thielemans at gmail.com  Fri Jun 21 11:19:19 2019
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Fri, 21 Jun 2019 16:19:19 +0100
Subject: [CMake] using variables in ExternalProject_Add arguments
Message-ID: <02dd01d52844$b33f3990$19bdacb0$@gmail.com>

Dear all

 

We have a Superbuild https://github.com/CCPPETMR/SIRF-SuperBuild. I'm trying
to introduce variables to reduce duplication. However, I'm getting weird
errors. 2 examples below. Any ideas? (I'm running this on Windows 10 at
present with CMake 3.13.2).

 

Many thanks

Kris

 

1.	Use of a variable for CMAKE_ARGS

 

ExternalProject_Add(${proj}

    ${${proj}_EP_ARGS}

    GIT_REPOSITORY ${${proj}_URL}

    GIT_TAG ${${proj}_TAG} 

    CMAKE_ARGS 

            ${HDF5_CMAKE_ARGS}

            -DBOOST_ROOT=${BOOST_ROOT}

    INSTALL_DIR ${ISMRMRD_Install_Dir}

 

With 

HDF5_CMAKE_ARGS=-DHDF5_ROOT:PATH=C:/Users/krisf/Documents/devel/build-VC/SIR
F-SuperBuild/INSTALL

 
-DHDF5_INCLUDE_DIRS:PATH=C:/Users/krisf/Documents/devel/build-VC/SIRF-SuperB
uild/INSTALL/include

       -DHDF5_FIND_DEBUG:BOOL=ON

 

Error:

5>  Performing configure step for 'ISMRMRD'

5>CUSTOMBUILD : CMake error : The source directory
"C:/Users/krisf/Documents/devel/build-VC/SIRF-SuperBuild/builds/ISMRMRD/buil
d" does not appear to contain CMakeLists.txt.

 

Indeed, that directory is where we sk the SuperBuild to build. The sources
sit in .SIRF-SuperBuild/sources/ISMRMRD. Why does it go to the build
directory? 

All works ok  when commenting out the HDF5_CMAKE_ARGS line, or by putting
its value directly in the ExternalProject_Add.

 

 

2.	Use of a variable for PATCH_COMMAND

 

find_program(GIT "git")

set(PATCH_COMMAND "${GIT} apply ${PATCHFILE}")

 

  ExternalProject_Add(${proj}

    ${${proj}_EP_ARGS}

    URL ${${proj}_URL}

    URL_HASH MD5=${${proj}_MD5}

    PATCH_COMMAND ${PATCH_COMMAND}

    ...

   )

 

Error:

2>  Performing patch step for 'HDF5'

2>  The filename, directory name, or volume label syntax is incorrect.

 

Everything works fine if I use

   PATCH_COMMAND ${GIT} apply ${PATCHFILE}

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/2efd87b8/attachment.html>

From david.aldrich.ntml at gmail.com  Fri Jun 21 12:09:49 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Fri, 21 Jun 2019 17:09:49 +0100
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <7b2d439f47066596b5693479bf39737c543633d9.camel@endoframe.com>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
 <dce32e585838ea595d0297e55691d4954c8f9d48.camel@endoframe.com>
 <CAJK_ieiNahRWj5Yi8zgyKOifMMyQf_rxK3g9aEyWFaY_D5FggA@mail.gmail.com>
 <7b2d439f47066596b5693479bf39737c543633d9.camel@endoframe.com>
Message-ID: <CAJK_ieh3ETGr6n0DO3umMtnbRMf0v3TPBmrjWgtAL99NCvZ0aQ@mail.gmail.com>

>
> > What would best practice be to provide convenient commands for our
> > developers to easily build the target ?
>
> For the Makefile generator, best practice is to use separate build
> directories (i.e., places where you run cmake) for different
> configurations (i.e., different settings recorded during the
> configuration step).
>
> If you want to provide developers with some known set(s) of
> configuration settings, I suggest wrapper scripts that invoke cmake
> with those settings.
>
> Thanks for your advice. I am not finding it easy to find 'patterns' for
these sort of issues. I would have thought that configuring a project with
separate debug and release directories would be quite typical. But it's
hard to find the recommended way of doing such things. Anyway, I think I am
on the right track now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/c4753921/attachment.html>

From mike.jackson at bluequartz.net  Fri Jun 21 14:40:10 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Fri, 21 Jun 2019 14:40:10 -0400
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <CAJK_ieh3ETGr6n0DO3umMtnbRMf0v3TPBmrjWgtAL99NCvZ0aQ@mail.gmail.com>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
 <dce32e585838ea595d0297e55691d4954c8f9d48.camel@endoframe.com>
 <CAJK_ieiNahRWj5Yi8zgyKOifMMyQf_rxK3g9aEyWFaY_D5FggA@mail.gmail.com>
 <7b2d439f47066596b5693479bf39737c543633d9.camel@endoframe.com>
 <CAJK_ieh3ETGr6n0DO3umMtnbRMf0v3TPBmrjWgtAL99NCvZ0aQ@mail.gmail.com>
Message-ID: <FB914832-F6B4-4B75-AD1E-60D08646C57E@bluequartz.net>

David, 

????I think a bit more explanation of the philosophy (at least how I interpret it) is needed. I see in your emails that you are ?targeting makefiles?. With CMake you need to really stop thinking this way. Rarely do you need to target any specific build system (although those times do come up?). A lot of folks I see coming from autoconf to CMake still try to treat CMake in the same way. Don?t. There are a few golden rules with CMake that if you adhere to those will allow you to use CMake much easier.

 

1: NEVER have the Source directory and the Build directory be the same place.

2: PREFER out-of-source build directories (Not required but helpful)

3: Try not to target specific generators (makefiles, visual studio, xcode)

 

What this looks like is the following. Say I have a project from github called Foo and I clone it onto my local filesystem. From a command line perspective you get the following:

 

Git clone https://github.com/somebody/Foo

 

The *Preferred* way is this

Clone Foo

*At the same directory level as Foo*

Mkdir Debug && cd Debug

Cmake -DCMAKE_BUILD_TYPE=Release ../Foo

 

 

# We can break rule 2 a bit by making subdirectories inside of Foo

 ??cd Foo

?? mkdir Debug && cd Debug

?? cmake -DCMAKE_BUILD_TYPE=Debug ../

?? make -j

 

We have just created a Debug build in the Debug Directory. Now, the same is analogous for the Release build.

 

Cd Foo

Mkdir Release && cd Release

Cmake -DCMAKE_BUILD_TYPE=Release ../

Make -j

 

*IF* you make these subdirectories in a source code top level be sure to add those directory names to the .gitignore file.

 

If your cmake is written properly then the build creates NOTHING inside of the source directory.

 

I hope this helps summarize all of the other emails. Glad to have you in the CMake community.

 

--

Mike Jackson 

 

From: CMake <cmake-bounces at cmake.org> on behalf of David Aldrich <david.aldrich.ntml at gmail.com>
Date: Friday, June 21, 2019 at 12:10 PM
To: Braden McDaniel <braden at endoframe.com>
Cc: CMake <cmake at cmake.org>
Subject: Re: [CMake] How to support separate debug and release build directories?

 

> What would best practice be to provide convenient commands for our
> developers to easily build the target ?

For the Makefile generator, best practice is to use separate build
directories (i.e., places where you run cmake) for different
configurations (i.e., different settings recorded during the
configuration step).

If you want to provide developers with some known set(s) of
configuration settings, I suggest wrapper scripts that invoke cmake
with those settings.

Thanks for your advice. I am not finding it easy to find 'patterns' for these sort of issues. I would have thought that configuring a project with separate debug and release directories would be quite typical. But it's hard to find the recommended way of doing such things. Anyway, I think I am on the right track now.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190621/2e33f1f7/attachment.html>

From craig.scott at crascit.com  Sat Jun 22 03:18:14 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 22 Jun 2019 17:18:14 +1000
Subject: [CMake] Multiple exports for a target installation
In-Reply-To: <8C4B0CF6-5C86-43C8-8C8A-E21C37EDB51A@fb.com>
References: <C739DF5E-E0DE-41C6-B6CF-25F23FE12FDF@fb.com>
 <CA+dygYk+OPb8MJQbQd1QRNSKQMCVaRbowSCVZepn-2Ejna9g4Q@mail.gmail.com>
 <8C4B0CF6-5C86-43C8-8C8A-E21C37EDB51A@fb.com>
Message-ID: <CA+dygYmG2M+TJsfUba5aDnZdR5_VKXD0Tdhrzm2etxHbRUcffQ@mail.gmail.com>

On Tue, Jun 18, 2019 at 10:29 AM Shoaib Meenai <smeenai at fb.com> wrote:

> Thank you!
>
>
>
> When you say having an export set that the other exports then depend on,
> do you mean the COMPONENT option of the install(EXPORT) signature, or
> something else? (Sadly the project I?m working with is still on CMake
> 3.4.3, whose documentation says something very different for the COMPONENT
> option than the latest version, but I?ll cross that bridge when I get to
> it.)
>

As far as components and export sets are concerned, the behavior isn't much
different between CMake 3.4 and 3.14. Think of it like this:

   - The config file for a package (i.e. its <packageName>Config.cmake
   file) may refer to one or more export sets. It can do this in a way that
   some or all of the export sets are optional, pulling them in if present,
   silently continuing if not. It depends on the way the project wants to
   define and use its export sets. For most projects, they will require all
   export sets they refer to to be present. The optional components of a
   find_package() call might map to optional export sets (just one example of
   how optional export sets might be used).
   - An export set defines targets. That set of targets can span across one
   or more components. The export set requires all of those components to be
   installed/present or it is considered ill-formed (or put another way, the
   installation is incomplete). The install(TARGETS ... EXPORT ...) command
   determines what targets are in which export set. The install(EXPORT ...)
   command defines what component the actual export file is part of (further
   discussion on this below).
   - A component can include targets, files and custom scripts to be
   invoked when installing that component from a build tree. Targets and files
   can technically be part of multiple components, but this would be
   relatively uncommon and may complicate the export picture. A component may
   depend on one or more other components, e.g. a Development component may
   require a Runtime component, such as Development headers requiring the
   Runtime shared library.

If a project decides to split up its exports across multiple export sets,
there can be dependencies between them. For example, a project might define
export set Algo which has components Fast and Accurate, and export set Apps
which has components Gui and CLI. The project's <packageName>Config.cmake
file requires the Algo export set to be present but the Apps export set is
optional and only pulled in if present. In this scenario, one might have
the Fast and Accurate components installed, but not the Gui or CLI
components. The Algo export set represents the mandatory parts of the
package that will always be needed. The Gui and CLI components might not be
installed if, for example, someone just wants to build against the
libraries provided by the Fast and Accurate components (i.e. they are
writing their own apps rather than wanting to use the apps that are
provided by the Gui and CLI components).

What can be a bit confusing is that the exported file itself is also part
of a component. That exported file might or might not need to be installed,
depending on whether the project is being distributed as purely runtime
components or whether other projects might be building against it and
therefore expect headers, package config files, etc. The exported file
(which is installed by install(EXPORT ...) ) is only needed for the latter,
so it is usually part of a Development component or something similarly
named (hopefully named something project-specific rather than just a
generic "Development"!). The <packageName>Config.cmake file is also part of
a component, and may be part of the same component that the export file is
in.

The above is how I think about packages, export sets and components. You
could have more complicated arrangements and have some overlap between
export sets, but I'd generally try to avoid that if possible. It's simpler
if you can structure things with clear and unambiguous dependencies without
cycles or overlaps. It's already quite involved even without those things!

HTH



>
>
> *From: *Craig Scott <craig.scott at crascit.com>
> *Date: *Saturday, June 15, 2019 at 10:43 PM
> *To: *Shoaib Meenai <smeenai at fb.com>
> *Cc: *"cmake at cmake.org" <cmake at cmake.org>
> *Subject: *Re: [CMake] Multiple exports for a target installation
>
>
>
>
>
>
>
> On Sat, Jun 15, 2019 at 9:03 PM Shoaib Meenai <smeenai at fb.com> wrote:
>
> Is it possible to associate a target with multiple exports? For example,
> if I'm building a project where I want to create multiple export sets, but
> there's some overlap in targets between those sets. I tried passing
> multiple EXPORT options to the install(TARGETS) signature but I just got an
> error: install TARGETS given unknown argument "EXPORT".
>
>
> Typically, you'd want your export sets to not be overlapping and to
> contain no cyclic dependencies. If you have a target in multiple export
> sets, it suggests that you probably should factor out that target to a
> separate export set that other exports then depend on. That said, if you
> have a scenario that legitimately requires a target in multiple export
> sets, then you would need to use multiple install() commands to achieve
> this, specifying a different export set for each one.
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190622/5fe40dde/attachment-0001.html>

From kris.f.thielemans at gmail.com  Sat Jun 22 05:53:29 2019
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sat, 22 Jun 2019 10:53:29 +0100
Subject: [CMake] using variables in ExternalProject_Add arguments
In-Reply-To: <02dd01d52844$b33f3990$19bdacb0$@gmail.com>
References: <02dd01d52844$b33f3990$19bdacb0$@gmail.com>
Message-ID: <006a01d528e0$58f73900$0ae5ab00$@gmail.com>

Dear all

 

I've managed to resolve this. My mistake was to use quotes:

 

WRONG:

  set(HDF5_CMAKE_ARGS

    "-DHDF5_ROOT:PATH=${HDF5_ROOT}

     -DHDF5_INCLUDE_DIRS:PATH=${HDF5_INCLUDE_DIRS}

     -DHDF5_FIND_DEBUG:BOOL=ON"

  )

 

CORRECT:

  set(HDF5_CMAKE_ARGS

     -DHDF5_ROOT:PATH=${HDF5_ROOT}

     -DHDF5_INCLUDE_DIRS:PATH=${HDF5_INCLUDE_DIRS}

     -DHDF5_FIND_DEBUG:BOOL=ON

  )

 

 

WRONG:

set(PATCH_COMMAND "${GIT} apply ${PATCHFILE}")

 

CORRECT:

set(PATCH_COMMAND ${GIT} apply ${PATCHFILE})

 

Kris

 

From: Kris Thielemans <kris.f.thielemans at gmail.com> 
Sent: 21 June 2019 16:19
To: 'CMake Mail List' <cmake at cmake.org>
Subject: using variables in ExternalProject_Add arguments

 

Dear all

 

We have a Superbuild https://github.com/CCPPETMR/SIRF-SuperBuild. I'm trying
to introduce variables to reduce duplication. However, I'm getting weird
errors. 2 examples below. Any ideas? (I'm running this on Windows 10 at
present with CMake 3.13.2).

 

Many thanks

Kris

 

1.	Use of a variable for CMAKE_ARGS

 

ExternalProject_Add(${proj}

    ${${proj}_EP_ARGS}

    GIT_REPOSITORY ${${proj}_URL}

    GIT_TAG ${${proj}_TAG} 

    CMAKE_ARGS 

            ${HDF5_CMAKE_ARGS}

            -DBOOST_ROOT=${BOOST_ROOT}

    INSTALL_DIR ${ISMRMRD_Install_Dir}

 

With 

HDF5_CMAKE_ARGS=-DHDF5_ROOT:PATH=C:/Users/krisf/Documents/devel/build-VC/SIR
F-SuperBuild/INSTALL

 
-DHDF5_INCLUDE_DIRS:PATH=C:/Users/krisf/Documents/devel/build-VC/SIRF-SuperB
uild/INSTALL/include

       -DHDF5_FIND_DEBUG:BOOL=ON

 

Error:

5>  Performing configure step for 'ISMRMRD'

5>CUSTOMBUILD : CMake error : The source directory
"C:/Users/krisf/Documents/devel/build-VC/SIRF-SuperBuild/builds/ISMRMRD/buil
d" does not appear to contain CMakeLists.txt.

 

Indeed, that directory is where we sk the SuperBuild to build. The sources
sit in .SIRF-SuperBuild/sources/ISMRMRD. Why does it go to the build
directory? 

All works ok  when commenting out the HDF5_CMAKE_ARGS line, or by putting
its value directly in the ExternalProject_Add.

 

 

2.	Use of a variable for PATCH_COMMAND

 

find_program(GIT "git")

set(PATCH_COMMAND "${GIT} apply ${PATCHFILE}")

 

  ExternalProject_Add(${proj}

    ${${proj}_EP_ARGS}

    URL ${${proj}_URL}

    URL_HASH MD5=${${proj}_MD5}

    PATCH_COMMAND ${PATCH_COMMAND}

    ...

   )

 

Error:

2>  Performing patch step for 'HDF5'

2>  The filename, directory name, or volume label syntax is incorrect.

 

Everything works fine if I use

   PATCH_COMMAND ${GIT} apply ${PATCHFILE}

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190622/182b36c4/attachment.html>

From kris.f.thielemans at gmail.com  Sun Jun 23 04:04:31 2019
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Sun, 23 Jun 2019 09:04:31 +0100
Subject: [CMake] cached variable for multiple files. Use FILEPATH ?
Message-ID: <00b501d5299a$4a6c1f80$df445e80$@gmail.com>

Hi

 

I need to store multiple libraries in one cached variable. Do I still give
it type FILEPATH?

 

Thanks

Kris

 

PS: 

In case you want to know why. We use a superbuild and need to pass the
location of the external project's libraries to the dependent project. We
currently do that via a non-cached variable. However, our users are then
tempted to issue "make" (or whatever) in the subfolder of the dependent
project. If the location of the external project's libraries is not cached,
this seems to lead to unexpected behaviour. Alternative suggestions welcome.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190623/aa6e16e0/attachment.html>

From meghna.vasudeva at gmail.com  Sun Jun 23 04:39:17 2019
From: meghna.vasudeva at gmail.com (dexter810)
Date: Sun, 23 Jun 2019 01:39:17 -0700 (MST)
Subject: [CMake] Write CMakeLists.txt for this C++ program
In-Reply-To: <1560940949778-0.post@n2.nabble.com>
References: <1560940949778-0.post@n2.nabble.com>
Message-ID: <1561279157881-0.post@n2.nabble.com>

I built this C++ executable using CMake 3.10.2 in Ubuntu 18.04 and it was
built
successfully using the first approach. I'm now trying to build it using the
same CMakeLists.txt and
folder structure in Android Studio which is also using CMake 3.10.2, this
time a library not an executable, that being the only change.

On running inspect code inside Android Studio, it gave me errors related to
the headers, it couldn't find them:
<http://cmake.3232098.n2.nabble.com/file/t398066/headers_problem.headers_problem> 

>From my understanding when I built on Ubuntu, my build folder got populated
with certain folders and files which contained the header files, but after
building in Android Studio and looking inside the default build folder I
couldn't find anything remotely similar.
Is the way CMake works in Android Studio different than how CMake works in
say, Ubuntu? 



--
Sent from: http://cmake.3232098.n2.nabble.com/

From cjw at ucar.edu  Sun Jun 23 09:49:01 2019
From: cjw at ucar.edu (Christopher Webster)
Date: Sun, 23 Jun 2019 07:49:01 -0600
Subject: [CMake] cmake on MinGW64; which generator
Message-ID: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>

Greetings,

? I am trying to figure out which generator to use on MinGW64 on Windows10, the 2-3 I have tried fail.

cmake version is 3.14.5


If I try "Unix Makefiles" I get:

$ cmake -S coin -B coin_build -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
System is unknown to cmake, create:
Platform/MINGW64_NT-10.0-17763 to use this system, please send your
config file to cmake at www.cmake.org so it can be added to cmake



If I try "MinGW Makefiles" I get:

$ cmake -S coin -B coin_build -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
CMake Error: Could not create named generator MinGW Makefiles

Generators
* Unix Makefiles?????????????? = Generates standard UNIX makefiles.
? Ninja??????????????????????? = Generates build.ninja files.
? CodeBlocks - Ninja?????????? = Generates CodeBlocks project files.
? CodeBlocks - Unix Makefiles? = Generates CodeBlocks project files.
? CodeLite - Ninja???????????? = Generates CodeLite project files.
? CodeLite - Unix Makefiles??? = Generates CodeLite project files.
? Sublime Text 2 - Ninja?????? = Generates Sublime Text 2 project files.
? Sublime Text 2 - Unix Makefiles
?????????????????????????????? = Generates Sublime Text 2 project files.
? Kate - Ninja???????????????? = Generates Kate project files.
? Kate - Unix Makefiles??????? = Generates Kate project files.
? Eclipse CDT4 - Ninja???????? = Generates Eclipse CDT 4.0 project files.
? Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files


Thanks for any guidance.

Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190623/c9bec942/attachment.html>

From cristian.adam at gmail.com  Sun Jun 23 10:58:26 2019
From: cristian.adam at gmail.com (Cristian Adam)
Date: Sun, 23 Jun 2019 16:58:26 +0200
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
Message-ID: <CA+u+m-JKzH=ZN5a-tZL0sn=4ApNdk9HtBoVmHOcg34NVYbontA@mail.gmail.com>

Hi,

You are most probably using MSys2, which means that you are using CMake
from MSys2,
and they patch CMake for their platform. This also means that CMake
upstream doesn't support it.

Here <https://paste.ubuntu.com/p/ypnMXfdK6t/> are the differences between
upstream CMake 3.14.3 and MSys2 CMake 3.14.3. No idea why
the MSys2 people didn't try to upstream this into CMake.

In this case you should get support from MSys2 people, or switch to upstream
CMake <https://cmake.org/download/> and standalone MinGW-w64
<https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/>
.

Alternatively you can try using the Ninja generator.

The problem with standalone MinGW-w64 is that you will not have the number
of libraries that MSys2 offers.
You can use a CMake package manager like Conan, or Hunter to obtain those
libraries.

I know this because when I tried to compile Qt6::Base with MSys2 I was not
able to compile, due to
various Msys2 problems. With upstream CMake, standalone MinGW-w64 and
Hunter 3rd party libraries
everything worked just fine. At https://bugreports.qt.io/browse/QTBUG-75578
I described how I compiled Qt6::Base.

Cheers,
Cristian.


On Sun, Jun 23, 2019 at 3:49 PM Christopher Webster <cjw at ucar.edu> wrote:

> Greetings,
>
>   I am trying to figure out which generator to use on MinGW64 on Windows10, the 2-3 I have tried fail.
>
> cmake version is 3.14.5
>
>
> If I try "Unix Makefiles" I get:
>
> $ cmake -S coin -B coin_build -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
> -- The C compiler identification is GNU 9.1.0
> -- The CXX compiler identification is GNU 9.1.0
> System is unknown to cmake, create:
> Platform/MINGW64_NT-10.0-17763 to use this system, please send your
> config file to cmake at www.cmake.org so it can be added to cmake
>
>
>
> If I try "MinGW Makefiles" I get:
>
> $ cmake -S coin -B coin_build -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
> CMake Error: Could not create named generator MinGW Makefiles
>
> Generators
> * Unix Makefiles               = Generates standard UNIX makefiles.
>   Ninja                        = Generates build.ninja files.
>   CodeBlocks - Ninja           = Generates CodeBlocks project files.
>   CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
>   CodeLite - Ninja             = Generates CodeLite project files.
>   CodeLite - Unix Makefiles    = Generates CodeLite project files.
>   Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
>   Sublime Text 2 - Unix Makefiles
>                                = Generates Sublime Text 2 project files.
>   Kate - Ninja                 = Generates Kate project files.
>   Kate - Unix Makefiles        = Generates Kate project files.
>   Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
>   Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files
>
>
> Thanks for any guidance.
>
> Chris
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190623/703a1f96/attachment-0001.html>

From Alan.W.Irwin1234 at gmail.com  Sun Jun 23 11:22:14 2019
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Sun, 23 Jun 2019 08:22:14 -0700 (PDT)
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
Message-ID: <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>

On 2019-06-23 07:49-0600 Christopher Webster wrote:

> Greetings,
>
> ? I am trying to figure out which generator to use on MinGW64 on Windows10, the 2-3 I have tried fail.
>
> cmake version is 3.14.5
>
>
> If I try "Unix Makefiles" I get:
>
> $ cmake -S coin -B coin_build -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
> -- The C compiler identification is GNU 9.1.0
> -- The CXX compiler identification is GNU 9.1.0
> System is unknown to cmake, create:
> Platform/MINGW64_NT-10.0-17763 to use this system, please send your
> config file to cmake at www.cmake.org so it can be added to cmake
>
>
>
> If I try "MinGW Makefiles" I get:
>
> $ cmake -S coin -B coin_build -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D
> CMake Error: Could not create named generator MinGW Makefiles
>

There are a lot of different platforms that use the MinGW-w64 compiler so you should probably
describe the platform where you are attempting to use that compiler in more detail.  For example,
it sounds like you are simply taking a normal Window platform and downloading the
MinGW-w64 compiler for that platform, but what is the exact URL for that download?

I don't have any recent direct experience myself (I have no access to
Microsoft Windows and Wine Windows bugs are currently blocking access
to MSYS2), but PLplot developers I am aquainted with have recently had
a lot of success with the [MSYS2
platform](https://github.com/msys2/msys2/wiki) which is another exaple
of a platform that uses the MinGW-w64 compiler.  For that platform
they have found that "Unix Makefiles" and "MSYS Makefiles" generally
give good results.  They haven't yet tried "MinGW Makefiles" but from
my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2)
experience for that generator you have to be sure that sh.exe is not
on your PATH (e.g., by renaming it) before it will work.  (I have
never quite been sure why that was a requirement, but my guess was the
"mingw" make version acts differently if it detects sh.exe.)  But
again from my ancient experience the rest of the Unix tools provided
by MSYS2 including bash.exe will likely work well with the "MinGW
Makefiles" generator.

I hope this (ancient direct and recent indirect) practical experience
with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and
MinGW-w64 will be of some help to you.

Alan
__________________________
Alan W. Irwin

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.org); 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 ggarra13 at gmail.com  Sun Jun 23 17:08:34 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Sun, 23 Jun 2019 18:08:34 -0300
Subject: [CMake] How do I get ExternalProject_Add to install libs/programs
 with sudo access
Message-ID: <83bc0777-fa3d-da8b-d0a8-4abbf0ab9cf7@gmail.com>

I am in the process of adding ExternalProject_Add commands to my program 
and I find them to work okay, except when they get to the install step.? 
Once they reach the install, they fail as they don't have super user 
access to install in /usr/local/, which is where I want them.

How do you work around this with ExternalProject_Add?


From cjw at ucar.edu  Sun Jun 23 17:31:01 2019
From: cjw at ucar.edu (Christopher Webster)
Date: Sun, 23 Jun 2019 15:31:01 -0600
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
Message-ID: <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>

On 6/23/19 9:22 AM, Alan W. Irwin wrote:
>
> There are a lot of different platforms that use the MinGW-w64 compiler
> so you should probably
> describe the platform where you are attempting to use that compiler in
> more detail.? For example,
> it sounds like you are simply taking a normal Window platform and
> downloading the
> MinGW-w64 compiler for that platform, but what is the exact URL for
> that download?

As Cristian surmised we use msys2/mingw64; we download from
www.msys2.org (the x86_64 option).? Then install the mingw64 toolchain,
and use mingw64 shells:

pacman -Sy msys2-devel
pacman -Sy mingw-w64-x86_64-toolchain
pacman -Sy base-devel
pacman -Sy mingw-w64-x86_64-check
pacman -Sy mingw-w64-x86_64-qt5
pacman -Sy mingw-w64-x86_64-qwt-qt5
pacman -Sy mingw-w64-x86_64-doxygen
pacman -Sy mingw-w64-x86_64-boost
pacman -Sy mingw-w64-x86_64-git-lfs
pacman -Sy mingw-w64-x86_64-gsl
pacman -Sy mingw-w64-x86_64-netcdf
pacman -Sy mingw-w64-x86_64-curl
pacman -Sy mingw-w64-x86_64-postgresql
pacman -Sy nano scons vim git procps

cmake was installed via:

pacman -Sy cmake


>
> I don't have any recent direct experience myself (I have no access to
> Microsoft Windows and Wine Windows bugs are currently blocking access
> to MSYS2), but PLplot developers I am aquainted with have recently had
> a lot of success with the [MSYS2
> platform](https://github.com/msys2/msys2/wiki) which is another exaple
> of a platform that uses the MinGW-w64 compiler.? For that platform
> they have found that "Unix Makefiles" and "MSYS Makefiles" generally
> give good results.? They haven't yet tried "MinGW Makefiles" but from
> my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2)
> experience for that generator you have to be sure that sh.exe is not
> on your PATH (e.g., by renaming it) before it will work.? (I have
> never quite been sure why that was a requirement, but my guess was the
> "mingw" make version acts differently if it detects sh.exe.)? But
> again from my ancient experience the rest of the Unix tools provided
> by MSYS2 including bash.exe will likely work well with the "MinGW
> Makefiles" generator.
>
> I hope this (ancient direct and recent indirect) practical experience
> with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and
> MinGW-w64 will be of some help to you.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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.org); 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 rubendibattista at gmail.com  Sun Jun 23 18:21:10 2019
From: rubendibattista at gmail.com (Ruben Di Battista)
Date: Mon, 24 Jun 2019 00:21:10 +0200
Subject: [CMake] How do I get ExternalProject_Add to install
 libs/programs with sudo access
In-Reply-To: <83bc0777-fa3d-da8b-d0a8-4abbf0ab9cf7@gmail.com>
References: <83bc0777-fa3d-da8b-d0a8-4abbf0ab9cf7@gmail.com>
Message-ID: <etPan.5d0ffb56.6f459e93.2941@gmail.com>

If I?m not mistaken, you should be able to change the install prefix using the CMAKE_ARGS option in the Configure step. This is my ExternalProject_Add I use to download third party stuff. Things enclosed by @ are replaced at configure time by correct names/URLs.?

```
ExternalProject_Add(
? ? @TP_PACKAGE_NAME@
? ? GIT_REPOSITORY @TP_PACKAGE_GIT_REPOSITORY@
? ? GIT_TAG "master"
? ? GIT_PROGRESS TRUE?
? ? UPDATE_COMMAND ${GIT_EXECUTABLE} pull
? ? LOG_DOWNLOAD ON
? ? LOG_CONFIGURE ON
? ? LOG_BUILD ON
? ? INSTALL_DIR "@TP_PACKAGE_INSTALL_DIR@"
? ? CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_CXX_FLAGS='-g'
)
```

          _   
-.     .?  |????
  ',  ;    |??????
    ??     |????????? RdB
    ,.,    |??????
  .'   '.  |????
-'       `?

https://rdb.is

On 23 June 2019 at 23:08:43, Gonzalo Garramu?o (ggarra13 at gmail.com) wrote:

I am in the process of adding ExternalProject_Add commands to my program  
and I find them to work okay, except when they get to the install step.?  
Once they reach the install, they fail as they don't have super user  
access to install in /usr/local/, which is where I want them.  

How do you work around this with ExternalProject_Add?  

--  

Powered by www.kitware.com  

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

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

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

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

Follow this link to subscribe/unsubscribe:  
https://cmake.org/mailman/listinfo/cmake  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190624/d86d057b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <https://cmake.org/pipermail/cmake/attachments/20190624/d86d057b/attachment.sig>

From hex7c3 at gmail.com  Sun Jun 23 18:26:45 2019
From: hex7c3 at gmail.com (hex)
Date: Sun, 23 Jun 2019 23:26:45 +0100
Subject: [CMake] install multiple versions of CMake on your system
Message-ID: <b0b6858c-167b-70d0-0c9a-453351d84972@gmail.com>

hello,

I'd like to install CMake under /usr/local/cmake/3.15/bin/ or similar.

Is it possible to add the version number to a build option, like 
-DCMAKE_INSTALL_PREFIX

or do I need to modify CMake sources?


thank you


From mellery451 at gmail.com  Sun Jun 23 19:58:31 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Sun, 23 Jun 2019 16:58:31 -0700
Subject: [CMake] install multiple versions of CMake on your system
In-Reply-To: <b0b6858c-167b-70d0-0c9a-453351d84972@gmail.com>
References: <b0b6858c-167b-70d0-0c9a-453351d84972@gmail.com>
Message-ID: <58221A01-0744-4A42-9FE8-5DDA6437516A@gmail.com>

If you are using the shell archive from cmake.org, it supports a ?prefix and ?exclude-subdir option, e.g.:

cd /tmp
CM_INSTALLER=cmake-3.14.0-Linux-x86_64.sh
CM_VER_DIR=/opt/local/cmake/3.14
wget https://cmake.org/files/v3.14/$CM_INSTALLER
chmod a+x $CM_INSTALLER
mkdir -p $CM_VER_DIR
./$CM_INSTALLER --prefix=$CM_VER_DIR --exclude-subdir
rm /tmp/$CM_INSTALLER

?or if you use the tar archive, you can similarly unpack it anywhere you like.

If you are building from source, I would assume CMAKE_INSTALL_PREFIX would be the way to go.

-Mike


> On Jun 23, 2019, at 3:26 PM, hex <hex7c3 at gmail.com> wrote:
> 
> hello,
> 
> I'd like to install CMake under /usr/local/cmake/3.15/bin/ or similar.
> 
> Is it possible to add the version number to a build option, like -DCMAKE_INSTALL_PREFIX
> 
> or do I need to modify CMake sources?
> 
> 
> thank you
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake


From ggarra13 at gmail.com  Sun Jun 23 21:44:16 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Sun, 23 Jun 2019 22:44:16 -0300
Subject: [CMake] How do I get ExternalProject_Add to install
 libs/programs with sudo access
In-Reply-To: <etPan.5d0ffb56.6f459e93.2941@gmail.com>
References: <83bc0777-fa3d-da8b-d0a8-4abbf0ab9cf7@gmail.com>
 <etPan.5d0ffb56.6f459e93.2941@gmail.com>
Message-ID: <994ef2f8-135e-f54b-8ebe-8ce473c051f3@gmail.com>


El 23/6/19 a las 19:21, Ruben Di Battista escribi?:
> If I?m not mistaken, you should be able to change the install prefix 
> using the CMAKE_ARGS option in the Configure step.
> ? ? CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_CXX_FLAGS='-g'

Thanks, Ruben.? I am familiar with this.? I was hoping to have a way of 
installing in /usr/local, by having cmake/ninja call a sudo ninja 
install and then leaving the terminal to type in the password.

But I guess this is not possible, and I'll have to install somewhere else.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190623/ba7c39e0/attachment.html>

From cmake at eikel.org  Mon Jun 24 01:46:10 2019
From: cmake at eikel.org (Benjamin Eikel)
Date: Mon, 24 Jun 2019 07:46:10 +0200
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
 <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
Message-ID: <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>

Dear Christopher,

Am 23. Juni 2019 23:31:01 MESZ schrieb Christopher Webster <cjw at ucar.edu>:
>On 6/23/19 9:22 AM, Alan W. Irwin wrote:
>>
>> There are a lot of different platforms that use the MinGW-w64
>compiler
>> so you should probably
>> describe the platform where you are attempting to use that compiler
>in
>> more detail.? For example,
>> it sounds like you are simply taking a normal Window platform and
>> downloading the
>> MinGW-w64 compiler for that platform, but what is the exact URL for
>> that download?
>
>As Cristian surmised we use msys2/mingw64; we download from
>www.msys2.org (the x86_64 option).? Then install the mingw64 toolchain,
>and use mingw64 shells:
>
>pacman -Sy msys2-devel
>pacman -Sy mingw-w64-x86_64-toolchain
>pacman -Sy base-devel
>pacman -Sy mingw-w64-x86_64-check
>pacman -Sy mingw-w64-x86_64-qt5
>pacman -Sy mingw-w64-x86_64-qwt-qt5
>pacman -Sy mingw-w64-x86_64-doxygen
>pacman -Sy mingw-w64-x86_64-boost
>pacman -Sy mingw-w64-x86_64-git-lfs
>pacman -Sy mingw-w64-x86_64-gsl
>pacman -Sy mingw-w64-x86_64-netcdf
>pacman -Sy mingw-w64-x86_64-curl
>pacman -Sy mingw-w64-x86_64-postgresql
>pacman -Sy nano scons vim git procps
>
>cmake was installed via:
>
>pacman -Sy cmake


try to install and use mingw-w64-x86_64-cmake in the mingw64 shell. Additionally, see this answer and the corresponding thread:
https://cmake.org/pipermail/cmake/2018-January/066869.html

Kind regards
Benjamin

>
>
>>
>> I don't have any recent direct experience myself (I have no access to
>> Microsoft Windows and Wine Windows bugs are currently blocking access
>> to MSYS2), but PLplot developers I am aquainted with have recently
>had
>> a lot of success with the [MSYS2
>> platform](https://github.com/msys2/msys2/wiki) which is another
>exaple
>> of a platform that uses the MinGW-w64 compiler.? For that platform
>> they have found that "Unix Makefiles" and "MSYS Makefiles" generally
>> give good results.? They haven't yet tried "MinGW Makefiles" but from
>> my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2)
>> experience for that generator you have to be sure that sh.exe is not
>> on your PATH (e.g., by renaming it) before it will work.? (I have
>> never quite been sure why that was a requirement, but my guess was
>the
>> "mingw" make version acts differently if it detects sh.exe.)? But
>> again from my ancient experience the rest of the Unix tools provided
>> by MSYS2 including bash.exe will likely work well with the "MinGW
>> Makefiles" generator.
>>
>> I hope this (ancient direct and recent indirect) practical experience
>> with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and
>> MinGW-w64 will be of some help to you.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> 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.org); 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:
>https://cmake.org/mailman/listinfo/cmake

From david.aldrich.ntml at gmail.com  Mon Jun 24 06:14:08 2019
From: david.aldrich.ntml at gmail.com (David Aldrich)
Date: Mon, 24 Jun 2019 11:14:08 +0100
Subject: [CMake] How to support separate debug and release build
 directories?
In-Reply-To: <FB914832-F6B4-4B75-AD1E-60D08646C57E@bluequartz.net>
References: <CAJK_iegoejadWP-C4E76Yw9ES=cpdqHoSgfhkWs0HUyLMsHFAg@mail.gmail.com>
 <dce32e585838ea595d0297e55691d4954c8f9d48.camel@endoframe.com>
 <CAJK_ieiNahRWj5Yi8zgyKOifMMyQf_rxK3g9aEyWFaY_D5FggA@mail.gmail.com>
 <7b2d439f47066596b5693479bf39737c543633d9.camel@endoframe.com>
 <CAJK_ieh3ETGr6n0DO3umMtnbRMf0v3TPBmrjWgtAL99NCvZ0aQ@mail.gmail.com>
 <FB914832-F6B4-4B75-AD1E-60D08646C57E@bluequartz.net>
Message-ID: <CAJK_iehNO=d66PwcrMr3qRj5ReT1pQ0KihJTbmFxdJOAAZVg9A@mail.gmail.com>

>
> David,
>
>     I think a bit more explanation of the philosophy (at least how I
> interpret it) is needed. I see in your emails that you are ?targeting
> makefiles?. With CMake you need to really stop thinking this way. Rarely do
> you need to target any specific build system (although those times do come
> up?). A lot of folks I see coming from autoconf to CMake still try to treat
> CMake in the same way. Don?t. There are a few golden rules with CMake that
> if you adhere to those will allow you to use CMake much easier.
>
>
>
> 1: NEVER have the Source directory and the Build directory be the same
> place.
>
> 2: PREFER out-of-source build directories (Not required but helpful)
>
> 3: Try not to target specific generators (makefiles, visual studio, xcode)
>
> <snip>
>

Hi Michael

Thanks very much for your reply and explanation. As a result, I now have
the separate Debug/Release build subdirectories working correctly.

Best regards

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190624/f7880dec/attachment.html>

From robert.maynard at kitware.com  Mon Jun 24 08:13:48 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 24 Jun 2019 08:13:48 -0400
Subject: [CMake] getting compiler's include paths
In-Reply-To: <CALU1LNwaixGaRpdmZBLQSR46k0D5K5GmwLLMpajF4qj7cbgf_w@mail.gmail.com>
References: <CALU1LNwaixGaRpdmZBLQSR46k0D5K5GmwLLMpajF4qj7cbgf_w@mail.gmail.com>
Message-ID: <CAFzjYVo4O3vNrHQ9SR0DxdKm2-XM+U3uD34m0X2Q_zWfNkuK7A@mail.gmail.com>

It look that starting with CMake 3.6 modification of system headers
will cause CMake to recompile projects. What version of CMake and your
compiler are you using?

On Mon, Jun 17, 2019 at 9:40 AM jl forums <jlmxyz.forums at gmail.com> wrote:
>
> Hi,
> I want to create a full tag file and for this require to know the compiler full include path...  there is a way to had custom includes path but didn't found any variables for the include path....
> for example :
> $ gcc-8 -v -x c -E /dev/null
> Using built-in specs.
> [....]
> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc/x86_64-linux-gnu/8/include
>  /usr/local/include
>  /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
>  /usr/x86_64-linux-gnu/include
>  /usr/include/x86_64-linux-gnu
>  /usr/include
> End of search list.
> [...]
>
> $ gcc -v -x c -E /dev/null
> Using built-in specs.
> [...]
> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc/x86_64-linux-gnu/7/include
>  /usr/local/include
>  /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
>  /usr/x86_64-linux-gnu/include
>  /usr/include/x86_64-linux-gnu
>  /usr/include
> End of search list.
> [...]
>
> I tried to
>
>
> get_target_property(moggle_interface_includes FileSync INTERFACE_INCLUDE_DIRECTORIES)
> message("Moggle interface includes: ${moggle_interface_includes}")
>
> get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES)
> message("MOTOR includes ${motor_includes}")
>
> but I get
>
> Moggle interface includes: moggle_interface_includes-NOTFOUND
> MOTOR includes motor_includes-NOTFOUND
>
>
> there is also some issue because cmake strip dependencies from system's include, which means that updating a system software won't cause rebuild and consider that the build is uptodate, causing unexpected results
> seems that there is ways to workaround this :  https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake but this is ugly... would be better to let the user choose with an option
>
> thanks and regards
> JLM
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From cjw at ucar.edu  Mon Jun 24 09:39:41 2019
From: cjw at ucar.edu (Christopher Webster)
Date: Mon, 24 Jun 2019 07:39:41 -0600
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
 <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
 <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>
Message-ID: <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>

Thank you Benjamin, that fixed it.? Now to figure out the cpack.d error.

Is there a way to search the archives?? I had looked through the last
several months of threads, but that is not practical for searching back
a over a year

Chris


On 6/23/19 11:46 PM, Benjamin Eikel wrote:
> Dear Christopher,
>
> Am 23. Juni 2019 23:31:01 MESZ schrieb Christopher Webster <cjw at ucar.edu>:
>> On 6/23/19 9:22 AM, Alan W. Irwin wrote:
>>> There are a lot of different platforms that use the MinGW-w64
>> compiler
>>> so you should probably
>>> describe the platform where you are attempting to use that compiler
>> in
>>> more detail.? For example,
>>> it sounds like you are simply taking a normal Window platform and
>>> downloading the
>>> MinGW-w64 compiler for that platform, but what is the exact URL for
>>> that download?
>> As Cristian surmised we use msys2/mingw64; we download from
>> www.msys2.org (the x86_64 option).? Then install the mingw64 toolchain,
>> and use mingw64 shells:
>>
>> pacman -Sy msys2-devel
>> pacman -Sy mingw-w64-x86_64-toolchain
>> pacman -Sy base-devel
>> pacman -Sy mingw-w64-x86_64-check
>> pacman -Sy mingw-w64-x86_64-qt5
>> pacman -Sy mingw-w64-x86_64-qwt-qt5
>> pacman -Sy mingw-w64-x86_64-doxygen
>> pacman -Sy mingw-w64-x86_64-boost
>> pacman -Sy mingw-w64-x86_64-git-lfs
>> pacman -Sy mingw-w64-x86_64-gsl
>> pacman -Sy mingw-w64-x86_64-netcdf
>> pacman -Sy mingw-w64-x86_64-curl
>> pacman -Sy mingw-w64-x86_64-postgresql
>> pacman -Sy nano scons vim git procps
>>
>> cmake was installed via:
>>
>> pacman -Sy cmake
>
> try to install and use mingw-w64-x86_64-cmake in the mingw64 shell. Additionally, see this answer and the corresponding thread:
> https://cmake.org/pipermail/cmake/2018-January/066869.html
>
> Kind regards
> Benjamin
>



From volker.enderlein at ifm-chemnitz.de  Mon Jun 24 10:03:11 2019
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Mon, 24 Jun 2019 16:03:11 +0200
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
 <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
 <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>
 <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>
Message-ID: <8a67bc2e-b4e4-24ca-ed77-1de762ae42e3@ifm-chemnitz.de>

Am 24.06.2019 um 15:39 schrieb Christopher Webster:

Hi Christopher,

did you followed the instructions from 
https://bitbucket.org/Coin3D/coin/wiki/BuildWithCMake
and cloned the repo, e.g. ran hg clone https://bitbucket.org/Coin3D/coin 
coin ?

As coin uses subrepositories the Download the compressed sources from 
the Download section does not work. The subrepos won't be populated.

Cheers Volker
> Thank you Benjamin, that fixed it.? Now to figure out the cpack.d error.
>
> Is there a way to search the archives?? I had looked through the last
> several months of threads, but that is not practical for searching back
> a over a year
>
> Chris
>

-- 


From cjw at ucar.edu  Mon Jun 24 10:42:06 2019
From: cjw at ucar.edu (Christopher Webster)
Date: Mon, 24 Jun 2019 08:42:06 -0600
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <8a67bc2e-b4e4-24ca-ed77-1de762ae42e3@ifm-chemnitz.de>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
 <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
 <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>
 <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>
 <8a67bc2e-b4e4-24ca-ed77-1de762ae42e3@ifm-chemnitz.de>
Message-ID: <8c6fc525-7976-28c6-7559-ee3a74649eed@ucar.edu>

On 6/24/19 8:03 AM, Volker Enderlein wrote:
> Am 24.06.2019 um 15:39 schrieb Christopher Webster:
>
> Hi Christopher,
>
> did you followed the instructions from
> https://bitbucket.org/Coin3D/coin/wiki/BuildWithCMake
> and cloned the repo, e.g. ran hg clone
> https://bitbucket.org/Coin3D/coin coin ?
>
> As coin uses subrepositories the Download the compressed sources from
> the Download section does not work. The subrepos won't be populated.

Hi Volker,

I am following the instructions at the wiki page you listed above and
used hg(1) to download.? Their example is for Visual Studio Generator.?
I am wading through MinGW vs. MSYS for generator.? MinGW complains the
sh.exe is in my path and MSYS errors out with a cpack.d error.? Though I
suspect I want the MinGW.

I did get the Coin3D going on MacOS, and Quarter (though
Quarter.framework installed kind of funny, so working through that also).

Thanks,
Chris


From volker.enderlein at ifm-chemnitz.de  Mon Jun 24 11:10:12 2019
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Mon, 24 Jun 2019 17:10:12 +0200
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <8c6fc525-7976-28c6-7559-ee3a74649eed@ucar.edu>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
 <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
 <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>
 <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>
 <8a67bc2e-b4e4-24ca-ed77-1de762ae42e3@ifm-chemnitz.de>
 <8c6fc525-7976-28c6-7559-ee3a74649eed@ucar.edu>
Message-ID: <54de2b6e-25e2-ac30-36dd-78ef019c9520@ifm-chemnitz.de>

Am 24.06.2019 um 16:42 schrieb Christopher Webster:
> On 6/24/19 8:03 AM, Volker Enderlein wrote:
>> Am 24.06.2019 um 15:39 schrieb Christopher Webster:
>>
>> Hi Christopher,
>>
>> did you followed the instructions from
>> https://bitbucket.org/Coin3D/coin/wiki/BuildWithCMake
>> and cloned the repo, e.g. ran hg clone
>> https://bitbucket.org/Coin3D/coin coin ?
>>
>> As coin uses subrepositories the Download the compressed sources from
>> the Download section does not work. The subrepos won't be populated.
> Hi Volker,
>
> I am following the instructions at the wiki page you listed above and
> used hg(1) to download.? Their example is for Visual Studio Generator.
> I am wading through MinGW vs. MSYS for generator.? MinGW complains the
> sh.exe is in my path and MSYS errors out with a cpack.d error.? Though I
> suspect I want the MinGW.
>
> I did get the Coin3D going on MacOS, and Quarter (though
> Quarter.framework installed kind of funny, so working through that also).
>
> Thanks,
> Chris
>
Hi Chris,


you might also open an issue on the Coin issue tracker for that cpack.d 
problem (or for your entire build issue).

As the framework option on macOS is not very well tested I would 
recommend to use the plain ole dylib approach. That is known to work for 
Coin, SoQt, SoXt and Quarter. Recently the default setting to build a 
framework on macOS has been changed for Coin3D as it is still being 
considered experimental. You may check the last few commit messages.


Cheers, Volker



From tadej.panjtar at gmail.com  Mon Jun 24 12:44:04 2019
From: tadej.panjtar at gmail.com (Tadej Panjtar)
Date: Mon, 24 Jun 2019 18:44:04 +0200
Subject: [CMake] Statically linking with MFC VS2019
Message-ID: <CAF315RWaPOqS4MQDSskNnYfs753NU1e0Sp4gmaaTL1kH4eaivw@mail.gmail.com>

Hello!

In CMakeLists.txt i have:
set(CMAKE_MFC_FLAG 1)
add_executable(executable WIN32 sources...)

When i open the solution, there is in general properties of executable
there is wrong set "Use of MFC": "Use Standard Windows Libraries" instead
of "Use MFC in a Static Library"

What else should i have to set?

I am using cmake-3.15.0-rc2-win32-x86 version of cmake.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190624/c16ab4c0/attachment.html>

From Alan.W.Irwin1234 at gmail.com  Mon Jun 24 18:06:51 2019
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Mon, 24 Jun 2019 15:06:51 -0700 (PDT)
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
 <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
 <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>
 <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>
Message-ID: <nycvar.QRO.7.76.1906241444270.27571@zreyva.zlyna.ubzr>

On 2019-06-24 07:39-0600 Christopher Webster wrote:

> Thank you Benjamin, that [install and use mingw-w64-x86_64-cmake in the mingw64 shell] fixed it.

I was happy to hear that Benjamin solved this first issue for you.

Just to follow up on what he said, I confirm the good PLplot results
for the MSYS2 platform that I referred to in my previous post also
used the "mingw-w64-x86_64-cmake" native package rather than the
non-native (linked to msys2.dll) "cmake" package.

You (and others reading this thread) should consult the patches at
<https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-cmake>
to see the various ways that the "mingw-w64-x86_64-cmake" package
differs from vanilla cmake for Windows from Kitware.  I agree with
another poster's comments that if indeed some or all of those fixes
are really necessary for the MSYS2 platform that ideally they should
be adopted by the upstream CMake developers.  So I hope those
developers are (i) reading this thread and (ii) willing to follow up
by looking at those patches.

Alan
__________________________
Alan W. Irwin

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.org); 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 smeenai at fb.com  Mon Jun 24 18:16:44 2019
From: smeenai at fb.com (Shoaib Meenai)
Date: Mon, 24 Jun 2019 22:16:44 +0000
Subject: [CMake] Multiple exports for a target installation
In-Reply-To: <CA+dygYmG2M+TJsfUba5aDnZdR5_VKXD0Tdhrzm2etxHbRUcffQ@mail.gmail.com>
References: <C739DF5E-E0DE-41C6-B6CF-25F23FE12FDF@fb.com>
 <CA+dygYk+OPb8MJQbQd1QRNSKQMCVaRbowSCVZepn-2Ejna9g4Q@mail.gmail.com>
 <8C4B0CF6-5C86-43C8-8C8A-E21C37EDB51A@fb.com>
 <CA+dygYmG2M+TJsfUba5aDnZdR5_VKXD0Tdhrzm2etxHbRUcffQ@mail.gmail.com>
Message-ID: <2CA45677-1E74-4B57-BACF-FC097C3CD88F@fb.com>

Thank you for the detailed explanation! That?s really helpful and gives me a much better sense of how to think about and structure this :)

From: Craig Scott <craig.scott at crascit.com>
Date: Saturday, June 22, 2019 at 12:18 AM
To: Shoaib Meenai <smeenai at fb.com>
Cc: "cmake at cmake.org" <cmake at cmake.org>
Subject: Re: [CMake] Multiple exports for a target installation



On Tue, Jun 18, 2019 at 10:29 AM Shoaib Meenai <smeenai at fb.com<mailto:smeenai at fb.com>> wrote:
Thank you!

When you say having an export set that the other exports then depend on, do you mean the COMPONENT option of the install(EXPORT) signature, or something else? (Sadly the project I?m working with is still on CMake 3.4.3, whose documentation says something very different for the COMPONENT option than the latest version, but I?ll cross that bridge when I get to it.)

As far as components and export sets are concerned, the behavior isn't much different between CMake 3.4 and 3.14. Think of it like this:

  *   The config file for a package (i.e. its <packageName>Config.cmake file) may refer to one or more export sets. It can do this in a way that some or all of the export sets are optional, pulling them in if present, silently continuing if not. It depends on the way the project wants to define and use its export sets. For most projects, they will require all export sets they refer to to be present. The optional components of a find_package() call might map to optional export sets (just one example of how optional export sets might be used).
  *   An export set defines targets. That set of targets can span across one or more components. The export set requires all of those components to be installed/present or it is considered ill-formed (or put another way, the installation is incomplete). The install(TARGETS ... EXPORT ...) command determines what targets are in which export set. The install(EXPORT ...) command defines what component the actual export file is part of (further discussion on this below).
  *   A component can include targets, files and custom scripts to be invoked when installing that component from a build tree. Targets and files can technically be part of multiple components, but this would be relatively uncommon and may complicate the export picture. A component may depend on one or more other components, e.g. a Development component may require a Runtime component, such as Development headers requiring the Runtime shared library.
If a project decides to split up its exports across multiple export sets, there can be dependencies between them. For example, a project might define export set Algo which has components Fast and Accurate, and export set Apps which has components Gui and CLI. The project's <packageName>Config.cmake file requires the Algo export set to be present but the Apps export set is optional and only pulled in if present. In this scenario, one might have the Fast and Accurate components installed, but not the Gui or CLI components. The Algo export set represents the mandatory parts of the package that will always be needed. The Gui and CLI components might not be installed if, for example, someone just wants to build against the libraries provided by the Fast and Accurate components (i.e. they are writing their own apps rather than wanting to use the apps that are provided by the Gui and CLI components).

What can be a bit confusing is that the exported file itself is also part of a component. That exported file might or might not need to be installed, depending on whether the project is being distributed as purely runtime components or whether other projects might be building against it and therefore expect headers, package config files, etc. The exported file (which is installed by install(EXPORT ...) ) is only needed for the latter, so it is usually part of a Development component or something similarly named (hopefully named something project-specific rather than just a generic "Development"!). The <packageName>Config.cmake file is also part of a component, and may be part of the same component that the export file is in.

The above is how I think about packages, export sets and components. You could have more complicated arrangements and have some overlap between export sets, but I'd generally try to avoid that if possible. It's simpler if you can structure things with clear and unambiguous dependencies without cycles or overlaps. It's already quite involved even without those things!

HTH



From: Craig Scott <craig.scott at crascit.com<mailto:craig.scott at crascit.com>>
Date: Saturday, June 15, 2019 at 10:43 PM
To: Shoaib Meenai <smeenai at fb.com<mailto:smeenai at fb.com>>
Cc: "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: Re: [CMake] Multiple exports for a target installation



On Sat, Jun 15, 2019 at 9:03 PM Shoaib Meenai <smeenai at fb.com<mailto:smeenai at fb.com>> wrote:
Is it possible to associate a target with multiple exports? For example, if I'm building a project where I want to create multiple export sets, but there's some overlap in targets between those sets. I tried passing multiple EXPORT options to the install(TARGETS) signature but I just got an error: install TARGETS given unknown argument "EXPORT".

Typically, you'd want your export sets to not be overlapping and to contain no cyclic dependencies. If you have a target in multiple export sets, it suggests that you probably should factor out that target to a separate export set that other exports then depend on. That said, if you have a scenario that legitimately requires a target in multiple export sets, then you would need to use multiple install() commands to achieve this, specifying a different export set for each one.

--
Craig Scott
Melbourne, Australia
https://crascit.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__crascit.com&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=fbTRNztVUYoZQ3jWMZDCnjUkgyIkIY3oKUOcoSHtJhU&s=D8L2FOhY6A090QgEuF3TlSRsaoWmXEMMvLkZGqKyn60&e=>

Get the hand-book for every CMake user: Professional CMake: A Practical Guide<https://urldefense.proofpoint.com/v2/url?u=https-3A__crascit.com_professional-2Dcmake_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=fbTRNztVUYoZQ3jWMZDCnjUkgyIkIY3oKUOcoSHtJhU&s=sgkIsOcB05bpz9VPxJm34J7is5oYnwNtGYWQkbvYzuE&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190624/779c6dd1/attachment-0001.html>

From mingw.android at gmail.com  Tue Jun 25 06:16:33 2019
From: mingw.android at gmail.com (Ray Donnelly)
Date: Tue, 25 Jun 2019 12:16:33 +0200
Subject: [CMake] cmake on MinGW64; which generator
In-Reply-To: <nycvar.QRO.7.76.1906241444270.27571@zreyva.zlyna.ubzr>
References: <82369415-b262-d038-25f5-bc6f8a724f7c@ucar.edu>
 <nycvar.QRO.7.76.1906230746090.27571@zreyva.zlyna.ubzr>
 <75a0d49a-f5d0-9170-9bec-ee42379669af@ucar.edu>
 <769B21AF-BCAF-4939-BFCE-48155451DB4B@eikel.org>
 <8ceea72c-8f18-f1ad-fa4e-b2e728b3e65b@ucar.edu>
 <nycvar.QRO.7.76.1906241444270.27571@zreyva.zlyna.ubzr>
Message-ID: <CAOYw7duSyEEDsiiRnffZYvzo_Y6N-f_c_RDaJhiu7L8W4rH-Xg@mail.gmail.com>

The problem is the time required to upstream such work. Unfortunately I do
not have that time.

On Tue, Jun 25, 2019, 12:15 AM Alan W. Irwin <Alan.W.Irwin1234 at gmail.com>
wrote:

> On 2019-06-24 07:39-0600 Christopher Webster wrote:
>
> > Thank you Benjamin, that [install and use mingw-w64-x86_64-cmake in the
> mingw64 shell] fixed it.
>
> I was happy to hear that Benjamin solved this first issue for you.
>
> Just to follow up on what he said, I confirm the good PLplot results
> for the MSYS2 platform that I referred to in my previous post also
> used the "mingw-w64-x86_64-cmake" native package rather than the
> non-native (linked to msys2.dll) "cmake" package.
>
> You (and others reading this thread) should consult the patches at
> <https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-cmake>
> to see the various ways that the "mingw-w64-x86_64-cmake" package
> differs from vanilla cmake for Windows from Kitware.  I agree with
> another poster's comments that if indeed some or all of those fixes
> are really necessary for the MSYS2 platform that ideally they should
> be adopted by the upstream CMake developers.  So I hope those
> developers are (i) reading this thread and (ii) willing to follow up
> by looking at those patches.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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.org); 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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190625/ebe16924/attachment.html>

From erkam.murat.bozkurt at gmail.com  Wed Jun 26 08:34:01 2019
From: erkam.murat.bozkurt at gmail.com (Erkam Murat Bozkurt)
Date: Wed, 26 Jun 2019 15:34:01 +0300
Subject: [CMake] About PCYNLITX project and its innovations ( for C+++
 multi-threading )
Message-ID: <CA+oH3ZPdVEyiT-JyHfwEjuPcTsUArdYqgFczncCo7J--OnMk=g@mail.gmail.com>

Previously, I have presented my project to you. The current name of my
project is PCYNLITX.

PCYNLITX platform offers completely new programming technology which can be
named as Programmable Meta-Programming System and PCYNLITX platform is just
a particular application of this new programming methodology.

Basically, PCYNLITX is an intelligent integrated development environment (
IDE ) which can produce an application-specific multi-threading library
based on your needs and assists you in multi-thread software development
process. PCYNLITX is not a multi-threading library. Instead, it is a
multi-threading library generator. You can find out very comprehensive
documentation about pcynlitx project from both project web site and source
code repository. The addresses of the project web page and source code
repository are given in below links.

www.pcynlitx.tech

https://sourceforge.net/projects/pcynlitx

The outcome of the PCYNLITX platform acts as an autonomous thread
management system provides deterministic scheduling of the threads. You can
control the thread with the numbers given by you and determine the relation
of the threads. In other words, different from the other multi-threading
tools, you can directly schedule the threads independently from the
operating system.

The scientific journal of the project is under review on IEEE Transactions
on Software Engineering.

Currently, the PCYNLITX platform only works on Linux based operating
systems and the other versions ( Windows and McOSx ) are under development.
The License of the PCYNLITX platform is GNU GPLv3 Free Software License. You
can find out many other documents including scientific introduction of the
project (?Technical Introduction? ), code examples and GUI tutorial form
the project web sites. You can also find out a documents introducing
std::thread programming, pthread programming and OpenMP programming on the
web sites.

I am always waiting your valuable comments and contributions.

Thanks and best regards.

Erkam Murat Bozkurt

M.Sc in Control Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190626/812473e6/attachment.html>

From Torsten at Robitzki.de  Wed Jun 26 09:53:16 2019
From: Torsten at Robitzki.de (Torsten Robitzki)
Date: Wed, 26 Jun 2019 15:53:16 +0200
Subject: [CMake] Embedded build using ExternalProject
Message-ID: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>

Hello,

I have a project, where binaries are build for an embedded platform and for a PC platform. To build software update packages for the embedded platforms (files that can be used to make in the field firmware updates), tools that have to run during the build have to be build from source first. For example firmware.tfp have to be build by running create_package with firmware.bin. firmware.bin have to build with settings for the embedded platform and create_package have to be build with setting of the build host.

I?ve asked this question already a year or so ago and got the response, that using super builds will help me. Now I try to convert the project to a super build structure. Fortunately, there was very little content inside my main CMakeLists.txt, mainly `add_subdirectory( source )`. Mainly, I want to build different sets of artifacts from the same source tree, but with different

Now I?m stuck with a number of issues. First, I want to build all firmware binaries for the NRF52 embedded platform:

    ExternalProject_Add(firmware_binaries
        SOURCE_DIR  ${CMAKE_CURRENT_LIST_DIR}/source
        INSTALL_DIR ${installDir}
        CMAKE_ARGS
            -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
            -DBOOTLOADER_AES_KEY=${BOOTLOADER_AES_KEY}
            -DBOOTLOADER_VERSION=${BOOTLOADER_VERSION}
            -DBUILD_DEBUG=1
            -DBUILD_NRF52=1
        BUILD_COMMAND ${CMAKE_COMMAND} --build ${CMAKE_CURRENT_BINARY_DIR} --target firmware_binaries
    )

I don?t want to build any EOL test firmware, test-tools etc. just the stuff that will be shipped, thus the explicit target. I can build the firmware_binaries, from the source directly, without problems. But when I try to build with the top-level cmake file, that contains the ExternalProject_Add(), I get the usual configure output and then:

-- Configuring done
-- Generating done
-- Build files have been written to: /Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build
[ 75%] Performing build step for 'firmware_binaries'
[ 12%] Performing build step for 'firmware_binaries'
[ 12%] Performing build step for 'firmware_binaries'
[ 12%] Performing build step for ?firmware_binaries?
?

This line repeats until make reports:

make[776]: /usr/local/Cellar/cmake/3.14.3/bin/cmake: Resource temporarily unavailable
make[776]: *** wait: No child processes.  Stop.
make[776]: *** Waiting for unfinished jobs....
make[776]: *** wait: No child processes.  Stop.

Any idea, what might be wrong here? Some kind of recursion?

An other issue: I want to forward targets to the super build, so that I can build them there. For example I have ~30 unit test programs and when I?m working in a certain area, I usually want to build exactly one of this programs. Is it possible to export them as targets of the super build?

A third issue that I have is, that changes to the CMakeLists.txt files in the Project are not reflected by the super build. If I make a change to one of the CMake files under ${CMAKE_CURRENT_LIST_DIR}/source, I usually have to delete the whole build folder and start from scratch with the build. Is there an other way to force the super build to recognize the changes? (Note: ${CMAKE_CURRENT_LIST_DIR}/source is not added as subdirectory to the top level (super build) CMakeLists.txt).

best regards,

Torsten

P.S.:
$ cmake --version
cmake version 3.14.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190626/ec95342b/attachment.sig>

From AlbrechtS.fltk at online.de  Wed Jun 26 13:10:48 2019
From: AlbrechtS.fltk at online.de (Albrecht Schlosser)
Date: Wed, 26 Jun 2019 19:10:48 +0200
Subject: [CMake] Embedded build using ExternalProject
In-Reply-To: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
References: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
Message-ID: <5ba97787-30a6-0313-54ea-0fd18b63ef04@online.de>

On 6/26/19 3:53 PM Torsten Robitzki wrote:

> I don?t want to build any EOL test firmware, test-tools etc. just the stuff that will be shipped, thus the explicit target. I can build the firmware_binaries, from the source directly, without problems. But when I try to build with the top-level cmake file, that contains the ExternalProject_Add(), I get the usual configure output and then:
> 
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build

Is this a on a Windows system?

Are you maybe using Cygwin or MinGW?

> [ 75%] Performing build step for 'firmware_binaries'
> [ 12%] Performing build step for 'firmware_binaries'
> [ 12%] Performing build step for 'firmware_binaries'
> [ 12%] Performing build step for ?firmware_binaries?
> ?
> 
> This line repeats until make reports:
> 
> make[776]: /usr/local/Cellar/cmake/3.14.3/bin/cmake: Resource temporarily unavailable
> make[776]: *** wait: No child processes.  Stop.
> make[776]: *** Waiting for unfinished jobs....
> make[776]: *** wait: No child processes.  Stop.
> 
> Any idea, what might be wrong here? Some kind of recursion?

"Resource temporarily unavailable" looks like a well-known Cygwin (or 
maybe also MinGW) issue. If both of your answers above is "yes" I'd 
guess it is.

As a workaround you may try to use 'make -j1' or something like this to 
reduce the number of concurrent make jobs, but this is only a guess.

From Torsten at Robitzki.de  Wed Jun 26 13:38:29 2019
From: Torsten at Robitzki.de (Torsten Robitzki)
Date: Wed, 26 Jun 2019 19:38:29 +0200
Subject: [CMake] Embedded build using ExternalProject
In-Reply-To: <5ba97787-30a6-0313-54ea-0fd18b63ef04@online.de>
References: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
 <5ba97787-30a6-0313-54ea-0fd18b63ef04@online.de>
Message-ID: <12DF4530-FD4D-410D-B3BE-46A949FBA732@Robitzki.de>

Hi Albrecht,

> Am 26.06.2019 um 19:10 schrieb Albrecht Schlosser <AlbrechtS.fltk at online.de>:
> 
> On 6/26/19 3:53 PM Torsten Robitzki wrote:
> 
>> I don?t want to build any EOL test firmware, test-tools etc. just the stuff that will be shipped, thus the explicit target. I can build the firmware_binaries, from the source directly, without problems. But when I try to build with the top-level cmake file, that contains the ExternalProject_Add(), I get the usual configure output and then:
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build
> 
> Is this a on a Windows system?

No, my build host is a Mac. I figured out, what the problem with this recusion is:

  BUILD_COMMAND ${CMAKE_COMMAND} ?build ${CMAKE_CURRENT_BINARY_DIR} --target firmware_binaries

The build command really recuses into ${CMAKE_CURRENT_BINARY_DIR}, which have to be:

  BUILD_COMMAND ${CMAKE_COMMAND} ?build <BINARY_DIR> --target firmware_packages

:-)





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190626/e371177f/attachment.sig>

From post at hendrik-sattler.de  Wed Jun 26 14:07:20 2019
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 26 Jun 2019 20:07:20 +0200
Subject: [CMake] Embedded build using ExternalProject
In-Reply-To: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
References: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
Message-ID: <07D88FEE-6A86-46C1-98A2-E49B9716FC87@hendrik-sattler.de>



Am 26. Juni 2019 15:53:16 MESZ schrieb Torsten Robitzki <Torsten at Robitzki.de>:
>Hello,
>
>I have a project, where binaries are build for an embedded platform and
>for a PC platform. To build software update packages for the embedded
>platforms (files that can be used to make in the field firmware
>updates), tools that have to run during the build have to be build from
>source first. For example firmware.tfp have to be build by running
>create_package with firmware.bin. firmware.bin have to build with
>settings for the embedded platform and create_package have to be build
>with setting of the build host.
>
>I?ve asked this question already a year or so ago and got the response,
>that using super builds will help me. Now I try to convert the project
>to a super build structure. Fortunately, there was very little content
>inside my main CMakeLists.txt, mainly `add_subdirectory( source )`.
>Mainly, I want to build different sets of artifacts from the same
>source tree, but with different
>
>Now I?m stuck with a number of issues. First, I want to build all
>firmware binaries for the NRF52 embedded platform:
>
>    ExternalProject_Add(firmware_binaries
>        SOURCE_DIR  ${CMAKE_CURRENT_LIST_DIR}/source
>        INSTALL_DIR ${installDir}
>        CMAKE_ARGS
>            -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
>            -DBOOTLOADER_AES_KEY=${BOOTLOADER_AES_KEY}
>            -DBOOTLOADER_VERSION=${BOOTLOADER_VERSION}
>            -DBUILD_DEBUG=1
>            -DBUILD_NRF52=1
>BUILD_COMMAND ${CMAKE_COMMAND} --build ${CMAKE_CURRENT_BINARY_DIR}
>--target firmware_binaries
>    )

The build command is using the wrong directory.

>I don?t want to build any EOL test firmware, test-tools etc. just the
>stuff that will be shipped, thus the explicit target. I can build the
>firmware_binaries, from the source directly, without problems. But when
>I try to build with the top-level cmake file, that contains the
>ExternalProject_Add(), I get the usual configure output and then:
>
>-- Configuring done
>-- Generating done
>-- Build files have been written to:
>/Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build
>[ 75%] Performing build step for 'firmware_binaries'
>[ 12%] Performing build step for 'firmware_binaries'
>[ 12%] Performing build step for 'firmware_binaries'
>[ 12%] Performing build step for ?firmware_binaries?
>?
>
>This line repeats until make reports:
>
>make[776]: /usr/local/Cellar/cmake/3.14.3/bin/cmake: Resource
>temporarily unavailable
>make[776]: *** wait: No child processes.  Stop.
>make[776]: *** Waiting for unfinished jobs....
>make[776]: *** wait: No child processes.  Stop.
>
>Any idea, what might be wrong here? Some kind of recursion?
>
>An other issue: I want to forward targets to the super build, so that I
>can build them there. For example I have ~30 unit test programs and
>when I?m working in a certain area, I usually want to build exactly one
>of this programs. Is it possible to export them as targets of the super
>build?
>
>A third issue that I have is, that changes to the CMakeLists.txt files
>in the Project are not reflected by the super build. If I make a change
>to one of the CMake files under ${CMAKE_CURRENT_LIST_DIR}/source, I
>usually have to delete the whole build folder and start from scratch
>with the build. Is there an other way to force the super build to
>recognize the changes? (Note: ${CMAKE_CURRENT_LIST_DIR}/source is not
>added as subdirectory to the top level (super build) CMakeLists.txt).
>
>best regards,
>
>Torsten
>
>P.S.:
>$ cmake --version
>cmake version 3.14.3

From Torsten at Robitzki.de  Wed Jun 26 16:55:39 2019
From: Torsten at Robitzki.de (Torsten at Robitzki.de)
Date: Wed, 26 Jun 2019 22:55:39 +0200
Subject: [CMake] Embedded build using ExternalProject
In-Reply-To: <07D88FEE-6A86-46C1-98A2-E49B9716FC87@hendrik-sattler.de>
References: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
 <07D88FEE-6A86-46C1-98A2-E49B9716FC87@hendrik-sattler.de>
Message-ID: <92944E2A-43F4-4357-AAA8-46E04E4AB977@Robitzki.de>



> Am 26.06.2019 um 20:07 schrieb Hendrik Sattler <post at hendrik-sattler.de>:
> 
>>   ExternalProject_Add(firmware_binaries
>>       SOURCE_DIR  ${CMAKE_CURRENT_LIST_DIR}/source
>>       INSTALL_DIR ${installDir}
>>       CMAKE_ARGS
>>           -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
>>           -DBOOTLOADER_AES_KEY=${BOOTLOADER_AES_KEY}
>>           -DBOOTLOADER_VERSION=${BOOTLOADER_VERSION}
>>           -DBUILD_DEBUG=1
>>           -DBUILD_NRF52=1
>> BUILD_COMMAND ${CMAKE_COMMAND} --build ${CMAKE_CURRENT_BINARY_DIR}
>> --target firmware_binaries
>>   )
> 
> The build command is using the wrong directory.

Yes, thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190626/a70f8c37/attachment.sig>

From doenges at mvtec.com  Thu Jun 27 07:06:36 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Thu, 27 Jun 2019 13:06:36 +0200
Subject: [CMake] Embedded build using ExternalProject
In-Reply-To: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
References: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
Message-ID: <4ee63189-262c-b17e-77a6-ddb53399c6be@mvtec.com>


Am 26.06.19 um 15:53 schrieb Torsten Robitzki:
> A third issue that I have is, that changes to the CMakeLists.txt files in the Project are not reflected by the super build. If I make a change to one of the CMake files under ${CMAKE_CURRENT_LIST_DIR}/source, I usually have to delete the whole build folder and start from scratch with the build. Is there an other way to force the super build to recognize the changes? (Note: ${CMAKE_CURRENT_LIST_DIR}/source is not added as subdirectory to the top level (super build) CMakeLists.txt).

I can't help you with your other issues, but I believe the solution to 
this problem is to specify "BUILD_ALWAYS TRUE" in your 
ExternalProject_Add. From the documentation for ExternalProject_Add:

Enabling this option forces the build step to always be run. This can be 
the easiest way to robustly ensure that the external project?s own build 
dependencies are evaluated rather than relying on the default success 
timestamp-based method. This option is not normally needed unless 
developers are expected to modify something the external project?s build 
depends on in a way that is not detectable via the step target 
dependencies (e.g. |SOURCE_DIR| is used without a download method and 
developers might modify the sources in |SOURCE_DIR|).

-- 

*Dr. Eric D?nges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doenges at mvtec.com <mailto:doenges at mvtec.com> | Tel: +49 89 457 695-0 | 
www.mvtec.com <http://www.mvtec.com>

Sign up <http://www.mvtec.com/newsletter> for our MVTec Newsletter!

Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht M?nchen HRB 114695

MVTec Software GmbH Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190627/f905ce73/attachment.html>

From jlmxyz.forums at gmail.com  Thu Jun 27 08:59:13 2019
From: jlmxyz.forums at gmail.com (jl forums)
Date: Thu, 27 Jun 2019 14:59:13 +0200
Subject: [CMake] getting compiler's include paths
In-Reply-To: <CAFzjYVo4O3vNrHQ9SR0DxdKm2-XM+U3uD34m0X2Q_zWfNkuK7A@mail.gmail.com>
References: <CALU1LNwaixGaRpdmZBLQSR46k0D5K5GmwLLMpajF4qj7cbgf_w@mail.gmail.com>
 <CAFzjYVo4O3vNrHQ9SR0DxdKm2-XM+U3uD34m0X2Q_zWfNkuK7A@mail.gmail.com>
Message-ID: <CALU1LNw-B3MsFC8mUSWJcvJVDyzh3G7OGum+_qX3kcEfU1ZLhw@mail.gmail.com>

thanks for the anwer....
quite not... I'm using cmake 3.14.2 (so, far away from 3.6....) and have a
look, in main.cpp, there is #include <filesystem>:

$ find /usr/include/ -name filesystem
/usr/include/c++/5/experimental/filesystem
/usr/include/c++/7/experimental/filesystem
/usr/include/c++/8/filesystem
/usr/include/c++/8/experimental/filesystem
$ sudo touch /usr/include/c++/5/experimental/filesystem
/usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem
/usr/include/c++/8/experimental/filesystem
$ make
[100%] Built target FileSync
$ touch ../main.cxx
$ make
Scanning dependencies of target FileSync
[ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o
[100%] Linking CXX executable FileSync
[100%] Built target FileSync


=> cmake don't create "full include dependency" which IS a mistake....
updating system g++ can just assume the target is uptodate and in fact just
create a broken build...

in cmake cxx.includecache

#IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">])
#IncludeRegexScan: ^.*$
#IncludeRegexComplain: ^$
#IncludeRegexTransform:
/home/orange/crypt/Devel/projets/FileSync/main.cxx
cstdio
-
io.h
-
fcntl.h
-
locale
-
clocale
-
fstream
-
iostream
-
filesystem
-

$ /usr/bin/gcc-8 -M ../main.cxx
main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \
 /usr/include/c++/8/cstdio \
 /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \
 /usr/x86_64-linux-gnu/include/features.h \
 /usr/x86_64-linux-gnu/include/sys/cdefs.h \
 /usr/x86_64-linux-gnu/include/bits/wordsize.h \
 /usr/x86_64-linux-gnu/include/bits/long-double.h \
 /usr/x86_64-linux-gnu/include/gnu/stubs.h \
 /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \
 /usr/x86_64-linux-gnu/include/stdio.h \
 /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \
 /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \
 /usr/x86_64-linux-gnu/include/bits/types.h \
 /usr/x86_64-linux-gnu/include/bits/typesizes.h \
 /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \
 /usr/x86_64-linux-gnu/include/bits/types/FILE.h \
 /usr/x86_64-linux-gnu/include/bits/libio.h \
 /usr/x86_64-linux-gnu/include/bits/_G_config.h \
 /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \
 /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \
 /usr/x86_64-linux-gnu/include/bits/stdio_lim.h \
 /usr/x86_64-linux-gnu/include/bits/sys_errlist.h \
 /usr/include/c++/8/locale /usr/include/c++/8/bits/localefwd.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/c++locale.h \
 /usr/include/c++/8/clocale /usr/x86_64-linux-gnu/include/locale.h \
 /usr/x86_64-linux-gnu/include/bits/locale.h \
 /usr/x86_64-linux-gnu/include/bits/types/locale_t.h \
 /usr/x86_64-linux-gnu/include/bits/types/__locale_t.h \
 /usr/include/c++/8/iosfwd /usr/include/c++/8/bits/stringfwd.h \
 /usr/include/c++/8/bits/memoryfwd.h /usr/include/c++/8/bits/postypes.h \
 /usr/include/c++/8/cwchar /usr/x86_64-linux-gnu/include/wchar.h \
 /usr/x86_64-linux-gnu/include/bits/floatn.h \
 /usr/x86_64-linux-gnu/include/bits/floatn-common.h \
 /usr/x86_64-linux-gnu/include/bits/wchar.h \
 /usr/x86_64-linux-gnu/include/bits/types/wint_t.h \
 /usr/x86_64-linux-gnu/include/bits/types/mbstate_t.h \
 /usr/include/c++/8/cctype /usr/x86_64-linux-gnu/include/ctype.h \
 /usr/x86_64-linux-gnu/include/endian.h \
 /usr/x86_64-linux-gnu/include/bits/endian.h \
 /usr/x86_64-linux-gnu/include/bits/byteswap.h \
 /usr/x86_64-linux-gnu/include/bits/byteswap-16.h \
 /usr/x86_64-linux-gnu/include/bits/uintn-identity.h \
 /usr/include/c++/8/bits/locale_classes.h /usr/include/c++/8/string \
 /usr/include/c++/8/bits/char_traits.h \
 /usr/include/c++/8/bits/stl_algobase.h \
 /usr/include/c++/8/bits/functexcept.h \
 /usr/include/c++/8/bits/exception_defines.h \
 /usr/include/c++/8/bits/cpp_type_traits.h \
 /usr/include/c++/8/ext/type_traits.h \
 /usr/include/c++/8/ext/numeric_traits.h \
 /usr/include/c++/8/bits/stl_pair.h /usr/include/c++/8/bits/move.h \
 /usr/include/c++/8/bits/concept_check.h /usr/include/c++/8/type_traits \
 /usr/include/c++/8/bits/stl_iterator_base_types.h \
 /usr/include/c++/8/bits/stl_iterator_base_funcs.h \
 /usr/include/c++/8/debug/assertions.h \
 /usr/include/c++/8/bits/stl_iterator.h \
 /usr/include/c++/8/bits/ptr_traits.h /usr/include/c++/8/debug/debug.h \
 /usr/include/c++/8/bits/predefined_ops.h /usr/include/c++/8/cstdint \
 /usr/lib/gcc/x86_64-linux-gnu/8/include/stdint.h \
 /usr/x86_64-linux-gnu/include/stdint.h \
 /usr/x86_64-linux-gnu/include/bits/stdint-intn.h \
 /usr/x86_64-linux-gnu/include/bits/stdint-uintn.h \
 /usr/include/c++/8/bits/allocator.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/c++allocator.h \
 /usr/include/c++/8/ext/new_allocator.h /usr/include/c++/8/new \
 /usr/include/c++/8/exception /usr/include/c++/8/bits/exception.h \
 /usr/include/c++/8/bits/exception_ptr.h \
 /usr/include/c++/8/bits/cxxabi_init_exception.h \
 /usr/include/c++/8/typeinfo /usr/include/c++/8/bits/hash_bytes.h \
 /usr/include/c++/8/bits/nested_exception.h \
 /usr/include/c++/8/bits/ostream_insert.h \
 /usr/include/c++/8/bits/cxxabi_forced.h \
 /usr/include/c++/8/bits/stl_function.h \
 /usr/include/c++/8/backward/binders.h \
 /usr/include/c++/8/bits/range_access.h \
 /usr/include/c++/8/initializer_list \
 /usr/include/c++/8/bits/basic_string.h \
 /usr/include/c++/8/ext/atomicity.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/gthr.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h \
 /usr/x86_64-linux-gnu/include/pthread.h \
 /usr/x86_64-linux-gnu/include/sched.h \
 /usr/x86_64-linux-gnu/include/bits/types/time_t.h \
 /usr/x86_64-linux-gnu/include/bits/types/struct_timespec.h \
 /usr/x86_64-linux-gnu/include/bits/sched.h \
 /usr/x86_64-linux-gnu/include/bits/cpu-set.h \
 /usr/x86_64-linux-gnu/include/time.h \
 /usr/x86_64-linux-gnu/include/bits/time.h \
 /usr/x86_64-linux-gnu/include/bits/timex.h \
 /usr/x86_64-linux-gnu/include/bits/types/struct_timeval.h \
 /usr/x86_64-linux-gnu/include/bits/types/clock_t.h \
 /usr/x86_64-linux-gnu/include/bits/types/struct_tm.h \
 /usr/x86_64-linux-gnu/include/bits/types/clockid_t.h \
 /usr/x86_64-linux-gnu/include/bits/types/timer_t.h \
 /usr/x86_64-linux-gnu/include/bits/types/struct_itimerspec.h \
 /usr/x86_64-linux-gnu/include/bits/pthreadtypes.h \
 /usr/x86_64-linux-gnu/include/bits/thread-shared-types.h \
 /usr/x86_64-linux-gnu/include/bits/pthreadtypes-arch.h \
 /usr/x86_64-linux-gnu/include/bits/setjmp.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/atomic_word.h \
 /usr/include/c++/8/ext/alloc_traits.h \
 /usr/include/c++/8/bits/alloc_traits.h \
 /usr/include/c++/8/ext/string_conversions.h /usr/include/c++/8/cstdlib \
 /usr/x86_64-linux-gnu/include/stdlib.h \
 /usr/x86_64-linux-gnu/include/bits/waitflags.h \
 /usr/x86_64-linux-gnu/include/bits/waitstatus.h \
 /usr/x86_64-linux-gnu/include/sys/types.h \
 /usr/x86_64-linux-gnu/include/sys/select.h \
 /usr/x86_64-linux-gnu/include/bits/select.h \
 /usr/x86_64-linux-gnu/include/bits/types/sigset_t.h \
 /usr/x86_64-linux-gnu/include/bits/types/__sigset_t.h \
 /usr/x86_64-linux-gnu/include/sys/sysmacros.h \
 /usr/x86_64-linux-gnu/include/bits/sysmacros.h \
 /usr/x86_64-linux-gnu/include/alloca.h \
 /usr/x86_64-linux-gnu/include/bits/stdlib-float.h \
 /usr/include/c++/8/bits/std_abs.h /usr/include/c++/8/cerrno \
 /usr/x86_64-linux-gnu/include/errno.h \
 /usr/x86_64-linux-gnu/include/bits/errno.h \
 /usr/x86_64-linux-gnu/include/linux/errno.h \
 /usr/x86_64-linux-gnu/include/asm/errno.h \
 /usr/x86_64-linux-gnu/include/asm-generic/errno.h \
 /usr/x86_64-linux-gnu/include/asm-generic/errno-base.h \
 /usr/include/c++/8/bits/functional_hash.h \
 /usr/include/c++/8/bits/basic_string.tcc \
 /usr/include/c++/8/bits/locale_classes.tcc \
 /usr/include/c++/8/bits/locale_facets.h /usr/include/c++/8/cwctype \
 /usr/x86_64-linux-gnu/include/wctype.h \
 /usr/x86_64-linux-gnu/include/bits/wctype-wchar.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_base.h \
 /usr/include/c++/8/bits/ios_base.h /usr/include/c++/8/system_error \
 /usr/include/x86_64-linux-gnu/c++/8/bits/error_constants.h \
 /usr/include/c++/8/stdexcept /usr/include/c++/8/streambuf \
 /usr/include/c++/8/bits/streambuf.tcc \
 /usr/include/c++/8/bits/streambuf_iterator.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_inline.h \
 /usr/include/c++/8/bits/locale_facets.tcc \
 /usr/include/c++/8/bits/locale_facets_nonio.h /usr/include/c++/8/ctime \
 /usr/include/x86_64-linux-gnu/c++/8/bits/time_members.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/messages_members.h \
 /usr/x86_64-linux-gnu/include/libintl.h \
 /usr/include/c++/8/bits/codecvt.h \
 /usr/include/c++/8/bits/locale_facets_nonio.tcc \
 /usr/include/c++/8/bits/locale_conv.h \
 /usr/include/c++/8/bits/unique_ptr.h /usr/include/c++/8/utility \
 /usr/include/c++/8/bits/stl_relops.h /usr/include/c++/8/tuple \
 /usr/include/c++/8/array /usr/include/c++/8/bits/uses_allocator.h \
 /usr/include/c++/8/bits/invoke.h /usr/include/c++/8/fstream \
 /usr/include/c++/8/istream /usr/include/c++/8/ios \
 /usr/include/c++/8/bits/basic_ios.h \
 /usr/include/c++/8/bits/basic_ios.tcc /usr/include/c++/8/ostream \
 /usr/include/c++/8/bits/ostream.tcc /usr/include/c++/8/bits/istream.tcc \
 /usr/include/x86_64-linux-gnu/c++/8/bits/basic_file.h \
 /usr/include/x86_64-linux-gnu/c++/8/bits/c++io.h \
 /usr/include/c++/8/bits/fstream.tcc /usr/include/c++/8/iostream \
 /usr/include/c++/8/filesystem


amazing, no? cmake find only 9 dependencies against 100+ real ones (and I
don't even speak of errors that can be caused in parsing if some -D option
is changed....

thanks and regards
JLM


Le lun. 24 juin 2019 ? 14:14, Robert Maynard <robert.maynard at kitware.com> a
?crit :

> It look that starting with CMake 3.6 modification of system headers
> will cause CMake to recompile projects. What version of CMake and your
> compiler are you using?
>
> On Mon, Jun 17, 2019 at 9:40 AM jl forums <jlmxyz.forums at gmail.com> wrote:
> >
> > Hi,
> > I want to create a full tag file and for this require to know the
> compiler full include path...  there is a way to had custom includes path
> but didn't found any variables for the include path....
> > for example :
> > $ gcc-8 -v -x c -E /dev/null
> > Using built-in specs.
> > [....]
> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /usr/lib/gcc/x86_64-linux-gnu/8/include
> >  /usr/local/include
> >  /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
> >  /usr/x86_64-linux-gnu/include
> >  /usr/include/x86_64-linux-gnu
> >  /usr/include
> > End of search list.
> > [...]
> >
> > $ gcc -v -x c -E /dev/null
> > Using built-in specs.
> > [...]
> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /usr/lib/gcc/x86_64-linux-gnu/7/include
> >  /usr/local/include
> >  /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
> >  /usr/x86_64-linux-gnu/include
> >  /usr/include/x86_64-linux-gnu
> >  /usr/include
> > End of search list.
> > [...]
> >
> > I tried to
> >
> >
> > get_target_property(moggle_interface_includes FileSync
> INTERFACE_INCLUDE_DIRECTORIES)
> > message("Moggle interface includes: ${moggle_interface_includes}")
> >
> > get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES)
> > message("MOTOR includes ${motor_includes}")
> >
> > but I get
> >
> > Moggle interface includes: moggle_interface_includes-NOTFOUND
> > MOTOR includes motor_includes-NOTFOUND
> >
> >
> > there is also some issue because cmake strip dependencies from system's
> include, which means that updating a system software won't cause rebuild
> and consider that the build is uptodate, causing unexpected results
> > seems that there is ways to workaround this :
> https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake
> but this is ugly... would be better to let the user choose with an option
> >
> > thanks and regards
> > JLM
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190627/0ff3a01c/attachment-0001.html>

From Torsten at Robitzki.de  Thu Jun 27 09:09:20 2019
From: Torsten at Robitzki.de (Torsten at Robitzki.de)
Date: Thu, 27 Jun 2019 15:09:20 +0200
Subject: [CMake] Embedded build using ExternalProject
In-Reply-To: <4ee63189-262c-b17e-77a6-ddb53399c6be@mvtec.com>
References: <1AA76FE5-D78D-4E44-BDA4-AC8193721518@Robitzki.de>
 <4ee63189-262c-b17e-77a6-ddb53399c6be@mvtec.com>
Message-ID: <6A682540-0756-4C0E-8780-C548D587D8FC@Robitzki.de>

Hi Eric,

> Am 27.06.2019 um 13:06 schrieb Eric Doenges <doenges at mvtec.com>:
> 
> I can't help you with your other issues, but I believe the solution to this problem is to specify "BUILD_ALWAYS TRUE" in your ExternalProject_Add. From the documentation for ExternalProject_Add:
> Enabling this option forces the build step to always be run. This can be the easiest way to robustly ensure that the external project?s own build dependencies are evaluated rather than relying on the default success timestamp-based method. This option is not normally needed unless developers are expected to modify something the external project?s build depends on in a way that is not detectable via the step target dependencies (e.g. SOURCE_DIR is used without a download method and developers might modify the sources in SOURCE_DIR).

I?ve applied this option and will see if it helps.

thanks,

Torsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190627/bfc306db/attachment.sig>

From charles.w.jackson at nasa.gov  Thu Jun 27 13:09:27 2019
From: charles.w.jackson at nasa.gov (Jackson, Charles W. (LARC-D302))
Date: Thu, 27 Jun 2019 17:09:27 +0000
Subject: [CMake] Extracting the build order for a target
Message-ID: <bb1af2bce833835a638d5e06edae44c3d879eb1d.camel@nasa.gov>

Hello,

I was wondering if there was a way to extract the dependencies/build
order for a target? I know you can create graphs of the dependicies
using graphviz but what I really want is just a list of files in the
build order (whatever order the files would be built in if the build
was serial).

I would like this so that we can concatonate all of our Fortran source
files into a single file for interface checking (since there is only a
limited use of modules or explicit interfaces).

Thanks,
Chip

From robert.maynard at kitware.com  Thu Jun 27 14:31:07 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 27 Jun 2019 14:31:07 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.15.0-rc3 is ready for testing
Message-ID: <CAFzjYVorZGwFbh86QOrQ-SQn1S0BpaCTuPXzMH1iXvpMQvFWVA@mail.gmail.com>

I am proud to announce the third CMake 3.15 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.15

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.15/release/3.15.html

Some of the more significant changes in CMake 3.15 are:

* The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and
  "MSVC_RUNTIME_LIBRARY" target property were introduced to select the
  runtime library used by compilers targeting the MSVC ABI. See policy
  "CMP0091".

* With MSVC-like compilers the value of "CMAKE_<LANG>_FLAGS" no
  longer contains warning flags like "/W3" by default. See policy
  "CMP0092".

* The "Clang" compiler variant on Windows that targets the MSVC ABI
  but has a GNU-like command line is now supported.

* Preliminary support for the "Swift" language was added to the
  "Ninja" generator.

* The "$<COMPILE_LANG_AND_ID:...>" generator expression was
  introduced to allow specification of compile options for target
  files based on the "CMAKE_<LANG>_COMPILER_ID" and "LANGUAGE" of each
  source file.

* The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID",
  "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE",
  "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching
  one value from a comma-separated list.

* The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell
  "find_package()" calls to look for a package configuration file
  first even if a find module is available.

* The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set
  on Interface Libraries. The headers specified by those properties
  can be installed using the "install(TARGETS)" command by passing the
  "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively.

* The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and
  "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the
  Just My Code feature of the Visual Studio Debugger when compiling
  with MSVC cl 19.05 and higher.

* The "FindBoost" module was reworked to expose a more consistent
  user experience between its ?Config? and ?Module? modes and with
  other find modules in general.

* The "message()" command learned new types: "NOTICE", "VERBOSE",
  "DEBUG" and "TRACE".

* The "export(PACKAGE)" command now does nothing unless enabled via
  "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".


* The "CMAKE_GENERATOR" environment variable was added to specify a
  default generator to use when "cmake(1)" is run without a "-G"
  option.  Additionally, environment variables
  "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and
  "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.

* The "cmake(1)" command gained a new "--install" option. This may
  be used after building a project to run installation without using
  the generated build system or the native build tool.

* The "cmake(1)" command learned a new CLI option "--loglevel".

* The "cmake-server(7)" mode has been deprecated and will be removed
  from a future version of CMake.  Please port clients to use the
  "cmake-file-api(7)" instead.


CMake 3.15 Release Notes
************************

Changes made since CMake 3.14 include the following.


New Features
============


Generators
----------

* The "Xcode" generator now supports per-target schemes. See the
  "CMAKE_XCODE_GENERATE_SCHEME" variable and "XCODE_GENERATE_SCHEME"
  target property.

* The "Green Hills MULTI" generator has been updated:

  * It now supports the "add_custom_command()" and
    "add_custom_target()" commands.

  * It is now available on Linux.


Languages
---------

* Preliminary support for the "Swift" language was added to the
  "Ninja" generator:

  * Use the "SWIFTC" environment variable to specify a compiler.

  * The "Swift_DEPENDENCIES_FILE" target property and
    "Swift_DEPENDENCIES_FILE" source file property were added to
    customize dependency files.

  * The "Swift_MODULE_NAME" target property was added to customize
    the Swift module name.

  * The "Swift_DIAGNOSTICS_FILE" source property was added to
    indicate where to write the serialised Swift diagnostics.

  The Swift support is experimental, not considered stable, and may
  change in future releases of CMake.


Compilers
---------

* The "Clang" compiler variant on Windows that targets the MSVC ABI
  but has a GNU-like command line is now supported.

* Support for the Clang-based ARM compiler was added with compiler
  id "ARMClang".

* Support was added for the IAR compiler architectures Renesas RX,
  RL78, RH850 and Texas Instruments MSP430.

* Support was added for the IAR compilers built for Linux (IAR
  BuildLx).


Command-Line
------------

* The "CMAKE_GENERATOR" environment variable was added to specify a
  default generator to use when "cmake(1)" is run without a "-G"
  option.  Additionally, environment variables
  "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and
  "CMAKE_GENERATOR_INSTANCE" were created to configure the generator.

* The "cmake(1)" "--build" tool "--target" parameter gained support
  for multiple targets, e.g. "cmake --build . --target Library1
  Library2". It now also has a short form "-t" alias, e.g. "cmake
  --build . -t Library1 Library2".

* The "cmake(1)" command gained a new "--install" option. This may
  be used after building a project to run installation without using
  the generated build system or the native build tool.

* The "cmake(1)" command learned a new CLI option "--loglevel".

* The "cmake(1)" "-E remove_directory" command-line tool learned to
  support removing multiple directories.

* The "cmake(1)" "-E tar" tool has been improved:

  * It now continues adding files to an archive even if some of the
    files are not readable.  This behavior is more consistent with the
    classic "tar" tool.

  * It now parses all flags, and if an invalid flag was provided, a
    warning is issued.

  * It now displays an error if no action flag was specified, along
    with a list of possible actions: "t" (list), "c" (create) or "x"
    (extract).

  * It now supports extracting ("-x") or listing ("-t") only
    specific files or directories.

  * It now supports Zstandard compression with a "--zstd" option.
    Zstandard was designed to give a compression ratio comparable to
    that of the DEFLATE (zip) algorithm, but faster, especially for
    decompression.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  gained a new "JOB_POOL" option that works with the "Ninja" generator
  to set the pool variable on the build statement.

* The "add_library()" command "ALIAS" option learned to support
  import libraries of the "UNKNOWN" type.

* The "cmake_parse_arguments()" command gained an additional
  "<prefix>_KEYWORDS_MISSING_VALUES" output variable to report keyword
  arguments that were given by the caller with no values.

* The "execute_process()" command gained a "COMMAND_ECHO" option and
  supporting "CMAKE_EXECUTE_PROCESS_COMMAND_ECHO" variable to enable
  echoing of the command-line string before execution.

* The "file(INSTALL)" command learned a new argument,
  "FOLLOW_SYMLINK_CHAIN", which can be used to recursively resolve and
  install symlinks.

* "list()" learned new sub-commands: "PREPEND", "POP_FRONT" and
  "POP_BACK".

* The "message()" command learned new types: "NOTICE", "VERBOSE",
  "DEBUG" and "TRACE".

* The "string()" learned a new sub-command "REPEAT".


Variables
---------

* The "CMAKE_CROSSCOMPILING_EMULATOR" variable and corresponding
  "CROSSCOMPILING_EMULATOR" target property learned to support
  arguments to the emulator.

* The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell
  "find_package()" calls to look for a package configuration file
  first even if a find module is available.

* The "CMAKE_FRAMEWORK" variable was added to initialize the
  "FRAMEWORK" property on all targets.

* The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and
  "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the
  Just My Code feature of the Visual Studio Debugger when compiling
  with MSVC cl 19.05 and higher.

* The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and
  "MSVC_RUNTIME_LIBRARY" target property were introduced to select the
  runtime library used by compilers targeting the MSVC ABI. See policy
  "CMP0091".

* The "CMAKE_PROJECT_INCLUDE" and "CMAKE_PROJECT_INCLUDE_BEFORE"
  variables were added to allow injection of custom code at the sites
  of "project()" calls without knowing the project name a priori.


Properties
----------

* The "ADDITIONAL_CLEAN_FILES" target property and
  "ADDITIONAL_CLEAN_FILES" directory property were added. They allow
  to register additional files that should be removed during the clean
  stage.

* The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set
  on Interface Libraries. The headers specified by those properties
  can be installed using the "install(TARGETS)" command by passing the
  "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively.

* The "VS_PACKAGE_REFERENCES" target property was added to tell
  Visual Studio Generators to add references to "nuget" packages.

* The "VS_PROJECT_IMPORT" target property was added to allow managed
  Visual Studio project files to import external ".props" files.

* The "VS_NO_SOLUTION_DEPLOY" target property was added to tell
  Visual Studio Generators whether to deploy an artifact to the WinCE
  or Windows Phone target device.


Modules
-------

* The "FindBoost" module was reworked to expose a more consistent
  user experience between its ?Config? and ?Module? modes and with
  other find modules in general.

  * A new imported target "Boost::headers" is now defined (same as
    "Boost::boost").

  * New output variables "Boost_VERSION_MACRO",
    "Boost_VERSION_MAJOR", "Boost_VERSION_MINOR",
    "Boost_VERSION_PATCH", and "Boost_VERSION_COUNT" were added.

  * The "QUIET" argument passed to "find_package()" is no longer
    ignored in config mode.  Note that the CMake package shipped with
    Boost "1.70.0" ignores the "QUIET" argument passed to
    "find_package()".  This is fixed in the next Boost release.

  * The input switch "Boost_DETAILED_FAILURE_MSG" was removed.

  * "Boost_VERSION" now reports the version in "x.y.z" format in
    module mode.  See policy "CMP0093".

* The "FindCups" module now provides imported targets.

* The "FindEnvModules" module was added to use Lua- and TCL-based
  environment modules in CTest Scripts.

* The "FindGLEW" module now provides an interface more consistent
  with what upstream GLEW provides in its own CMake package files.

* The "FindPkgConfig" now populates "INTERFACE_LINK_OPTIONS"
  property of imported targets with other (non-library) linker flags.

* The "FindPostgreSQL" module learned to find debug and release
  variants separately.

* Modules "FindPython3", "FindPython2" and "FindPython" gained
  additional lookup strategies and controls, and a new default. See
  policy "CMP0094".

* Modules "FindPython", "FindPython2" and "FindPython3" gain a new
  target (respectively "Python::Module", "Python2::Module" and
  "Python3::Module") which can be used to develop Python modules.

* Modules "FindPython3", "FindPython2" and "FindPython" gain
  capability to control how virtual environments are handled.

* The "UseSWIG" module learned to manage alternate library names by
  passing "-interface <library_name>" for "python" language or
  "-dllimport <library_name>" for "CSharp" language to the "SWIG"
  compiler.


Generator Expressions
---------------------

* The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID",
  "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE",
  "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching
  one value from a comma-separated list.

* The "$<CUDA_COMPILER_ID:...>" and "$<CUDA_COMPILER_VERSION:...>"
  "generator expressions" were added.

* The "$<COMPILE_LANG_AND_ID:...>" generator expression was
  introduced to allow specification of compile options for target
  files based on the "CMAKE_<LANG>_COMPILER_ID" and "LANGUAGE" of each
  source file.

* A "$<FILTER:list,INCLUDE|EXCLUDE,regex>" "generator expression"
  has been added.

* A "$<REMOVE_DUPLICATES:list>" "generator expression" has been
  added.

* The "$<SHELL_PATH:...>" "generator expression" gained support for
  a list of paths.

* New "$<TARGET_FILE*>" "generator expressions" were added to
  retrieve the prefix, base name, and suffix of the file names of
  various artifacts:

  * "$<TARGET_FILE_PREFIX:...>"

  * "$<TARGET_FILE_BASE_NAME:...>"

  * "$<TARGET_FILE_SUFFIX:...>"

  * "$<TARGET_LINKER_FILE_PREFIX:...>"

  * "$<TARGET_LINKER_FILE_BASE_NAME:...>"

  * "$<TARGET_LINKER_FILE_SUFFIX:...>"

  * "$<TARGET_PDB_FILE_BASE_NAME:...>"

* The "$<TARGET_OBJECTS:...>" "generator expression" is now
  supported on "SHARED", "STATIC", "MODULE" libraries and executables.


CTest
-----

* The "ctest_submit()" command learned a new option: "BUILD_ID".
  This can be used to store the ID assigned to this build by CDash to
  a variable.

* The "ctest_update()" command learned to honor a new variable:
  "CTEST_UPDATE_VERSION_OVERRIDE". This can be used to specify the
  current version of your source tree rather than using the update
  command to discover the current version that is checked out.


CPack
-----

* The "CPack IFW Generator" gained a new
  "CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer
  stylesheet.


Deprecated and Removed Features
===============================

* The "cmake-server(7)" mode has been deprecated and will be removed
  from a future version of CMake.  Please port clients to use the
  "cmake-file-api(7)" instead.

* The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now
  deprecated.  Use the "ADDITIONAL_CLEAN_FILES" directory property
  instead.

* The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered
  deprecated. Support still exists but will be removed in future
  versions.

* The "export(PACKAGE)" command now does nothing unless enabled via
  "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090".

* The "Xcode" generator now requires at least Xcode 5.

* An explicit deprecation diagnostic was added for policy "CMP0066"
  ("CMP0065" and below were already deprecated). The "cmake-
  policies(7)" manual explains that the OLD behaviors of all policies
  are deprecated and that projects should port to the NEW behaviors.


Other Changes
=============

* CMake learned how to compile C++14 with the IBM AIX XL compiler
  and the SunPro compiler and to compile C++20 with the AppleClang
  compiler.

* With MSVC-like compilers the value of "CMAKE_<LANG>_FLAGS" no
  longer contains warning flags like "/W3" by default. See policy
  "CMP0092".

* IBM Clang-based XL compilers that define "__ibmxl__" now use the
  compiler id "XLClang" instead of "XL".  See policy "CMP0089".

* The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were
  changed to ignore empty arguments with a warning instead of treating
  them as a relative path and removing the contents of the current
  directory.


----------------------------------------------------------------------------
Changes made since CMake 3.15.0-rc2:

Alexandru Croitor (1):
  Help: Improve documentation of IMPORTED_LOCATION property

Brad King (4):
  export: Restore support for empty TARGETS list
  VS: Use AddLanguageFlags to de-duplicate CMAKE_{CUDA,ASM*}_FLAGS lookup
  CUDA: Implement MSVC runtime library abstraction
  CMake 3.15.0-rc3

Craig Scott (2):
  Help: Typo and grammar fixes in cmake_parse_arguments() docs
  Help: Document that CMAKE_FRAMEWORK initializes FRAMEWORK target prop

Francisco Facioni (1):
  Ninja: Fix CUDA device linking when using response files

Rolf Eike Beer (1):
  FindIconv test: request C++11

Sebastian Holtermann (3):
  Help: Autogen: Overhaul AUTORCC target property documentation
  Help: Autogen: Overhaul AUTOUIC target property documentation
  Help: Autogen: Overhaul AUTOMOC target property documentation

From dustyn at blasig.us  Thu Jun 27 14:32:35 2019
From: dustyn at blasig.us (Dustyn Blasig)
Date: Thu, 27 Jun 2019 13:32:35 -0500
Subject: [CMake] execute_process() and reconfiguration
Message-ID: <CAN4pPGWYAtnjQrpCAmHyPYKEmKV3qgAt7vhj+9-x0Y2ifPATrQ@mail.gmail.com>

Hi All,

I'm using execute_process to generate sources and additional CMakeLists.txt
file that then get included in the build. Is there a way for me to tell
CMake what source files my command relies on so it knows when it needs to
do a reconfiguration? For instance, if I touch the python script that
generates the source files, I'd like running make to properly reconfigure
if the change causes new source files to get created.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190627/0f2cdc9c/attachment-0001.html>

From smokris at softpixel.com  Thu Jun 27 15:48:59 2019
From: smokris at softpixel.com (Steve Mokris)
Date: Thu, 27 Jun 2019 15:48:59 -0400
Subject: [CMake] execute_process() and reconfiguration
In-Reply-To: <CAN4pPGWYAtnjQrpCAmHyPYKEmKV3qgAt7vhj+9-x0Y2ifPATrQ@mail.gmail.com>
References: <CAN4pPGWYAtnjQrpCAmHyPYKEmKV3qgAt7vhj+9-x0Y2ifPATrQ@mail.gmail.com>
Message-ID: <D4151316-79E5-454B-A503-9B927821224F@softpixel.com>

> Is there a way for me to tell CMake what source files my command relies on so it knows when it needs to do a reconfiguration?

CMAKE_CONFIGURE_DEPENDS can do that.

https://cmake.org/cmake/help/latest/prop_dir/CMAKE_CONFIGURE_DEPENDS.html


From dustyn at blasig.us  Thu Jun 27 22:17:59 2019
From: dustyn at blasig.us (Dustyn Blasig)
Date: Thu, 27 Jun 2019 21:17:59 -0500
Subject: [CMake] CMake with FetchContent instead of Git Submodules
Message-ID: <CAN4pPGXg7BGR9bzbejg=EhzZAYEnGDncgrJ_ESw+11jo9t6HNQ@mail.gmail.com>

Hi All,

I'm attempting to replace our use of git submodules with FetchContent flows
instead so we can pull pre-built packages if they already exist instead of
buildings locally.

However, I need to support a flow similar to Git submodules where
developers can edit a submodule and then rebuild the enclosing project
incrementally. Things seem to work OK if I jump into the fetched source
directories and check out branches, etc. However, even if I move the
download and source/unpacked folders outside the build (binary) directory
and then delete the build directory, rerunning CMake will blast away the
unpacked source even if the last extraction was with the same checksummed
download. I need to ensure a "clean" won't delete someones work in a
submodule, which is one reason why Git makes it hard to uninit and remove
submodules.

Is there a best practice for a flow like this that I can replicate?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190627/d8e4f049/attachment.html>

From meghna.vasudeva at gmail.com  Fri Jun 28 01:24:53 2019
From: meghna.vasudeva at gmail.com (dexter810)
Date: Thu, 27 Jun 2019 22:24:53 -0700 (MST)
Subject: [CMake] Is this the rigth way to build a shared library?
Message-ID: <1561699493723-0.post@n2.nabble.com>

This is my CMakeLists.txt which is successfully building a shared library, I
just wanted to confirm if it's the right way and it: 

cmake_minimum_required(VERSION 3.6)
project(main)



include_directories(
        ${CMAKE_CURRENT_SOURCE_DIR}/include
       
${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/include)

add_library(main SHARED main.cpp)


link_libraries (
        -L${CMAKE_CURRENT_SOURCE_DIR}/build/src/
        -L${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/.libs
    yaracpp yara pthread ssl crypto)




When I do ldd libmain.so I get: 

   linux-vdso.so.1 (0x00007ffee6583000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f7e1be18000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f7e1bc00000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7e1b80f000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7e1b471000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7e1c3a4000)



CMakeLists.txt for creating a successfully running executable: 
cmake_minimum_required(VERSION 3.6)
project(main CXX C)

add_executable(main main.cpp)

target_include_directories(main PRIVATE
        ${CMAKE_CURRENT_SOURCE_DIR}/include
       
${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/include)

target_link_libraries (main
        -L${CMAKE_CURRENT_SOURCE_DIR}/build/src/
        -L${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/.libs
    yaracpp yara pthread ssl crypto)

on doing ldd main, I got: 

    linux-vdso.so.1 (0x00007ffe723d4000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fc0c644b000)
    libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
(0x00007fc0c5f80000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fc0c5bf7000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc0c5859000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fc0c5641000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc0c5250000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fc0c68d6000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc0c504c000)



--
Sent from: http://cmake.3232098.n2.nabble.com/

From vinay.kotegowder at gmail.com  Fri Jun 28 02:52:04 2019
From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder)
Date: Fri, 28 Jun 2019 12:22:04 +0530
Subject: [CMake] String CONCAT issue
Message-ID: <CAE3QRuMpbsf4+-JqVLtAURoSzwPXBxQzchbHEg6g4Az3uO0wow@mail.gmail.com>

Hello,

The snippet:
set(SUITE_DIR /home/../abc)

list(APPEND TEST_LSIT
     test_a001)

foreach(test ${TEST_LIST})
        message(${test})
        string(CONCAT TEST_CMAKE "${SUITE_DIR}/" "${test}/test.cmake")
        message(${TEST_CMAKE})
endforeach()

Output:
test_a001

/home/.../abc/test_a001
/test.cmake

Not able to get the path of test.cmake properly.

Please let me know what is wrong in code.

Appreciate early response.

Regards,
Vinay

From Torsten at Robitzki.de  Fri Jun 28 05:49:06 2019
From: Torsten at Robitzki.de (Torsten Robitzki)
Date: Fri, 28 Jun 2019 11:49:06 +0200
Subject: [CMake] CPack`ing a bunch of command line tools on OS/X
Message-ID: <B04D3848-E81D-4793-8FBD-E0854EFD1394@Robitzki.de>

Hello,
I try to pack a bunch of command line tools (and some additional data files) into an OS/X installer. When the installer is running, it should install / copy the command line tools and adjust the PATH variable (or what ever mean that comes close, to make the tools available). I use a super build structure and after build and is done, I end up with a very simple structure:

  install
    |
    |\-bin
    |   |\-bjpaprog
    |   |\-bjpaserver
    |   |\-bootloader_client
    |   \-?create_package
    |
    \--firmware
        |\-bootloader.tfp
        |\-firmware.tfp
        \-?softdevice.tfp

I use TGZ and productbuild as CPack generators. The generated zip file contains all the files above. The generated pkg files, just starts the installer, but does nothing.

The CMakeLists.txt for the packing looks basically like this:

    cmake_minimum_required(VERSION 3.14)

    set(CPACK_PACKAGE_VENDOR "Torrox GmbH & Co KG")

    install(DIRECTORY ${INSTALL_DIR}/bin DESTINATION .)
    install(DIRECTORY ${INSTALL_DIR}/firmware DESTINATION .)

    set(CPACK_GENERATOR TGZ productbuild)

    include(CPack)


I have no clue, to as where to start. Any ideas, pointers, comments?

best regards,

Torsten


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190628/bdf2cc76/attachment.sig>

From craig.scott at crascit.com  Fri Jun 28 06:25:36 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Fri, 28 Jun 2019 20:25:36 +1000
Subject: [CMake] CMake with FetchContent instead of Git Submodules
In-Reply-To: <CAN4pPGXg7BGR9bzbejg=EhzZAYEnGDncgrJ_ESw+11jo9t6HNQ@mail.gmail.com>
References: <CAN4pPGXg7BGR9bzbejg=EhzZAYEnGDncgrJ_ESw+11jo9t6HNQ@mail.gmail.com>
Message-ID: <CA+dygYmfy+BMVOyRMxKUisPC4BRNe+nsh3J_7EynWX4tekvbzA@mail.gmail.com>

On Fri, Jun 28, 2019 at 12:18 PM Dustyn Blasig <dustyn at blasig.us> wrote:

> Hi All,
>
> I'm attempting to replace our use of git submodules with FetchContent
> flows instead so we can pull pre-built packages if they already exist
> instead of buildings locally.
>
> However, I need to support a flow similar to Git submodules where
> developers can edit a submodule and then rebuild the enclosing project
> incrementally. Things seem to work OK if I jump into the fetched source
> directories and check out branches, etc. However, even if I move the
> download and source/unpacked folders outside the build (binary) directory
> and then delete the build directory, rerunning CMake will blast away the
> unpacked source even if the last extraction was with the same checksummed
> download. I need to ensure a "clean" won't delete someones work in a
> submodule, which is one reason why Git makes it hard to uninit and remove
> submodules.
>
> Is there a best practice for a flow like this that I can replicate?
>

(Background info: I'm the creator of the FetchContent module)

If you want to be making changes to the sources, you should clone that repo
manually and point the build at it rather than try to modify the one that
the project downloads for you. You do this by setting the
FETCHCONTENT_SOURCE_DIR_<someName> cache variable to override where the
build should find the sources. Here's the relevant part from the
FetchContent documentation:

FETCHCONTENT_SOURCE_DIR_<ucName>If this is set, no download or update steps
are performed for the specified content and the <lcName>_SOURCE_DIR variable
returned to the caller is pointed at this location. This gives developers a
way to have a separate checkout of the content that they can modify freely
without interference from the build. The build simply uses that existing
source, but it still defines <lcName>_BINARY_DIR to point inside its own
build area. Developers are strongly encouraged to use this mechanism rather
than editing the sources populated in the default location, as changes to
sources in the default location can be lost when content population details
are changed by the project.

The thinking behind this is that the project will assume it is in control
of the sources unless told otherwise. By setting the above cache variable,
you are telling FetchContent that "I want to use my own sources instead of
whatever you would normally use". Either FetchContent is in control or you
are.

I use this feature a LOT. Let's say you're working on a project where you
need to do some refactoring that requires changes in the top level project
and in some of its dependencies. I will have the top level project cloned.
I will also have separate manually cloned repos for those dependencies that
I need to modify. When I run CMake on my top level project, I use
FETCHCONTENT_SOURCE_DIR_<depName> to point the build at my local cloned
repos. That makes the build use my local clones so I can modify the
sources, change branches, etc. without fear of things being changed under
my feet. When I'm done, I'll commit and push my changes in each of the
local cloned repos, then I'll update the GIT_HASH details of those
dependencies in my top level project. I delete the
FETCHCONTENT_SOURCE_DIR_<...> variables from my CMake cache and re-run
CMake (and build) to confirm that I've updated my dependency hashes
correctly, then I commit and push my changes to the top level project.

I use this strategy with project hierarchies with 40+ dependencies that can
be up to maybe 10 levels deep. I can pull out any dependency used anywhere
in the hierarchy and work with my own local cloned repo without having to
care about where in the project hierarchy that dependency is usually
populated. Being able to easily and selectively switch between the
project-controlled FetchContent-provided source or my own local cloned
repo(s) is critical to being able to do this efficiently. If you look at
the CMake cache variables in ccmake or cmake-gui, you will also see all the
source directory overrides grouped together because the variable names all
start with FETCHCONTENT_SOURCE_DIR (this is why I named the cache variables
FetchContent creates this way instead of putting the dependency name at the
front of the cache variable name). So you can quickly see for which
dependencies you are currently using a local cloned repo instead of what
the project normally uses.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190628/5036d605/attachment-0001.html>

From eike at sf-mail.de  Fri Jun 28 06:31:11 2019
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Fri, 28 Jun 2019 12:31:11 +0200
Subject: [CMake] String CONCAT issue
In-Reply-To: <CAE3QRuMpbsf4+-JqVLtAURoSzwPXBxQzchbHEg6g4Az3uO0wow@mail.gmail.com>
References: <CAE3QRuMpbsf4+-JqVLtAURoSzwPXBxQzchbHEg6g4Az3uO0wow@mail.gmail.com>
Message-ID: <56a05462cde091ff903967862220c456@sf-mail.de>

Am 2019-06-28 08:52, schrieb vinay kumar Kotegowder:
> Hello,
> 
> The snippet:
> set(SUITE_DIR /home/../abc)
> 
> list(APPEND TEST_LSIT
>      test_a001)

Since there is a type here I bet this is not the original code that you 
have run.

> foreach(test ${TEST_LIST})
>         message(${test})

Please prefix the calls to message() with something so it is obvious 
which call is producing which output.

>         string(CONCAT TEST_CMAKE "${SUITE_DIR}/" "${test}/test.cmake")
>         message(${TEST_CMAKE})
> endforeach()
> 
> Output:
> test_a001
> 
> /home/.../abc/test_a001
> /test.cmake

Which CMake version is this about?
-- 

From kyle.edwards at kitware.com  Fri Jun 28 09:31:31 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 28 Jun 2019 09:31:31 -0400
Subject: [CMake] Is this the rigth way to build a shared library?
In-Reply-To: <1561699493723-0.post@n2.nabble.com>
References: <1561699493723-0.post@n2.nabble.com>
Message-ID: <1561728691.6071.2.camel@kitware.com>

On Thu, 2019-06-27 at 22:24 -0700, dexter810 wrote:
> This is my CMakeLists.txt which is successfully building a shared
> library, I
> just wanted to confirm if it's the right way and it:?
> 
> cmake_minimum_required(VERSION 3.6)
> project(main)
> 
> 
> 
> include_directories(
> ????????${CMAKE_CURRENT_SOURCE_DIR}/include
> ???????
> ${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/include)
> 
> add_library(main SHARED main.cpp)
> 
> 
> link_libraries (
> ????????-L${CMAKE_CURRENT_SOURCE_DIR}/build/src/
> ????????-
> L${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/.libs
> ????yaracpp yara pthread ssl crypto)

Rather than specifying -L flags and specifying library names, there are
two other approaches you can take that would be better:

1) Use target_link_directories() in conjunction with
target_link_libraries().
2) Use find_package(Threads) to find pthread, and use find_library()
for everything else.

https://cmake.org/cmake/help/latest/command/find_package.html
https://cmake.org/cmake/help/latest/command/find_library.html

Kyle

From Kris.Malfettone at sig.com  Fri Jun 28 11:07:48 2019
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Fri, 28 Jun 2019 15:07:48 +0000
Subject: [CMake] Header only libraries with code generated files...
Message-ID: <62368795d2b64ce09588ea4797b58a5a@msx.bala.susq.com>

Hi all,
I had a question about managing code generated header only libraries is a very large project.  Currently, we have a very large project with many static and many generated files.  The problem I have is that due to the size of the project many usages (exe's and libraries) of those code generated files (header files) are done in separate folders from the generation targets.  That leads me to have to be very careful and explicit with using add_custom_command(...), add_custom_target(...), add_depenendcies(...), and set_source_files_properties( ... PROPERTIES GENERATED TRUE ).  Most of that knowledge / setup modeled after reading https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

I was wondering if I was able to simplify that by using Interface Libraries and doing target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my concerns were when adding the interface library to a target in another folder would I still have to:

*         Manually add the transitive dependencies

*         Manually indicate that the generated files are code generated.


I am also assuming my setup would be something like this when using Interface Libraries....

1.       Still use add_custom_command/add_custom_target to do the generation steps.

2.       Add the interface library in the same folder as the generation steps, managing its relationship with the code generation target via add_dependencies() meaning most of the code generation quirks are avoided.

3.       When adding executables or libraries in other folders just use target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )

a.       Hoping that any transitive dependencies to the code generation steps would be handled by exe_name being dependent on MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES

b.      Also hoping that I wouldn't have to specify which files are code generated at that step

I hope this makes sense.

-Kris

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190628/196c0512/attachment.html>

From kyle.edwards at kitware.com  Fri Jun 28 11:31:18 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 28 Jun 2019 11:31:18 -0400
Subject: [CMake] Header only libraries with code generated files...
In-Reply-To: <62368795d2b64ce09588ea4797b58a5a@msx.bala.susq.com>
References: <62368795d2b64ce09588ea4797b58a5a@msx.bala.susq.com>
Message-ID: <CAOXh_KokgEC8G6skDhT6qkgSF3hr2XBLVznDUeto=qkmkrQiKQ@mail.gmail.com>

It sounds like you want to use the INTERFACE version of
target_include_directories():
https://cmake.org/cmake/help/latest/command/target_include_directories.html

What this means is "anything that links against interface library foo
will also need to add these paths to its include directories."

You will also want to use add_dependencies() to make the interface
library dependent on the generation steps:

https://cmake.org/cmake/help/latest/command/add_dependencies.html

Kyle

On Fri, Jun 28, 2019 at 11:17 AM Malfettone, Kris
<Kris.Malfettone at sig.com> wrote:
>
> Hi all,
>
> I had a question about managing code generated header only libraries is a very large project.  Currently, we have a very large project with many static and many generated files.  The problem I have is that due to the size of the project many usages (exe?s and libraries) of those code generated files (header files) are done in separate folders from the generation targets.  That leads me to have to be very careful and explicit with using add_custom_command(?), add_custom_target(?), add_depenendcies(?), and set_source_files_properties( ? PROPERTIES GENERATED TRUE ).  Most of that knowledge / setup modeled after reading https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>
>
>
> I was wondering if I was able to simplify that by using Interface Libraries and doing target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my concerns were when adding the interface library to a target in another folder would I still have to:
>
> ?         Manually add the transitive dependencies
>
> ?         Manually indicate that the generated files are code generated.
>
>
>
>
>
> I am also assuming my setup would be something like this when using Interface Libraries?.
>
> 1.       Still use add_custom_command/add_custom_target to do the generation steps.
>
> 2.       Add the interface library in the same folder as the generation steps, managing its relationship with the code generation target via add_dependencies() meaning most of the code generation quirks are avoided.
>
> 3.       When adding executables or libraries in other folders just use target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )
>
> a.       Hoping that any transitive dependencies to the code generation steps would be handled by exe_name being dependent on MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES
>
> b.      Also hoping that I wouldn?t have to specify which files are code generated at that step
>
>
>
> I hope this makes sense.
>
>
>
> -Kris
>
>
> ________________________________
>
> IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

From dustyn at blasig.us  Fri Jun 28 12:12:21 2019
From: dustyn at blasig.us (Dustyn Blasig)
Date: Fri, 28 Jun 2019 11:12:21 -0500
Subject: [CMake] CMake with FetchContent instead of Git Submodules
In-Reply-To: <CA+dygYmfy+BMVOyRMxKUisPC4BRNe+nsh3J_7EynWX4tekvbzA@mail.gmail.com>
References: <CAN4pPGXg7BGR9bzbejg=EhzZAYEnGDncgrJ_ESw+11jo9t6HNQ@mail.gmail.com>
 <CA+dygYmfy+BMVOyRMxKUisPC4BRNe+nsh3J_7EynWX4tekvbzA@mail.gmail.com>
Message-ID: <CAN4pPGXjiW6W4SMaHaJckDMh++XEfdhXahJ7zy8PndBWx_+EYA@mail.gmail.com>

Wow, how did I miss that when I was looking through the page yesterday?
That's exactly what I need ; )

I may try going one step further and adding a flag <COMPONENT>_USE_CLONE=ON
that will do the full checkout to a repos directory, initialize the repo to
the target tag, and then set FETCHCONTENT_SOURCE_DIR_<COMPONENT> for the
user. The former would only be done iff the repo doesn't already exist.

On Fri, Jun 28, 2019 at 5:25 AM Craig Scott <craig.scott at crascit.com> wrote:

>
>
> On Fri, Jun 28, 2019 at 12:18 PM Dustyn Blasig <dustyn at blasig.us> wrote:
>
>> Hi All,
>>
>> I'm attempting to replace our use of git submodules with FetchContent
>> flows instead so we can pull pre-built packages if they already exist
>> instead of buildings locally.
>>
>> However, I need to support a flow similar to Git submodules where
>> developers can edit a submodule and then rebuild the enclosing project
>> incrementally. Things seem to work OK if I jump into the fetched source
>> directories and check out branches, etc. However, even if I move the
>> download and source/unpacked folders outside the build (binary) directory
>> and then delete the build directory, rerunning CMake will blast away the
>> unpacked source even if the last extraction was with the same checksummed
>> download. I need to ensure a "clean" won't delete someones work in a
>> submodule, which is one reason why Git makes it hard to uninit and remove
>> submodules.
>>
>> Is there a best practice for a flow like this that I can replicate?
>>
>
> (Background info: I'm the creator of the FetchContent module)
>
> If you want to be making changes to the sources, you should clone that
> repo manually and point the build at it rather than try to modify the one
> that the project downloads for you. You do this by setting the
> FETCHCONTENT_SOURCE_DIR_<someName> cache variable to override where the
> build should find the sources. Here's the relevant part from the
> FetchContent documentation:
>
> FETCHCONTENT_SOURCE_DIR_<ucName>If this is set, no download or update
> steps are performed for the specified content and the <lcName>_SOURCE_DIR variable
> returned to the caller is pointed at this location. This gives developers a
> way to have a separate checkout of the content that they can modify freely
> without interference from the build. The build simply uses that existing
> source, but it still defines <lcName>_BINARY_DIR to point inside its own
> build area. Developers are strongly encouraged to use this mechanism rather
> than editing the sources populated in the default location, as changes to
> sources in the default location can be lost when content population details
> are changed by the project.
>
> The thinking behind this is that the project will assume it is in control
> of the sources unless told otherwise. By setting the above cache variable,
> you are telling FetchContent that "I want to use my own sources instead of
> whatever you would normally use". Either FetchContent is in control or you
> are.
>
> I use this feature a LOT. Let's say you're working on a project where you
> need to do some refactoring that requires changes in the top level project
> and in some of its dependencies. I will have the top level project cloned.
> I will also have separate manually cloned repos for those dependencies that
> I need to modify. When I run CMake on my top level project, I use
> FETCHCONTENT_SOURCE_DIR_<depName> to point the build at my local cloned
> repos. That makes the build use my local clones so I can modify the
> sources, change branches, etc. without fear of things being changed under
> my feet. When I'm done, I'll commit and push my changes in each of the
> local cloned repos, then I'll update the GIT_HASH details of those
> dependencies in my top level project. I delete the
> FETCHCONTENT_SOURCE_DIR_<...> variables from my CMake cache and re-run
> CMake (and build) to confirm that I've updated my dependency hashes
> correctly, then I commit and push my changes to the top level project.
>
> I use this strategy with project hierarchies with 40+ dependencies that
> can be up to maybe 10 levels deep. I can pull out any dependency used
> anywhere in the hierarchy and work with my own local cloned repo without
> having to care about where in the project hierarchy that dependency is
> usually populated. Being able to easily and selectively switch between the
> project-controlled FetchContent-provided source or my own local cloned
> repo(s) is critical to being able to do this efficiently. If you look at
> the CMake cache variables in ccmake or cmake-gui, you will also see all the
> source directory overrides grouped together because the variable names all
> start with FETCHCONTENT_SOURCE_DIR (this is why I named the cache variables
> FetchContent creates this way instead of putting the dependency name at the
> front of the cache variable name). So you can quickly see for which
> dependencies you are currently using a local cloned repo instead of what
> the project normally uses.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide <https://crascit.com/professional-cmake/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190628/d1ccfbc8/attachment.html>

From Kris.Malfettone at sig.com  Fri Jun 28 12:25:28 2019
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Fri, 28 Jun 2019 16:25:28 +0000
Subject: [CMake] Header only libraries with code generated files...
In-Reply-To: <CAOXh_KokgEC8G6skDhT6qkgSF3hr2XBLVznDUeto=qkmkrQiKQ@mail.gmail.com>
References: <62368795d2b64ce09588ea4797b58a5a@msx.bala.susq.com>
 <CAOXh_KokgEC8G6skDhT6qkgSF3hr2XBLVznDUeto=qkmkrQiKQ@mail.gmail.com>
Message-ID: <8fb5fb7da1194aae85c2e567fbfa3150@msx.bala.susq.com>

I agree that is sounds like the right way and it is what I would like to use.  However, before going through the work I just wanted to make sure it didn't suffer from the same quirks that add_custom_target does when dealing with code generation in different directory.  As outlined in this blog post:

https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

-Kris

-----Original Message-----
From: Kyle Edwards [mailto:kyle.edwards at kitware.com]
Sent: Friday, June 28, 2019 11:31 AM
To: Malfettone, Kris <Kris.Malfettone at msx.bala.susq.com>
Cc: cmake at cmake.org
Subject: Re: [CMake] Header only libraries with code generated files...

It sounds like you want to use the INTERFACE version of
target_include_directories():
https://cmake.org/cmake/help/latest/command/target_include_directories.html

What this means is "anything that links against interface library foo
will also need to add these paths to its include directories."

You will also want to use add_dependencies() to make the interface
library dependent on the generation steps:

https://cmake.org/cmake/help/latest/command/add_dependencies.html

Kyle

On Fri, Jun 28, 2019 at 11:17 AM Malfettone, Kris
<Kris.Malfettone at sig.com> wrote:
>
> Hi all,
>
> I had a question about managing code generated header only libraries is a very large project.  Currently, we have a very large project with many static and many generated files.  The problem I have is that due to the size of the project many usages (exe?s and libraries) of those code generated files (header files) are done in separate folders from the generation targets.  That leads me to have to be very careful and explicit with using add_custom_command(?), add_custom_target(?), add_depenendcies(?), and set_source_files_properties( ? PROPERTIES GENERATED TRUE ).  Most of that knowledge / setup modeled after reading https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>
>
>
> I was wondering if I was able to simplify that by using Interface Libraries and doing target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my concerns were when adding the interface library to a target in another folder would I still have to:
>
> ?         Manually add the transitive dependencies
>
> ?         Manually indicate that the generated files are code generated.
>
>
>
>
>
> I am also assuming my setup would be something like this when using Interface Libraries?.
>
> 1.       Still use add_custom_command/add_custom_target to do the generation steps.
>
> 2.       Add the interface library in the same folder as the generation steps, managing its relationship with the code generation target via add_dependencies() meaning most of the code generation quirks are avoided.
>
> 3.       When adding executables or libraries in other folders just use target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )
>
> a.       Hoping that any transitive dependencies to the code generation steps would be handled by exe_name being dependent on MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES
>
> b.      Also hoping that I wouldn?t have to specify which files are code generated at that step
>
>
>
> I hope this makes sense.
>
>
>
> -Kris
>
>
> ________________________________
>
> IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

From elowe at elowe.com  Fri Jun 28 18:24:42 2019
From: elowe at elowe.com (Earle Lowe)
Date: Fri, 28 Jun 2019 15:24:42 -0700
Subject: [CMake] HP-UX ia64 (32bit) port
Message-ID: <CABGOUcwn=2ZBZTa=c5eto34v32yT_H1fxWa-PmKyuMkSdPe3Hg@mail.gmail.com>

I have made an HP-UX port for CMAKE 3.15

It's not entirely optimal, because I took a small shortcut on fsevents
in libuv by using the "no events" source also used by cygwin. HP-UX
does have /dev/poll, so I think the AIX code could be used as a
template for a proper implementation.

It runs --version, but I haven't tried to use it to make itself again,
or any other tests.

HP-UX  B.11.31 ia64 using GCC 9.4.3

The binaries are 32-bit

I didn't do this quite correctly because I didn't fork master and I
don't have a PR prepared.

If the community wants though, I can make a proper merge request

I'll note, getting GCC 9.4.3 working on HP-UX is actually harder than
porting cmake. This version of GCC has a fairly robust implementation
of C++11

-Earle