From forderud at gmail.com  Thu May  2 03:47:47 2019
From: forderud at gmail.com (Fredrik Orderud)
Date: Thu, 2 May 2019 09:47:47 +0200
Subject: [CMake] MSVC: How to configure manifest settings?
Message-ID: <CAHGmiitZR8A2D0nRz2Lj7YRtGBo5U25N0YEjNTgWH7GPtiy9rw@mail.gmail.com>

Hi,
I'm working on a project where I need to configure non-default
manifest settings when building on Windows. More specifically, I need
to inject the following tags in the generated vcxproj project:
<Manifest>
  <ComponentFileName>$(TargetName)$(TargetExt)</ComponentFileName>
  <RegistrarScriptFile>AdditionalRegEntries.rgs</RegistrarScriptFile>
</Manifest>

Any advise on how to achieve this from CMake?

I've already thought about writing a custom script to modify the
generated vcxproj file, but want to avoid that if possible.

Thanks in advance,
Fredrik Orderud

From d3ck0r at gmail.com  Thu May  2 04:18:58 2019
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 2 May 2019 01:18:58 -0700
Subject: [CMake] MSVC: How to configure manifest settings?
In-Reply-To: <CAHGmiitZR8A2D0nRz2Lj7YRtGBo5U25N0YEjNTgWH7GPtiy9rw@mail.gmail.com>
References: <CAHGmiitZR8A2D0nRz2Lj7YRtGBo5U25N0YEjNTgWH7GPtiy9rw@mail.gmail.com>
Message-ID: <CAA2GJqUD2k4xpXQ45nF4pBXvuyiso4oBqtvpjTJ85HuEJJiVUA@mail.gmail.com>

Depends on your generator.  It can be as simple as including the .manifest
in your sources list.
Otherwise you may have to make an extra mt.exe invokation...

https://github.com/d3x0r/SACK/blob/master/src/utils/service/CMakeLists.txt#L42-L53


On Thu, May 2, 2019 at 12:48 AM Fredrik Orderud <forderud at gmail.com> wrote:

> Hi,
> I'm working on a project where I need to configure non-default
> manifest settings when building on Windows. More specifically, I need
> to inject the following tags in the generated vcxproj project:
> <Manifest>
>   <ComponentFileName>$(TargetName)$(TargetExt)</ComponentFileName>
>   <RegistrarScriptFile>AdditionalRegEntries.rgs</RegistrarScriptFile>
> </Manifest>
>
> Any advise on how to achieve this from CMake?
>
> I've already thought about writing a custom script to modify the
> generated vcxproj file, but want to avoid that if possible.
>
> Thanks in advance,
> Fredrik Orderud
> --
>
> 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/20190502/f0c8ff06/attachment.html>

From ardillasdelmonte at gmail.com  Thu May  2 09:10:39 2019
From: ardillasdelmonte at gmail.com (ardi)
Date: Thu, 2 May 2019 15:10:39 +0200
Subject: [CMake] Forcing finding FreeGLUT instead of the system GLUT on MacOS
Message-ID: <CA+fZqCUfHt6qc1oR812jWXVGnWzc2mjgq2qt8i4RhSZF_ByBVQ@mail.gmail.com>

Hi,

I built and installed FreeGLUT in a custom location in my home
directory (Note: it's a custom location, but I also have pkg-config
installed on my PATH, and I did set it up so that when I do
'pkg-config --list-all' it successfully detects FreeGLUT in the
location where I installed it).

Now I'm trying to build a project that has find_package(GLUT REQUIRED)
and, as I would expect, it detects the system GLUT that comes standard
with MacOS. But for this particular build, I want it to find FreeGLUT
instead of the system GLUT. How can I force finding FreeGLUT?

Thanks a lot in advance,

ardi

From Alan.W.Irwin1234 at gmail.com  Sat May  4 13:14:54 2019
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Sat, 4 May 2019 10:14:54 -0700 (PDT)
Subject: [CMake] Forcing finding FreeGLUT instead of the system GLUT on
 MacOS
In-Reply-To: <CA+fZqCUfHt6qc1oR812jWXVGnWzc2mjgq2qt8i4RhSZF_ByBVQ@mail.gmail.com>
References: <CA+fZqCUfHt6qc1oR812jWXVGnWzc2mjgq2qt8i4RhSZF_ByBVQ@mail.gmail.com>
Message-ID: <nycvar.QRO.7.76.1905041002580.17916@zreyva.zlyna.ubzr>

On 2019-05-02 15:10+0200 ardi wrote:

> Hi,
>
> I built and installed FreeGLUT in a custom location in my home
> directory (Note: it's a custom location, but I also have pkg-config
> installed on my PATH, and I did set it up so that when I do
> 'pkg-config --list-all' it successfully detects FreeGLUT in the
> location where I installed it).
>
> Now I'm trying to build a project that has find_package(GLUT REQUIRED)
> and, as I would expect, it detects the system GLUT that comes standard
> with MacOS. But for this particular build, I want it to find FreeGLUT
> instead of the system GLUT. How can I force finding FreeGLUT?
>
> Thanks a lot in advance,

Hi ardi:

In your cmake installation take a look at

$PREFIX/share/cmake-3.14/Modules/FindGLUT.cmake

where you will find no mention of PkgConfig, i.e., CMake does not
use pkg-config to find GLUT.  Instead, it uses native CMake find
methods which are documented at e.g., <https://cmake.org/cmake/help/latest/command/find_path.html>.
And if you look into that documentation you can find a number of
environment variables that control which GLUT installation location is found
such as CMAKE_PREFIX_PATH.

Hope that helps.

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.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From stryku2393 at gmail.com  Sun May  5 19:48:32 2019
From: stryku2393 at gmail.com (stryku_t)
Date: Mon, 6 May 2019 01:48:32 +0200
Subject: [CMake] CMakeSL - a project that I've been working on
Message-ID: <CAGgDfCxutcfuU0RjBD36M=XeEhsvh-kd8vC6Sd_my6mtnpG47A@mail.gmail.com>

Hello everyone,

I've been working on a project related to CMake. I wrote an article
explaining everything.
Feel free to check it out and tell me what do you think.
https://gist.github.com/stryku/50903f147c899a84c20515a6bc5fab97

Best regards,
Mateusz Janek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190506/b5ccf767/attachment.html>

From tadeusz.kadlubowski at pix4d.com  Mon May  6 10:44:22 2019
From: tadeusz.kadlubowski at pix4d.com (=?UTF-8?Q?Tadeusz_A=2E_Kad=C5=82ubowski?=)
Date: Mon, 6 May 2019 16:44:22 +0200
Subject: [CMake] Problem with foreach() iteration over a list that uses
 generator expressions
Message-ID: <CACPawCp_5Ch3P0uTTW+dors=n9J3USaza4d-n0uH+g8V0u1vPA@mail.gmail.com>

Hi,

I apologize for initially sending this message to
cmake-developers at cmake.org, rather than here. I was confused and
mistook the proper mailing list.

I have an `INTERFACE IMPORTED` library target that depends on a bunch
of optional dependencies. Please see the snippet below:

cmake_minimum_required(VERSION 3.14)

add_library(example INTERFACE IMPORTED)
set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
$<$<CONFIG:Debug>:${undefined_dependency_one}
${undefined_dependency_two}>
)

It so happens that both of the optional dependencies
`${undefined_dependency_one}` and `${undefined_dependency_two}` are
set to empty/undefined on my system, which is perfectly fine.

I want to do some postprocessing to the dependencies  of my target:

get_target_property(all_dependencies example INTERFACE_LINK_LIBRARIES)
foreach(lib IN LISTS all_dependencies)
    message(STATUS "dependency on " ${lib})
endforeach()

This `foreach()` loop gets confused about the generator expression.
The output of the `message(STATUS ...)` calls in the snippet above is:

-- dependency on $<$<CONFIG:Debug>:
-- dependency on >

Please note that the generator expression got mangled into two pieces
by the `foreach()` loop. I was expecting to see a single line of
`$<$<CONFIG:Debug>:>`

I experimented with different versions of this test case and found
variants that do not get mangled in the `foreach()` loop. In a
modification when there is only one empty/undefined dependency the
`foreach()` loop works as expected.

set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
$<$<CONFIG:Debug>:${undefined_dependency_one}>
)

A modification in which each empty/undefined dependency is surrounded
with its own generator expression works correctly too:

set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
$<$<CONFIG:Debug>:${undefined_dependency_one}>
$<$<CONFIG:Debug>:${undefined_dependency_two}>
)

Is that a bug in how CMake handles generator expressions? Am I
misunderstanding some CMake language concepts here?

(all code tested with CMake 3.14.3 on Ubuntu 18.04)

I would be grateful on any feedback about what's going on in that
`foreach` loop.
--

Tadeusz Andrzej Kad?ubowski | Senior Software Engineer
Berlin, Germany
tadeusz.kadlubowski at pix4d.com
www.pix4d.com



-- 
Tadeusz Andrzej Kad?ubowski | Senior Software Engineer
Berlin, Germany
tadeusz.kadlubowski at pix4d.com
www.pix4d.com

From campoverdeangelf at gmail.com  Mon May  6 19:15:13 2019
From: campoverdeangelf at gmail.com (Angel Campoverde)
Date: Mon, 6 May 2019 18:15:13 -0500
Subject: [CMake] c++2a
Message-ID: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>

Hello,

I am looking at:

https://cmake.org/cmake/help/v3.14/prop_tgt/CXX_STANDARD.html

and I see that I can pass 20, for c++20. However I do not have that in my
compiler, I only have c++2a and gnu++2a, this means that CMake goes back to
c++17 and macros like __VA_OPT__:

https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

can't  be used. I know that all this should work, because I can compile
myself a small test piece of code with:

g++ code.cxx -o code -std=c++2a

so the problems is CMake. Is there a way to go around this?

Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190506/790a5aeb/attachment.html>

From mateusz at loskot.net  Tue May  7 03:32:26 2019
From: mateusz at loskot.net (Mateusz Loskot)
Date: Tue, 7 May 2019 09:32:26 +0200
Subject: [CMake] c++2a
In-Reply-To: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
Message-ID: <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>

On Tue, 7 May 2019 at 01:15, Angel Campoverde
<campoverdeangelf at gmail.com> wrote:
>
> I am looking at:
>
> https://cmake.org/cmake/help/v3.14/prop_tgt/CXX_STANDARD.html
>
> and I see that I can pass 20, for c++20. However I do not have that in my compiler,
> I only have c++2a and gnu++2a, this means that CMake goes back to c++17

No, it doesn't mean that.

The valid values documented for CXX_STANDARD are CMake generalisation
and not what is directly passed via -std= or /std: or whatever option
your compiler uses.

If you run this cmake command
cmake -DCMAKE_CXX_STANDARD=20 -DCMAKE_CXX_EXTENSIONS=OFF ..
and then
VERBOSE=1 make
you will clearly see that CMake generated the compiler
command lines with -std=c++2a

IFF, you are using version of GCC or clang that supports c++2a, obviously
(i.e. GCC 8/clang 6 or later. I'm not entirely confident about clang)

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From dmacq at instantiations.com  Tue May  7 12:19:31 2019
From: dmacq at instantiations.com (Donald MacQueen [|])
Date: Tue, 7 May 2019 12:19:31 -0400
Subject: [CMake] CDash grid display disappeared
Message-ID: <e8ca80a3-ae02-f99f-c079-45a52aa7699c@instantiations.com>

I was on vacation last week, so testing resumed Monday. All of the seven 
machines running CTests say they are reporting their results to the 
CDash server, and on the CDash machine I can see results like:

33 minutes ago: 1 test failed on Machine 3

1 hour ago: 23 tests failed on Machine 7,

etc.

But the grid/spreadsheet is gone, and I can't figure out how to get it 
to display again.

Thanks in advance.

-- 
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 campoverdeangelf at gmail.com  Tue May  7 12:24:05 2019
From: campoverdeangelf at gmail.com (Angel Campoverde)
Date: Tue, 7 May 2019 11:24:05 -0500
Subject: [CMake] c++2a
In-Reply-To: <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
 <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
Message-ID: <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>

Hi,

No, It does not work, I told Cmake to use c++ 20, but it still goes back to
c++17. You can see what I get here:

https://pastebin.com/5ub18cMU

my CMakeLists.txt is here:

https://pastebin.com/3bwMKrWB

do you know what could be the problem?

Cheers.

On Tue, May 7, 2019 at 2:33 AM Mateusz Loskot <mateusz at loskot.net> wrote:

> On Tue, 7 May 2019 at 01:15, Angel Campoverde
> <campoverdeangelf at gmail.com> wrote:
> >
> > I am looking at:
> >
> > https://cmake.org/cmake/help/v3.14/prop_tgt/CXX_STANDARD.html
> >
> > and I see that I can pass 20, for c++20. However I do not have that in
> my compiler,
> > I only have c++2a and gnu++2a, this means that CMake goes back to c++17
>
> No, it doesn't mean that.
>
> The valid values documented for CXX_STANDARD are CMake generalisation
> and not what is directly passed via -std= or /std: or whatever option
> your compiler uses.
>
> If you run this cmake command
> cmake -DCMAKE_CXX_STANDARD=20 -DCMAKE_CXX_EXTENSIONS=OFF ..
> and then
> VERBOSE=1 make
> you will clearly see that CMake generated the compiler
> command lines with -std=c++2a
>
> IFF, you are using version of GCC or clang that supports c++2a, obviously
> (i.e. GCC 8/clang 6 or later. I'm not entirely confident about clang)
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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/20190507/e13dc129/attachment.html>

From robert.maynard at kitware.com  Tue May  7 13:39:44 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 7 May 2019 13:39:44 -0400
Subject: [CMake] c++2a
In-Reply-To: <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
 <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
 <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
Message-ID: <CAFzjYVqoVGtqrDXqfeWGej18RvH57kZAQ1R3+pTsQe6U-2oZuw@mail.gmail.com>

CMake hasn't been updated to be aware that XCode 10 added support for
C++20 (via -std=c++2a). I have opened a MR to correct this which you
can track at: https://gitlab.kitware.com/cmake/cmake/merge_requests/3294

On Tue, May 7, 2019 at 12:24 PM Angel Campoverde
<campoverdeangelf at gmail.com> wrote:
>
> Hi,
>
> No, It does not work, I told Cmake to use c++ 20, but it still goes back to c++17. You can see what I get here:
>
> https://pastebin.com/5ub18cMU
>
> my CMakeLists.txt is here:
>
> https://pastebin.com/3bwMKrWB
>
> do you know what could be the problem?
>
> Cheers.
>
> On Tue, May 7, 2019 at 2:33 AM Mateusz Loskot <mateusz at loskot.net> wrote:
>>
>> On Tue, 7 May 2019 at 01:15, Angel Campoverde
>> <campoverdeangelf at gmail.com> wrote:
>> >
>> > I am looking at:
>> >
>> > https://cmake.org/cmake/help/v3.14/prop_tgt/CXX_STANDARD.html
>> >
>> > and I see that I can pass 20, for c++20. However I do not have that in my compiler,
>> > I only have c++2a and gnu++2a, this means that CMake goes back to c++17
>>
>> No, it doesn't mean that.
>>
>> The valid values documented for CXX_STANDARD are CMake generalisation
>> and not what is directly passed via -std= or /std: or whatever option
>> your compiler uses.
>>
>> If you run this cmake command
>> cmake -DCMAKE_CXX_STANDARD=20 -DCMAKE_CXX_EXTENSIONS=OFF ..
>> and then
>> VERBOSE=1 make
>> you will clearly see that CMake generated the compiler
>> command lines with -std=c++2a
>>
>> IFF, you are using version of GCC or clang that supports c++2a, obviously
>> (i.e. GCC 8/clang 6 or later. I'm not entirely confident about clang)
>>
>> Best regards,
>> --
>> Mateusz Loskot, http://mateusz.loskot.net
>> --
>>
>> 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

From mateusz at loskot.net  Tue May  7 14:04:02 2019
From: mateusz at loskot.net (Mateusz Loskot)
Date: Tue, 7 May 2019 20:04:02 +0200
Subject: [CMake] c++2a
In-Reply-To: <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
 <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
 <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
Message-ID: <CABUeae_+Kj=PUKFVb2GUoCp2HyagT+9ihh6bkZ60OkQJVjStXA@mail.gmail.com>

On Tue, 7 May 2019 at 18:24, Angel Campoverde
<campoverdeangelf at gmail.com> wrote:
>
> No, It does not work, I told Cmake to use c++ 20, but it still goes back to c++17. You can see what I get here:
>
> https://pastebin.com/5ub18cMU

Next time, please specify what compiler you are using.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From campoverdeangelf at gmail.com  Tue May  7 14:37:34 2019
From: campoverdeangelf at gmail.com (Angel Campoverde)
Date: Tue, 7 May 2019 13:37:34 -0500
Subject: [CMake] c++2a
In-Reply-To: <CABUeae_+Kj=PUKFVb2GUoCp2HyagT+9ihh6bkZ60OkQJVjStXA@mail.gmail.com>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
 <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
 <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
 <CABUeae_+Kj=PUKFVb2GUoCp2HyagT+9ihh6bkZ60OkQJVjStXA@mail.gmail.com>
Message-ID: <CAJ22+4QmL47eoxPmZj7VhjrxmiXZnD5-LMDhsLE-1Ks357pmsA@mail.gmail.com>

Next time please ask what computer I am using.

On Tue, May 7, 2019 at 1:04 PM Mateusz Loskot <mateusz at loskot.net> wrote:

> On Tue, 7 May 2019 at 18:24, Angel Campoverde
> <campoverdeangelf at gmail.com> wrote:
> >
> > No, It does not work, I told Cmake to use c++ 20, but it still goes back
> to c++17. You can see what I get here:
> >
> > https://pastebin.com/5ub18cMU
>
> Next time, please specify what compiler you are using.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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/20190507/abafe690/attachment.html>

From mateusz at loskot.net  Tue May  7 14:40:48 2019
From: mateusz at loskot.net (Mateusz Loskot)
Date: Tue, 7 May 2019 20:40:48 +0200
Subject: [CMake] c++2a
In-Reply-To: <CAJ22+4QmL47eoxPmZj7VhjrxmiXZnD5-LMDhsLE-1Ks357pmsA@mail.gmail.com>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
 <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
 <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
 <CABUeae_+Kj=PUKFVb2GUoCp2HyagT+9ihh6bkZ60OkQJVjStXA@mail.gmail.com>
 <CAJ22+4QmL47eoxPmZj7VhjrxmiXZnD5-LMDhsLE-1Ks357pmsA@mail.gmail.com>
Message-ID: <CABUeae9rCFiy4SimyiRodGST8DGip6yvmdp0CFfxg_gESkBiiA@mail.gmail.com>

On Tue, 7 May 2019 at 20:38, Angel Campoverde
<campoverdeangelf at gmail.com> wrote:
> Next time please ask what computer I am using.

CMake results are intrinsically compiler-specific.
Your issue is compiler-specific.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

p.s. Please, stop it.

From razvyboy2004 at gmail.com  Tue May  7 14:47:14 2019
From: razvyboy2004 at gmail.com (Maris Razvan)
Date: Tue, 7 May 2019 21:47:14 +0300
Subject: [CMake] Can arguments in an command invocation end in a line
 comment?
Message-ID: <CAKwWByuHcYDsuuotev-5OjJKB=uLnOn7wokSW=o9JfR-yqT8dQ@mail.gmail.com>

In the latest CMake documentation, the "language" section, the "Source
Files" paragraph there is the following sentence:

    "Note that any source file line not inside Command Arguments or a
Bracket Comment can end in a Line Comment."

I think that source file lines inside "Command Arguments" can end in a
"Line Comment" because the grammar specified in the "Command
Invocations" paragraph states that a "line_ending" (which may contain
a "line_comment") can separate arguments.

Also, the following code snippet works as expected in cmake 3.11.4:

    foreach(arg arg1
                     arg2 #line-comment
               )
      message("${arg}")
    endforeach()

Am I misunderstanding the above quote or is it inaccurate?

Thank you!

From hex7c3 at gmail.com  Tue May  7 17:41:57 2019
From: hex7c3 at gmail.com (hex)
Date: Tue, 7 May 2019 22:41:57 +0100
Subject: [CMake] how to fetch a git submodule for a build target?
In-Reply-To: <fbb9c683-026d-2b80-6d5b-7e264f2c1698@gmail.com>
References: <fbb9c683-026d-2b80-6d5b-7e264f2c1698@gmail.com>
Message-ID: <2c37ae63-e4e7-dfe8-2900-b1322cb1f4dd@gmail.com>

hello,
>
> I am using the following command to add a git submodule to an existing 
> repository:
>
>
> add_custom_command(OUTPUT fetch
>
> ? COMMAND git submodule add https://github.com/user/repo.git
>
> )
>
> add_custom_target(new DEPENDS fetch)
>
>
> This is working as intended. Adding an already existing submodule to 
> the repo does not present any problem by git, as for my build system 
> though it results in an error and the build target fails.
>
>
> how can I make the build fail gracefully?
>
>
> thank you in advance
>

From razvyboy2004 at gmail.com  Tue May  7 17:52:38 2019
From: razvyboy2004 at gmail.com (Maris Razvan)
Date: Wed, 8 May 2019 00:52:38 +0300
Subject: [CMake] Can arguments in an command invocation end in a line
 comment?
In-Reply-To: <CAKwWByuHcYDsuuotev-5OjJKB=uLnOn7wokSW=o9JfR-yqT8dQ@mail.gmail.com>
References: <CAKwWByuHcYDsuuotev-5OjJKB=uLnOn7wokSW=o9JfR-yqT8dQ@mail.gmail.com>
Message-ID: <CAKwWByuVFc=Q3ZaPgF2N8YwrYTu3LhhpXE7QrQJWOmjoYCxfSA@mail.gmail.com>

I apologize for the spelling error in the subject of this thread.

I was told that this sentence actually states that lines inside a
(single) command argument cannot end in a line comment.
I initially thought that "Command Arguments" in this sentence means
the "section" that contains all the arguments in a command invocation,
as the wording implies that there may be multiple lines inside the
referred "Command Arguments".
However, a bracketed or a quoted argument can span several lines, so
the sentence means that one cannot have comments in a bracketed or
quoted argument (the grammar does not allow unescaped "#" inside an
unquoted argument, so I think the sentence does not refer to this
case).

Is this correct?

On Tue, May 7, 2019 at 9:47 PM Maris Razvan <razvyboy2004 at gmail.com> wrote:
>
> In the latest CMake documentation, the "language" section, the "Source
> Files" paragraph there is the following sentence:
>
>     "Note that any source file line not inside Command Arguments or a
> Bracket Comment can end in a Line Comment."
>
> I think that source file lines inside "Command Arguments" can end in a
> "Line Comment" because the grammar specified in the "Command
> Invocations" paragraph states that a "line_ending" (which may contain
> a "line_comment") can separate arguments.
>
> Also, the following code snippet works as expected in cmake 3.11.4:
>
>     foreach(arg arg1
>                      arg2 #line-comment
>                )
>       message("${arg}")
>     endforeach()
>
> Am I misunderstanding the above quote or is it inaccurate?
>
> Thank you!

From kyle.edwards at kitware.com  Tue May  7 17:59:58 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Tue, 07 May 2019 17:59:58 -0400
Subject: [CMake] Can arguments in an command invocation end in a line
 comment?
In-Reply-To: <CAKwWByuVFc=Q3ZaPgF2N8YwrYTu3LhhpXE7QrQJWOmjoYCxfSA@mail.gmail.com>
References: <CAKwWByuHcYDsuuotev-5OjJKB=uLnOn7wokSW=o9JfR-yqT8dQ@mail.gmail.com>
 <CAKwWByuVFc=Q3ZaPgF2N8YwrYTu3LhhpXE7QrQJWOmjoYCxfSA@mail.gmail.com>
Message-ID: <1557266398.2992.6.camel@kitware.com>

On Wed, 2019-05-08 at 00:52 +0300, Maris Razvan wrote:
I apologize for the spelling error in the subject of this thread.


I was told that this sentence actually states that lines inside a
(single) command argument cannot end in a line comment.
I initially thought that "Command Arguments" in this sentence means
the "section" that contains all the arguments in a command
invocation,
as the wording implies that there may be multiple lines inside the
referred "Command Arguments".
However, a bracketed or a quoted argument can span several lines, so
the sentence means that one cannot have comments in a bracketed or
quoted argument (the grammar does not allow unescaped "#" inside an
unquoted argument, so I think the sentence does not refer to this
case).


Is this correct?

This is valid:

my_command(
? ARG1 # This comment is not part of an argument
? ? # Neither is this
? ARG2
? )

This is also valid:

my_command(
? "ARG1
? ? # But this comment IS part of an argument
? ? "
? [==[ARG2
? ? # And so is this
? ? ]==]
? )

Hope that helps,

Kyle

From zehner.paul at jaxa.jp  Tue May  7 23:01:49 2019
From: zehner.paul at jaxa.jp (=?iso-2022-jp?B?WmVobmVyGyRCISEbKEJQYXVs?=)
Date: Wed, 8 May 2019 03:01:49 +0000
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>,
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
Message-ID: <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>

Robert,

Thank you for the advice.

As I want to take account of compiler version, I overrided the `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in the folder of `CMAKE_MODULE_PATH`. However, the installation `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should I do?

Best regards,


--

Paul Zehner, Ph. D.

Invited Researcher

Numerical Simulation Research Unit

Japan Aerospace Exploration Agency

7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo

182-8522, Japan

Tel. +81-50-3362-7933

Fax. +81-422-40-3327

zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp>

www.jaxa.jp<http://www.jaxa.jp>

________________________________
From: Robert Maynard <robert.maynard at kitware.com>
Sent: Friday, April 26, 2019 23:32
To: Zehner?Paul
Cc: Kai Wolf; cmake at cmake.org
Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler

For an initial implementation I would base the work on the PGI
compiler module (
https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
) not the GNU-CXX module.
This will allow you to add a new compiler with only meta-language
flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
having to manually build the feature tables.

On Fri, Apr 26, 2019 at 3:58 AM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
>
> Kai,
>
>
> Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration.
>
>
> If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request.
>
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp<http://www.jaxa.jp>
>
>
>
> ________________________________
> From: Kai Wolf <kai.wolf at gmail.com>
> Sent: Friday, April 26, 2019 16:22
> To: Zehner?Paul
> Cc: cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake
> file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust
> *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
>
> I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which
> you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
>
>
> Greetings,
>
> Kai
>
> http://kai-wolf.me
> http://effective-cmake.com
>
> Am 26.04.2019 um 07:35 schrieb Zehner?Paul <zehner.paul at jaxa.jp>:
>
> Hello Cmake community,
>
> I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler.
>
> I tested it on a simple project, and the line:
>
> ```cmake
> target_compile_features(test PUBLIC cxx_std_11)
> ```
>
> fails with this message:
>
> ```
> CMake Error at CMakeLists.txt:15 (target_compile_features):
>   target_compile_features no known features for CXX compiler
>
>   "Fujitsu"
>
>   version .
>
> ```
>
> So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features:
>
> ```cmake
> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> project(foobar CXX)
> message("Your C++ compiler supports these C++ features:")
> foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
>     message("${i}")
> endforeach()
> ```
>
> and no feature are listed.
>
> So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu?
>
> Thanks for your help,
>
> --
> Paul Zehner, Ph. D.
> Invited Researcher
> Numerical Simulation Research Unit
> Japan Aerospace Exploration Agency
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> 182-8522, Japan
> Tel. +81-50-3362-7933
> Fax. +81-422-40-3327
> zehner.paul at jaxa.jp
> www.jaxa.jp<http://www.jaxa.jp>
> --
>
> 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
>
>
> --
>
> 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/20190508/bd8c35ab/attachment-0001.html>

From cary at txcorp.com  Wed May  8 07:27:21 2019
From: cary at txcorp.com (JR Cary)
Date: Wed, 8 May 2019 07:27:21 -0400
Subject: [CMake] CMake with two C++ compilers
Message-ID: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>

Is there a standard way to deal with 2 C++ compilers?? Getting both
there versions, etc.?

I need one compiler for compiling ordinary C++ code and a different
one to use as the host compiler for CUDA.

Thx......John Cary

From hex7c3 at gmail.com  Wed May  8 07:38:23 2019
From: hex7c3 at gmail.com (Hex)
Date: Wed, 8 May 2019 04:38:23 -0700 (MST)
Subject: [CMake] CMake with two C++ compilers
In-Reply-To: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
References: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
Message-ID: <1557315503912-0.post@n2.nabble.com>

set the compiler for each build:

set(COMPILER /opt/gcc/bin)
cmake_force_c_compiler(  "${COMPILER}gcc" GNU)
cmake_force_cxx_compiler("${COMPILER}g++" GNU)



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

From sergey.nikulov at gmail.com  Wed May  8 09:23:12 2019
From: sergey.nikulov at gmail.com (Sergei Nikulov)
Date: Wed, 8 May 2019 16:23:12 +0300
Subject: [CMake] CMake with two C++ compilers
In-Reply-To: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
References: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
Message-ID: <CAE7Ac0AS7ZyGDEb9Pt65D+RcRL3PS526WJwPLZkPN0iDxBpwrw@mail.gmail.com>

??, 8 ??? 2019 ?. ? 14:27, JR Cary <cary at txcorp.com>:
>
> Is there a standard way to deal with 2 C++ compilers?  Getting both
> there versions, etc.?
>
> I need one compiler for compiling ordinary C++ code and a different
> one to use as the host compiler for CUDA.
>
> Thx......John Cary

Here is the exact answer to your question
https://devblogs.nvidia.com/building-cuda-applications-cmake/


-- 
Best Regards,
Sergei Nikulov

From robert.maynard at kitware.com  Wed May  8 14:12:45 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 8 May 2019 14:12:45 -0400
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
 <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>
Message-ID: <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>

I believe the only way is to have your version of
Fujitsu-DetermineCompiler.cmake be installed over the one provided by
CMake. When it comes to known compilers CMake explicitly includes the
version it ships.

On Tue, May 7, 2019 at 11:01 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
>
> Robert,
>
> Thank you for the advice.
>
> As I want to take account of compiler version, I overrided the `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in the folder of `CMAKE_MODULE_PATH`. However, the installation `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should I do?
>
> Best regards,
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp
>
> ________________________________
> From: Robert Maynard <robert.maynard at kitware.com>
> Sent: Friday, April 26, 2019 23:32
> To: Zehner?Paul
> Cc: Kai Wolf; cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> For an initial implementation I would base the work on the PGI
> compiler module (
> https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> ) not the GNU-CXX module.
> This will allow you to add a new compiler with only meta-language
> flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> having to manually build the feature tables.
>
> On Fri, Apr 26, 2019 at 3:58 AM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> >
> > Kai,
> >
> >
> > Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration.
> >
> >
> > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request.
> >
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.paul at jaxa.jp
> >
> > www.jaxa.jp
> >
> >
> >
> > ________________________________
> > From: Kai Wolf <kai.wolf at gmail.com>
> > Sent: Friday, April 26, 2019 16:22
> > To: Zehner?Paul
> > Cc: cmake at cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake
> > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust
> > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> >
> > I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which
> > you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> >
> >
> > Greetings,
> >
> > Kai
> >
> > http://kai-wolf.me
> > http://effective-cmake.com
> >
> > Am 26.04.2019 um 07:35 schrieb Zehner?Paul <zehner.paul at jaxa.jp>:
> >
> > Hello Cmake community,
> >
> > I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler.
> >
> > I tested it on a simple project, and the line:
> >
> > ```cmake
> > target_compile_features(test PUBLIC cxx_std_11)
> > ```
> >
> > fails with this message:
> >
> > ```
> > CMake Error at CMakeLists.txt:15 (target_compile_features):
> >   target_compile_features no known features for CXX compiler
> >
> >   "Fujitsu"
> >
> >   version .
> >
> > ```
> >
> > So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features:
> >
> > ```cmake
> > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > project(foobar CXX)
> > message("Your C++ compiler supports these C++ features:")
> > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> >     message("${i}")
> > endforeach()
> > ```
> >
> > and no feature are listed.
> >
> > So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu?
> >
> > Thanks for your help,
> >
> > --
> > Paul Zehner, Ph. D.
> > Invited Researcher
> > Numerical Simulation Research Unit
> > Japan Aerospace Exploration Agency
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > 182-8522, Japan
> > Tel. +81-50-3362-7933
> > Fax. +81-422-40-3327
> > zehner.paul at jaxa.jp
> > www.jaxa.jp
> > --
> >
> > 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

From zehner.paul at jaxa.jp  Wed May  8 22:15:06 2019
From: zehner.paul at jaxa.jp (=?iso-2022-jp?B?WmVobmVyGyRCISEbKEJQYXVs?=)
Date: Thu, 9 May 2019 02:15:06 +0000
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
 <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>,
 <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>
Message-ID: <TY1PR01MB1883FA83D31C6111C15E1016F4330@TY1PR01MB1883.jpnprd01.prod.outlook.com>

Thank you for your answer.

This means I have to override `/usr/share/cmake/Modules/Compiler/Fujitsu-DetermineCompiler.cmake`? This is not unfeasible, but it may seems tricky to my users. Since detecting compiler version is not a crucial task, maybe I will keep this file as it and concentrate on other ones.

Another question I have is regarding MPI. The `find_package(MPI REQUIRED)` directive fails with "Could NOT find MPI (missing: MPI_CXX_FOUND)". I have no clue on how to help the detection of MPI. The compiler I give to CMake is actually an MPI wrapper that only needs one argument to enable MPI features. I tried with some exotic-named GCC compilers at my lab (which are MPI wrappers as well) and it could detect MPI with no problem. Where should I start?

Best regards,


--

Paul Zehner, Ph. D.

Invited Researcher

Numerical Simulation Research Unit

Japan Aerospace Exploration Agency

7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo

182-8522, Japan

Tel. +81-50-3362-7933

Fax. +81-422-40-3327

zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp>

www.jaxa.jp<http://www.jaxa.jp>

________________________________
From: Robert Maynard <robert.maynard at kitware.com>
Sent: Thursday, May 9, 2019 3:12
To: Zehner?Paul
Cc: Kai Wolf; cmake at cmake.org
Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler

I believe the only way is to have your version of
Fujitsu-DetermineCompiler.cmake be installed over the one provided by
CMake. When it comes to known compilers CMake explicitly includes the
version it ships.

On Tue, May 7, 2019 at 11:01 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
>
> Robert,
>
> Thank you for the advice.
>
> As I want to take account of compiler version, I overrided the `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in the folder of `CMAKE_MODULE_PATH`. However, the installation `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should I do?
>
> Best regards,
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp<http://www.jaxa.jp>
>
> ________________________________
> From: Robert Maynard <robert.maynard at kitware.com>
> Sent: Friday, April 26, 2019 23:32
> To: Zehner?Paul
> Cc: Kai Wolf; cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> For an initial implementation I would base the work on the PGI
> compiler module (
> https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> ) not the GNU-CXX module.
> This will allow you to add a new compiler with only meta-language
> flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> having to manually build the feature tables.
>
> On Fri, Apr 26, 2019 at 3:58 AM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> >
> > Kai,
> >
> >
> > Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration.
> >
> >
> > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request.
> >
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.paul at jaxa.jp
> >
> > www.jaxa.jp<http://www.jaxa.jp>
> >
> >
> >
> > ________________________________
> > From: Kai Wolf <kai.wolf at gmail.com>
> > Sent: Friday, April 26, 2019 16:22
> > To: Zehner?Paul
> > Cc: cmake at cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake
> > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust
> > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> >
> > I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which
> > you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> >
> >
> > Greetings,
> >
> > Kai
> >
> > http://kai-wolf.me
> > http://effective-cmake.com
> >
> > Am 26.04.2019 um 07:35 schrieb Zehner?Paul <zehner.paul at jaxa.jp>:
> >
> > Hello Cmake community,
> >
> > I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler.
> >
> > I tested it on a simple project, and the line:
> >
> > ```cmake
> > target_compile_features(test PUBLIC cxx_std_11)
> > ```
> >
> > fails with this message:
> >
> > ```
> > CMake Error at CMakeLists.txt:15 (target_compile_features):
> >   target_compile_features no known features for CXX compiler
> >
> >   "Fujitsu"
> >
> >   version .
> >
> > ```
> >
> > So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features:
> >
> > ```cmake
> > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > project(foobar CXX)
> > message("Your C++ compiler supports these C++ features:")
> > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> >     message("${i}")
> > endforeach()
> > ```
> >
> > and no feature are listed.
> >
> > So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu?
> >
> > Thanks for your help,
> >
> > --
> > Paul Zehner, Ph. D.
> > Invited Researcher
> > Numerical Simulation Research Unit
> > Japan Aerospace Exploration Agency
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > 182-8522, Japan
> > Tel. +81-50-3362-7933
> > Fax. +81-422-40-3327
> > zehner.paul at jaxa.jp
> > www.jaxa.jp<http://www.jaxa.jp>
> > --
> >
> > 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
> >
> >
> > --
> >
> > 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/20190509/24743f6f/attachment-0001.html>

From stefan at sfendt.de  Thu May  9 02:21:46 2019
From: stefan at sfendt.de (Stefan Fendt)
Date: Thu, 9 May 2019 08:21:46 +0200
Subject: [CMake] c++2a
In-Reply-To: <CAJ22+4QmL47eoxPmZj7VhjrxmiXZnD5-LMDhsLE-1Ks357pmsA@mail.gmail.com>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
 <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
 <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
 <CABUeae_+Kj=PUKFVb2GUoCp2HyagT+9ihh6bkZ60OkQJVjStXA@mail.gmail.com>
 <CAJ22+4QmL47eoxPmZj7VhjrxmiXZnD5-LMDhsLE-1Ks357pmsA@mail.gmail.com>
Message-ID: <b87aafcc-df74-519d-6175-5f7a9f421acc@sfendt.de>

Am 07.05.2019 um 20:37 schrieb Angel Campoverde:
> Next time please ask what computer I am using.

*What*? Really? *Please* give this a second thought...

Stefan


From hex7c3 at gmail.com  Thu May  9 05:22:29 2019
From: hex7c3 at gmail.com (hex)
Date: Thu, 9 May 2019 10:22:29 +0100
Subject: [CMake] c++2a
In-Reply-To: <b87aafcc-df74-519d-6175-5f7a9f421acc@sfendt.de>
References: <CAJ22+4SAwPwV6DRS_ecNLf27sS5r71o0g7TKphWpq9aBpjbp8g@mail.gmail.com>
 <CABUeae_qcjYyhDRnM=_QBjTDZ6o5LUda7fd8+DdfE=Q1iEuaUw@mail.gmail.com>
 <CAJ22+4S=rE95Q3mZ0QByHbfW2Fc-4NCATjPhu7B2BUvLJ4Erjg@mail.gmail.com>
 <CABUeae_+Kj=PUKFVb2GUoCp2HyagT+9ihh6bkZ60OkQJVjStXA@mail.gmail.com>
 <CAJ22+4QmL47eoxPmZj7VhjrxmiXZnD5-LMDhsLE-1Ks357pmsA@mail.gmail.com>
 <b87aafcc-df74-519d-6175-5f7a9f421acc@sfendt.de>
Message-ID: <7e829ad4-b4c1-084e-786a-2ed6e5dd6767@gmail.com>

ummh, sooo... h, do you like... cheese?

On 5/9/19 7:21 AM, Stefan Fendt wrote:
> Am 07.05.2019 um 20:37 schrieb Angel Campoverde:
>> Next time please ask what computer I am using.
> *What*? Really? *Please* give this a second thought...
>
> Stefan
>

From serg at suslenkov.com  Thu May  9 05:45:19 2019
From: serg at suslenkov.com (SergSuslenkov)
Date: Thu, 9 May 2019 02:45:19 -0700 (MST)
Subject: [CMake] Different behavior between building using "cmake
 --build" and building in Visual Studio
In-Reply-To: <f2eb4330c19f35c0d7f01bc35a0f97a3@appletonaudio.com>
References: <b2e7596c2408f13a93ac2d1f7365af55@appletonaudio.com>
 <CY4PR1001MB21823C95C5F5E3FEE55CE06DA99F0@CY4PR1001MB2182.namprd10.prod.outlook.com>
 <f2eb4330c19f35c0d7f01bc35a0f97a3@appletonaudio.com>
Message-ID: <1557395119592-0.post@n2.nabble.com>

Hi Nick,

Not sure if it is relevant for you, but for other who will search.

I have the same problem.
What I found:

1. When you issue "cmake --build", it runs following command line:
msbuild ALL_BUILD.vcxproj /p:Platform=Win32 ...

So it is not a solution file, that have rules to match configurations, but a
ALL_BUILD project file.

2. inside each *.vcxproj, there is a section(s)
    <ProjectReference Include=&quot;&lt;path_to>\ZERO_CHECK.vcxproj">
      <Project>{979FF7F1-351C-30B2-9F05-100EBC38B87E}</Project>
      <Name>ZERO_CHECK</Name>
    </ProjectReference>

  There is reference for each dependent projects.

3. ms build is using this information to build project and all its
dependencies.

4. however, <ProjectReference ..> does not contain configuration matching
rules (set with MAP_IMPORTED_CONFIG_XXX)

5. there is a way to specify configuration in ProjectReference, but VS
generator in CMake does not have this ability.
5.1. Way to specify:
https://stackoverflow.com/questions/6624168/configuration-for-projectreference-in-msbuild
<ProjectReference Include="path to project.projext">
  <SetPlatform>Platform=x64</SetPlatform>
  <SetConfiguration>Configuration=Release</SetConfiguration>
</ProjectReference>

Conclusion: I don't think that CMake can do it right now.
I plan to add Debug/Release targets on my proprietary provided projects.
Probably this can be address in future version of CMake.

Regards,
Serg



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

From robert.maynard at kitware.com  Thu May  9 10:29:12 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 9 May 2019 10:29:12 -0400
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <TY1PR01MB1883FA83D31C6111C15E1016F4330@TY1PR01MB1883.jpnprd01.prod.outlook.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
 <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>
 <TY1PR01MB1883FA83D31C6111C15E1016F4330@TY1PR01MB1883.jpnprd01.prod.outlook.com>
Message-ID: <CAFzjYVoNhiBP=WK+5OR_=KoQB0f0QoHE8Owz6WpspyvYt6Mqiw@mail.gmail.com>

The goal would be to upstream the compiler changes to cmake so that
all users could benefit from the improved compiler detection :)

I would look at the FindMPI docs on locating the correct mpi compiler:
https://cmake.org/cmake/help/v3.14/module/FindMPI.html#variables-for-locating-mpi
. It looks like what you will need to specify is
MPI_<lang>_COMPILER_FLAGS

On Wed, May 8, 2019 at 10:15 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
>
> Thank you for your answer.
>
> This means I have to override `/usr/share/cmake/Modules/Compiler/Fujitsu-DetermineCompiler.cmake`? This is not unfeasible, but it may seems tricky to my users. Since detecting compiler version is not a crucial task, maybe I will keep this file as it and concentrate on other ones.
>
> Another question I have is regarding MPI. The `find_package(MPI REQUIRED)` directive fails with "Could NOT find MPI (missing: MPI_CXX_FOUND)". I have no clue on how to help the detection of MPI. The compiler I give to CMake is actually an MPI wrapper that only needs one argument to enable MPI features. I tried with some exotic-named GCC compilers at my lab (which are MPI wrappers as well) and it could detect MPI with no problem. Where should I start?
>
> Best regards,
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp
>
> ________________________________
> From: Robert Maynard <robert.maynard at kitware.com>
> Sent: Thursday, May 9, 2019 3:12
> To: Zehner?Paul
> Cc: Kai Wolf; cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> I believe the only way is to have your version of
> Fujitsu-DetermineCompiler.cmake be installed over the one provided by
> CMake. When it comes to known compilers CMake explicitly includes the
> version it ships.
>
> On Tue, May 7, 2019 at 11:01 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> >
> > Robert,
> >
> > Thank you for the advice.
> >
> > As I want to take account of compiler version, I overrided the `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in the folder of `CMAKE_MODULE_PATH`. However, the installation `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should I do?
> >
> > Best regards,
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.paul at jaxa.jp
> >
> > www.jaxa.jp
> >
> > ________________________________
> > From: Robert Maynard <robert.maynard at kitware.com>
> > Sent: Friday, April 26, 2019 23:32
> > To: Zehner?Paul
> > Cc: Kai Wolf; cmake at cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > For an initial implementation I would base the work on the PGI
> > compiler module (
> > https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> > ) not the GNU-CXX module.
> > This will allow you to add a new compiler with only meta-language
> > flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> > having to manually build the feature tables.
> >
> > On Fri, Apr 26, 2019 at 3:58 AM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> > >
> > > Kai,
> > >
> > >
> > > Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration.
> > >
> > >
> > > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request.
> > >
> > >
> > > --
> > >
> > > Paul Zehner, Ph. D.
> > >
> > > Invited Researcher
> > >
> > > Numerical Simulation Research Unit
> > >
> > > Japan Aerospace Exploration Agency
> > >
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > >
> > > 182-8522, Japan
> > >
> > > Tel. +81-50-3362-7933
> > >
> > > Fax. +81-422-40-3327
> > >
> > > zehner.paul at jaxa.jp
> > >
> > > www.jaxa.jp
> > >
> > >
> > >
> > > ________________________________
> > > From: Kai Wolf <kai.wolf at gmail.com>
> > > Sent: Friday, April 26, 2019 16:22
> > > To: Zehner?Paul
> > > Cc: cmake at cmake.org
> > > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> > >
> > > If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake
> > > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust
> > > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> > >
> > > I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which
> > > you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> > >
> > >
> > > Greetings,
> > >
> > > Kai
> > >
> > > http://kai-wolf.me
> > > http://effective-cmake.com
> > >
> > > Am 26.04.2019 um 07:35 schrieb Zehner?Paul <zehner.paul at jaxa.jp>:
> > >
> > > Hello Cmake community,
> > >
> > > I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler.
> > >
> > > I tested it on a simple project, and the line:
> > >
> > > ```cmake
> > > target_compile_features(test PUBLIC cxx_std_11)
> > > ```
> > >
> > > fails with this message:
> > >
> > > ```
> > > CMake Error at CMakeLists.txt:15 (target_compile_features):
> > >   target_compile_features no known features for CXX compiler
> > >
> > >   "Fujitsu"
> > >
> > >   version .
> > >
> > > ```
> > >
> > > So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features:
> > >
> > > ```cmake
> > > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > > project(foobar CXX)
> > > message("Your C++ compiler supports these C++ features:")
> > > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> > >     message("${i}")
> > > endforeach()
> > > ```
> > >
> > > and no feature are listed.
> > >
> > > So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu?
> > >
> > > Thanks for your help,
> > >
> > > --
> > > Paul Zehner, Ph. D.
> > > Invited Researcher
> > > Numerical Simulation Research Unit
> > > Japan Aerospace Exploration Agency
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > > 182-8522, Japan
> > > Tel. +81-50-3362-7933
> > > Fax. +81-422-40-3327
> > > zehner.paul at jaxa.jp
> > > www.jaxa.jp
> > > --
> > >
> > > 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

From jstrecker-cmake at kosada.com  Thu May  9 14:33:28 2019
From: jstrecker-cmake at kosada.com (jstrecker-cmake at kosada.com)
Date: Thu, 9 May 2019 14:33:28 -0400
Subject: [CMake] How do you test partial rebuilds?
Message-ID: <F4C4317F-6878-45E2-B865-E8BBE6EB8909@kosada.com>

My team sometimes discovers bugs in our build system where modifying one particular file doesn't trigger a rebuild of some dependent file.

While our continuous integration system (Jenkins) catches problems when building the whole project, we don't currently have any way to detect problems with partial rebuilds ? other than developers getting temporarily confused when they make a change, rebuild, and don't see their change take effect.

As we're in the process of moving from qmake to CMake, now seems like a good time to add some tests of partial rebuilds.

Have you written similar tests? Did you use a shell script (touch, rebuild, grep), or are more advanced tools available?

[There was a similar question on this list from 2009 (https://cmake.org/pipermail/cmake/2009-February/026967.html), but the thread didn't answer our question.]

-Jaymie

From chuck.atkins at kitware.com  Fri May 10 11:17:15 2019
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Fri, 10 May 2019 11:17:15 -0400
Subject: [CMake] CMake with two C++ compilers
In-Reply-To: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
References: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
Message-ID: <CAOXZzG7UuVc0=Ac5LSLKHk=zthSFT01Q88ArturPB92OrM-WNg@mail.gmail.com>

Hi John,
Two different compilers in the same project for the same language is messy,
but in your case it's directly supproted as a special case for cuda using
the CMAKE_CUDA_HOST_COMPILER CMake variable or the CUDAHOSTCXX environment
variable.

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.


On Wed, May 8, 2019 at 7:27 AM JR Cary <cary at txcorp.com> wrote:

> Is there a standard way to deal with 2 C++ compilers?  Getting both
> there versions, etc.?
>
> I need one compiler for compiling ordinary C++ code and a different
> one to use as the host compiler for CUDA.
>
> Thx......John Cary
> --
>
> 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/20190510/788c5a7e/attachment.html>

From cary at txcorp.com  Fri May 10 12:09:26 2019
From: cary at txcorp.com (JR Cary)
Date: Fri, 10 May 2019 10:09:26 -0600
Subject: [CMake] CMake with two C++ compilers
In-Reply-To: <CAOXZzG7UuVc0=Ac5LSLKHk=zthSFT01Q88ArturPB92OrM-WNg@mail.gmail.com>
References: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
 <CAOXZzG7UuVc0=Ac5LSLKHk=zthSFT01Q88ArturPB92OrM-WNg@mail.gmail.com>
Message-ID: <75a9d767-b37b-0d68-2d51-0a0e5259003d@txcorp.com>

Thanks, Chuck.

I was not clear on my question, which is:? When I specify the two 
compilers, how
do I get, e.g., CMAKE_CUDA_HOST_COMPILER_ID and 
CMAKE_CUDA_HOST_COMPILER_VERSION?

I need these to determine consistency between the CUDA version and the 
host compiler
version, so that I can disable CUDA when these are incmpatible.

Thanks...John

On 5/10/19 9:17 AM, Chuck Atkins wrote:
> Hi John,
> Two different compilers in the same project for the same language is 
> messy, but in your case it's directly supproted as a special case for 
> cuda using the CMAKE_CUDA_HOST_COMPILER CMake variable or the 
> CUDAHOSTCXX environment variable.
>
> ----------
> Chuck Atkins
> Staff R&D Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Wed, May 8, 2019 at 7:27 AM JR Cary <cary at txcorp.com 
> <mailto:cary at txcorp.com>> wrote:
>
>     Is there a standard way to deal with 2 C++ compilers?? Getting both
>     there versions, etc.?
>
>     I need one compiler for compiling ordinary C++ code and a different
>     one to use as the host compiler for CUDA.
>
>     Thx......John Cary
>     -- 
>
>     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/20190510/a09f4c6b/attachment.html>

From dustyn at blasig.us  Fri May 10 13:06:35 2019
From: dustyn at blasig.us (Dustyn Blasig)
Date: Fri, 10 May 2019 12:06:35 -0500
Subject: [CMake] Split Build and Test Pipelines
Message-ID: <CAN4pPGXADDyTSbfZ8wxjyXkG4zn3eH9jPo6+4fTG-SVkA-UoBQ@mail.gmail.com>

Hi All,

I'm curious if anyone has had success allowing two testing paths to coexist
well.

Currently, we are using CTest to run our test executables with `make test`.
However, on our Jenkins system, the build machines have the whole
development stack but the test machines do not. So we need a way to package
up the tests in a way that the test machines can simply run some generated
script to do the equivalent of what CTest would do.

My current thought is to generate OS specific scripts `make test` depends
on and runs. These scripts can get installed through `make install` if
ENABLE_TEST_INSTALL is set, and then the test machine can run the installed
scripts. The tricky part is building up the hierarchy of scripts in such a
way that the tester just needs to run "test.sh" or "test.bat" at the
top-level of the install hierarchy.

Any comments and suggestions greatly appreciated!

Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190510/fac59b68/attachment.html>

From kyle.edwards at kitware.com  Fri May 10 13:22:31 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 10 May 2019 13:22:31 -0400
Subject: [CMake] Split Build and Test Pipelines
In-Reply-To: <CAN4pPGXADDyTSbfZ8wxjyXkG4zn3eH9jPo6+4fTG-SVkA-UoBQ@mail.gmail.com>
References: <CAN4pPGXADDyTSbfZ8wxjyXkG4zn3eH9jPo6+4fTG-SVkA-UoBQ@mail.gmail.com>
Message-ID: <1557508951.2992.9.camel@kitware.com>

On Fri, 2019-05-10 at 12:06 -0500, Dustyn Blasig wrote:
> Hi All,
> 
> I'm curious if anyone has had success allowing two testing paths to
> coexist well.
> 
> Currently, we are using CTest to run our test executables with `make
> test`. However, on our Jenkins system, the build machines have the
> whole development stack but the test machines do not. So we need a
> way to package up the tests in a way that the test machines can
> simply run some generated script to do the equivalent of what CTest
> would do.
> 
> My current thought is to generate OS specific scripts `make test`
> depends on and runs. These scripts can get installed through `make
> install` if ENABLE_TEST_INSTALL is set, and then the test machine can
> run the installed scripts. The tricky part is building up the
> hierarchy of scripts in such a way that the tester just needs to run
> "test.sh" or "test.bat" at the top-level of the install hierarchy.
> 
> Any comments and suggestions greatly?appreciated!
If you at least have CMake/CTest installed on the test machines (even
if you don't have compilers, libraries, etc.), then you can create a
CMake project that doesn't build any code, but instead runs tests
against a set of external executables.
The build process for CMake itself has a mechanism to do exactly this:
if you configure CMake with -DCMake_TEST_EXTERNAL_CMAKE=path/to/bin,
then it will execute the test suite against the external CMake
executable without building any code. You could do something similar in
your own project: add an option to instead run the test suite against
an set of external excutables instead of building them.
Hope that helps!
Kyle

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

From MillerHenry at JohnDeere.com  Fri May 10 13:57:03 2019
From: MillerHenry at JohnDeere.com (Miller Henry)
Date: Fri, 10 May 2019 17:57:03 +0000
Subject: [CMake] Split Build and Test Pipelines
In-Reply-To: <CAN4pPGXADDyTSbfZ8wxjyXkG4zn3eH9jPo6+4fTG-SVkA-UoBQ@mail.gmail.com>
References: <CAN4pPGXADDyTSbfZ8wxjyXkG4zn3eH9jPo6+4fTG-SVkA-UoBQ@mail.gmail.com>
Message-ID: <BL0PR05MB49794D2AFA5061D45A0BE5BDBE0C0@BL0PR05MB4979.namprd05.prod.outlook.com>

We have had luck packaging all the CTestTestFile.cmake files, and using sed to adjust paths for the target location.  You need to install ctest on the test machine, along with all the tests.

The only paths we change are the test output location (ie google test .xml files: this might not apply to you), and the path to the build directory.  Something like the following.

         sed -i ?s/$BUILD_DIR/@CTEST_TARGET_DIR@/g? $file

When running we first use configure_file in cmake to substitute CTEST_TARGET_DIR with whatever path things are installed to on the test machine.

From: CMake <cmake-bounces at cmake.org> On Behalf Of Dustyn Blasig
Sent: Friday, May 10, 2019 12:07 PM
To: CMake <cmake at cmake.org>
Subject: [CMake] Split Build and Test Pipelines

Hi All,

I'm curious if anyone has had success allowing two testing paths to coexist well.

Currently, we are using CTest to run our test executables with `make test`. However, on our Jenkins system, the build machines have the whole development stack but the test machines do not. So we need a way to package up the tests in a way that the test machines can simply run some generated script to do the equivalent of what CTest would do.

My current thought is to generate OS specific scripts `make test` depends on and runs. These scripts can get installed through `make install` if ENABLE_TEST_INSTALL is set, and then the test machine can run the installed scripts. The tricky part is building up the hierarchy of scripts in such a way that the tester just needs to run "test.sh" or "test.bat" at the top-level of the install hierarchy.

Any comments and suggestions greatly appreciated!

Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190510/64a43980/attachment-0001.html>

From robert.maynard at kitware.com  Fri May 10 16:20:46 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 10 May 2019 16:20:46 -0400
Subject: [CMake] CMake with two C++ compilers
In-Reply-To: <75a9d767-b37b-0d68-2d51-0a0e5259003d@txcorp.com>
References: <ced3c49c-1c54-d417-8c4b-c3d5b15cb8e1@txcorp.com>
 <CAOXZzG7UuVc0=Ac5LSLKHk=zthSFT01Q88ArturPB92OrM-WNg@mail.gmail.com>
 <75a9d767-b37b-0d68-2d51-0a0e5259003d@txcorp.com>
Message-ID: <CAFzjYVpjrO-tJbL2vNn2SaMHVVB_2Cd6G5DsWDpCoE2x0CH4dw@mail.gmail.com>

Currently we don't provide the compiler id and version for the CUDA
host compiler.

If you are interested in having this information can you please create
an issue on the cmake gitlab: https://gitlab.kitware.com/cmake/cmake

On Fri, May 10, 2019 at 12:09 PM JR Cary <cary at txcorp.com> wrote:
>
> Thanks, Chuck.
>
> I was not clear on my question, which is:  When I specify the two compilers, how
> do I get, e.g., CMAKE_CUDA_HOST_COMPILER_ID and CMAKE_CUDA_HOST_COMPILER_VERSION?
>
> I need these to determine consistency between the CUDA version and the host compiler
> version, so that I can disable CUDA when these are incmpatible.
>
> Thanks...John
>
> On 5/10/19 9:17 AM, Chuck Atkins wrote:
>
> Hi John,
> Two different compilers in the same project for the same language is messy, but in your case it's directly supproted as a special case for cuda using the CMAKE_CUDA_HOST_COMPILER CMake variable or the CUDAHOSTCXX environment variable.
>
> ----------
> Chuck Atkins
> Staff R&D Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Wed, May 8, 2019 at 7:27 AM JR Cary <cary at txcorp.com> wrote:
>>
>> Is there a standard way to deal with 2 C++ compilers?  Getting both
>> there versions, etc.?
>>
>> I need one compiler for compiling ordinary C++ code and a different
>> one to use as the host compiler for CUDA.
>>
>> Thx......John Cary
>> --
>>
>> 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

From forderud at gmail.com  Sun May 12 15:13:42 2019
From: forderud at gmail.com (Fredrik Orderud)
Date: Sun, 12 May 2019 21:13:42 +0200
Subject: [CMake] How to pass linker options with whitespace?
Message-ID: <CAHGmiiuf4EzeAhrfEyZ1ZNyDPSB4kXbmrrKqod0cTQUWiyoJHg@mail.gmail.com>

I'm struggling to figure out how to pass "-s USE_WEBGL2=1 -s
FULL_ES2=1" (without the quotes) as linker options to _all_ CMake
targets when using Emscripten targeting WebAssembly.

I've already tried add_link_options(-s USE_WEBGL2=1 -s FULL_ES2=1),
but that caused the second "-s" to disappear before reaching the
linker. Also, calling add_link_options("-s USE_WEBGL2=1 -s
FULL_ES2=1") causes quotes to be added to the linker call.

I'm currently using set_target_properties(target PROPERTIES LINK_FLAGS
"-s USE_WEBGL2=1 -s FULL_ES2=1") as temporary solution. This works
fine, but am not satisfied with having to apply this manually to all
targets.

Any suggestions?

From marc.chevrier at gmail.com  Mon May 13 02:33:27 2019
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Mon, 13 May 2019 08:33:27 +0200
Subject: [CMake] How to pass linker options with whitespace?
In-Reply-To: <CAHGmiiuf4EzeAhrfEyZ1ZNyDPSB4kXbmrrKqod0cTQUWiyoJHg@mail.gmail.com>
References: <CAHGmiiuf4EzeAhrfEyZ1ZNyDPSB4kXbmrrKqod0cTQUWiyoJHg@mail.gmail.com>
Message-ID: <4d17d4fa-fce8-4457-85ec-6fb5888f9afa@Spark>

You have to use SHELL token (see documentation of add_link_options)

add_link_options ("SHELL:-s USE_WEBGL2=1" ?"SHELL:-s FULL_ES2=1")

Le 12 mai 2019 ? 21:14 +0200, Fredrik Orderud <forderud at gmail.com>, a ?crit :
> I'm struggling to figure out how to pass "-s USE_WEBGL2=1 -s
> FULL_ES2=1" (without the quotes) as linker options to _all_ CMake
> targets when using Emscripten targeting WebAssembly.
>
> I've already tried add_link_options(-s USE_WEBGL2=1 -s FULL_ES2=1),
> but that caused the second "-s" to disappear before reaching the
> linker. Also, calling add_link_options("-s USE_WEBGL2=1 -s
> FULL_ES2=1") causes quotes to be added to the linker call.
>
> I'm currently using set_target_properties(target PROPERTIES LINK_FLAGS
> "-s USE_WEBGL2=1 -s FULL_ES2=1") as temporary solution. This works
> fine, but am not satisfied with having to apply this manually to all
> targets.
>
> Any suggestions?
> --
>
> 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/20190513/fb007b10/attachment.html>

From forderud at gmail.com  Mon May 13 05:36:59 2019
From: forderud at gmail.com (Fredrik Orderud)
Date: Mon, 13 May 2019 11:36:59 +0200
Subject: [CMake] How to pass linker options with whitespace?
In-Reply-To: <4d17d4fa-fce8-4457-85ec-6fb5888f9afa@Spark>
References: <CAHGmiiuf4EzeAhrfEyZ1ZNyDPSB4kXbmrrKqod0cTQUWiyoJHg@mail.gmail.com>
 <4d17d4fa-fce8-4457-85ec-6fb5888f9afa@Spark>
Message-ID: <CAHGmiitHnymURUy9rcntXQE3MM6J9G9jAo_Rj7f_HXc9sx53qw@mail.gmail.com>

On Mon, May 13, 2019 at 8:40 AM Marc CHEVRIER <marc.chevrier at gmail.com> wrote:
> You have to use SHELL token (see documentation of add_link_options)
> add_link_options ("SHELL:-s USE_WEBGL2=1"  "SHELL:-s FULL_ES2=1")

You're of course right. Using "SHELL:" worked perfectly, and solved my
problem. Sorry for not reading the doc properly before contacting the
mailing list.

Fredrik

From bill at classdesign.com  Mon May 13 07:03:25 2019
From: bill at classdesign.com (Bill Somerville)
Date: Mon, 13 May 2019 12:03:25 +0100
Subject: [CMake] Dependency cycle - why?
Message-ID: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>

Hi folks,

I am struggling to understand what the problem is with this:

find_program (GO go)
set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
file (MAKE_DIRECTORY ${GOPATH})

set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
set (build_command ${GO} build)
set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
add_custom_command (OUTPUT ${output}
   COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} ${sources}
   DEPENDS ${sources}
   VERBATIM)
add_custom_target (callback_generator_target DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${output})
add_executable (callback_generator IMPORTED)
set_target_properties (callback_generator
   PROPERTIES
   IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
   )
add_dependencies (callback_generator callback_generator_target)

add_custom_target (server ALL DEPENDS callback_generator)

which gives this error:

>cmake --version
cmake --version
cmake version 3.14.3

>cmake -G "MinGW Makefiles" ..\..
cmake -G "MinGW Makefiles" ..\..
-- Configuring done
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
   "callback_generator_target" of type UTILITY
     depends on "callback_generator_target" (strong)
The component contains at least one cycle consisting of strong dependencies (created by add_dependencies) that cannot be broken.

The set_target_properties () call seems to be part of the problem but I 
don't understand why.

Regards
Bill Somerville.

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

From dustyn at blasig.us  Mon May 13 13:05:34 2019
From: dustyn at blasig.us (Dustyn Blasig)
Date: Mon, 13 May 2019 12:05:34 -0500
Subject: [CMake] ALL_BUILD with msbuild
Message-ID: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>

Hi All,

I'm trying to switch from devenv to msbuild on the command line so we can
use the /m parallel build option. On devenv, I just build the ALL_BUILD
target and it builds properly. However, on msbuild, there are two issues.

1. If I specify the ALL_BUILD target on the command line directly, I get
the following errors. (... used to remove large paths)

*c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /t:ALL_BUILD
/p:Configuration=Release /m || goto :ERROR
*Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 5/10/2019 1:01:52 PM.
     1>Project "c:\tmp\...\mysolution.sln" on node 1 (ALL_BUILD target(s)).
     1>ValidateSolutionConfiguration:
         Building solution configuration "Release|x64".
       ValidateProjects:
         The project "ALL_BUILD" is not selected for building in
solution configuration "Release|x64".
         The project "Continuous" is not selected for building in
solution configuration "Release|x64".
         The project "Experimental" is not selected for building in
solution configuration "Release|x64".
         The project "Nightly" is not selected for building in
solution configuration "Release|x64".
         The project "NightlyMemoryCheck" is not selected for building
in solution configuration "Release|x64".
         The project "RUN_TESTS" is not selected for building in
solution configuration "Release|x64".

         ...
     1>Project "c:\tmp\...\mysolution.sln" (1) is building
"...\myproj.vcxproj.metaproj" (2) on node 1 (ALL_BUILD target(s)).*
 2>Project "c:\tmp\...\myproj.vcxproj.metaproj" (2) is building
"c:\tmp\...\ZERO_CHECK.vcxproj" (54) on node 2 (ALL_BUILD target(s)).
*    54>c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target
"ALL_BUILD" does not exist in the project.
    54>Done Building Project "c:\tmp\...\ZERO_CHECK.vcxproj"
(ALL_BUILD target(s)) -- FAILED.
     2>Done Building Project "c:\tmp\...\myproj.vcxproj.metaproj"
(ALL_BUILD target(s)) -- FAILED.
     1>Done Building Project "c:\tmp\...\mysolution.sln" (ALL_BUILD
target(s)) -- FAILED.

Build FAILED.

       "c:\tmp\...\mysolution.sln" (ALL_BUILD target) (1) ->
       "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target) (2) ->
       "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target) (54) ->
         c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target
"ALL_BUILD" does not exist in the project.

    0 Warning(s)
    1 Error(s)


What is different with the ALL_BUILD target between msbuild and devenv? I
must be calling things improperly on the command line, but I'm not sure
what.

2. If I instead leave ALL_BUILD off and just let it build the defaults, it
gets further, but it also trys to build targets that are not enabled with
the "all" target by default like our unit tests which we add through a
hierarchy of targets like "run_tests_...".

*c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /p:Configuration=Release
/m || goto :ERROR
*


Should calling msbuild on just the solution build only the "all" target by
default, or does mbuild just build everything in the solution ignoring the
"all" target stuff?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190513/689f6a93/attachment.html>

From calebwherry at gmail.com  Mon May 13 14:15:44 2019
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Mon, 13 May 2019 14:15:44 -0400
Subject: [CMake] ALL_BUILD with msbuild
In-Reply-To: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>
References: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>
Message-ID: <CAJxY6XovWJcFzuyaA-Ka78cYWcU0MF-SPtqjZwP8Ot6ZYSAm0w@mail.gmail.com>

I do not specify the project name when running my main build, I call
msbuild like you do in #2.

How do you exclude things from ?all?? I?ve actually ran into issues with VS
and how pressing ?Build? in the IDE and running on the command line do
different things. This comes down to 2 target properties: EXCLUDE_FROM_ALL
and EXCLUDE_FROM_DEFAULT_BUILD.

These each do different things so I ended up setting them both to true for
all my tests. Give that a shot and see what happens along with the #2 way
of calling msbuild.

-Caleb

On Mon, May 13, 2019 at 1:05 PM Dustyn Blasig <dustyn at blasig.us> wrote:

> Hi All,
>
> I'm trying to switch from devenv to msbuild on the command line so we can
> use the /m parallel build option. On devenv, I just build the ALL_BUILD
> target and it builds properly. However, on msbuild, there are two issues.
>
> 1. If I specify the ALL_BUILD target on the command line directly, I get
> the following errors. (... used to remove large paths)
>
> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /t:ALL_BUILD /p:Configuration=Release /m || goto :ERROR
> *Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Build started 5/10/2019 1:01:52 PM.
>      1>Project "c:\tmp\...\mysolution.sln" on node 1 (ALL_BUILD target(s)).
>      1>ValidateSolutionConfiguration:
>          Building solution configuration "Release|x64".
>        ValidateProjects:
>          The project "ALL_BUILD" is not selected for building in solution configuration "Release|x64".
>          The project "Continuous" is not selected for building in solution configuration "Release|x64".
>          The project "Experimental" is not selected for building in solution configuration "Release|x64".
>          The project "Nightly" is not selected for building in solution configuration "Release|x64".
>          The project "NightlyMemoryCheck" is not selected for building in solution configuration "Release|x64".
>          The project "RUN_TESTS" is not selected for building in solution configuration "Release|x64".
>
>          ...
>      1>Project "c:\tmp\...\mysolution.sln" (1) is building "...\myproj.vcxproj.metaproj" (2) on node 1 (ALL_BUILD target(s)).*     2>Project "c:\tmp\...\myproj.vcxproj.metaproj" (2) is building "c:\tmp\...\ZERO_CHECK.vcxproj" (54) on node 2 (ALL_BUILD target(s)).
> *    54>c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>     54>Done Building Project "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target(s)) -- FAILED.
>      2>Done Building Project "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target(s)) -- FAILED.
>      1>Done Building Project "c:\tmp\...\mysolution.sln" (ALL_BUILD target(s)) -- FAILED.
>
> Build FAILED.
>
>        "c:\tmp\...\mysolution.sln" (ALL_BUILD target) (1) ->
>        "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target) (2) ->
>        "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target) (54) ->
>          c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>
>     0 Warning(s)
>     1 Error(s)
>
>
> What is different with the ALL_BUILD target between msbuild and devenv? I
> must be calling things improperly on the command line, but I'm not sure
> what.
>
> 2. If I instead leave ALL_BUILD off and just let it build the defaults, it
> gets further, but it also trys to build targets that are not enabled with
> the "all" target by default like our unit tests which we add through a
> hierarchy of targets like "run_tests_...".
>
> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /p:Configuration=Release /m || goto :ERROR
> *
>
>
> Should calling msbuild on just the solution build only the "all" target by
> default, or does mbuild just build everything in the solution ignoring the
> "all" target stuff?
>
> Thanks!
> --
>
> 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
>
-- 
Sent from my iPhone SE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190513/8b650e46/attachment.html>

From dustyn at blasig.us  Mon May 13 14:35:46 2019
From: dustyn at blasig.us (Dustyn Blasig)
Date: Mon, 13 May 2019 13:35:46 -0500
Subject: [CMake] ALL_BUILD with msbuild
In-Reply-To: <CAJxY6XovWJcFzuyaA-Ka78cYWcU0MF-SPtqjZwP8Ot6ZYSAm0w@mail.gmail.com>
References: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>
 <CAJxY6XovWJcFzuyaA-Ka78cYWcU0MF-SPtqjZwP8Ot6ZYSAm0w@mail.gmail.com>
Message-ID: <CAN4pPGUfrzDia=zH=LhVM7=PS4aEES=mepMrNfrgspzpSJe-CA@mail.gmail.com>

Ah, thanks, we do use EXCLUDE_FROM_ALL but I did not know about
EXCLUDE_FROM_DEFAULT_BUILD. From the documentation, it sounds like we
really do want to build the ALL_BUILD target, but I'm not sure how to get
the ZERO_CHECK project to properly build with msbuild. I can probably use
EXCLUDE_FROM_DEFAULT_BUILD as a workaround in the meantime, though.

On Mon, May 13, 2019 at 1:15 PM J. Caleb Wherry <calebwherry at gmail.com>
wrote:

> I do not specify the project name when running my main build, I call
> msbuild like you do in #2.
>
> How do you exclude things from ?all?? I?ve actually ran into issues with
> VS and how pressing ?Build? in the IDE and running on the command line do
> different things. This comes down to 2 target properties: EXCLUDE_FROM_ALL
> and EXCLUDE_FROM_DEFAULT_BUILD.
>
> These each do different things so I ended up setting them both to true for
> all my tests. Give that a shot and see what happens along with the #2 way
> of calling msbuild.
>
> -Caleb
>
> On Mon, May 13, 2019 at 1:05 PM Dustyn Blasig <dustyn at blasig.us> wrote:
>
>> Hi All,
>>
>> I'm trying to switch from devenv to msbuild on the command line so we can
>> use the /m parallel build option. On devenv, I just build the ALL_BUILD
>> target and it builds properly. However, on msbuild, there are two issues.
>>
>> 1. If I specify the ALL_BUILD target on the command line directly, I get
>> the following errors. (... used to remove large paths)
>>
>> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /t:ALL_BUILD /p:Configuration=Release /m || goto :ERROR
>> *Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> Build started 5/10/2019 1:01:52 PM.
>>      1>Project "c:\tmp\...\mysolution.sln" on node 1 (ALL_BUILD target(s)).
>>      1>ValidateSolutionConfiguration:
>>          Building solution configuration "Release|x64".
>>        ValidateProjects:
>>          The project "ALL_BUILD" is not selected for building in solution configuration "Release|x64".
>>          The project "Continuous" is not selected for building in solution configuration "Release|x64".
>>          The project "Experimental" is not selected for building in solution configuration "Release|x64".
>>          The project "Nightly" is not selected for building in solution configuration "Release|x64".
>>          The project "NightlyMemoryCheck" is not selected for building in solution configuration "Release|x64".
>>          The project "RUN_TESTS" is not selected for building in solution configuration "Release|x64".
>>
>>          ...
>>      1>Project "c:\tmp\...\mysolution.sln" (1) is building "...\myproj.vcxproj.metaproj" (2) on node 1 (ALL_BUILD target(s)).*     2>Project "c:\tmp\...\myproj.vcxproj.metaproj" (2) is building "c:\tmp\...\ZERO_CHECK.vcxproj" (54) on node 2 (ALL_BUILD target(s)).
>> *    54>c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>>     54>Done Building Project "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target(s)) -- FAILED.
>>      2>Done Building Project "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target(s)) -- FAILED.
>>      1>Done Building Project "c:\tmp\...\mysolution.sln" (ALL_BUILD target(s)) -- FAILED.
>>
>> Build FAILED.
>>
>>        "c:\tmp\...\mysolution.sln" (ALL_BUILD target) (1) ->
>>        "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target) (2) ->
>>        "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target) (54) ->
>>          c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>>
>>     0 Warning(s)
>>     1 Error(s)
>>
>>
>> What is different with the ALL_BUILD target between msbuild and devenv? I
>> must be calling things improperly on the command line, but I'm not sure
>> what.
>>
>> 2. If I instead leave ALL_BUILD off and just let it build the defaults,
>> it gets further, but it also trys to build targets that are not enabled
>> with the "all" target by default like our unit tests which we add through a
>> hierarchy of targets like "run_tests_...".
>>
>> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /p:Configuration=Release /m || goto :ERROR
>> *
>>
>>
>> Should calling msbuild on just the solution build only the "all" target
>> by default, or does mbuild just build everything in the solution ignoring
>> the "all" target stuff?
>>
>> Thanks!
>> --
>>
>> 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
>>
> --
> Sent from my iPhone SE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190513/926527aa/attachment-0001.html>

From calebwherry at gmail.com  Mon May 13 15:07:03 2019
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Mon, 13 May 2019 15:07:03 -0400
Subject: [CMake] ALL_BUILD with msbuild
In-Reply-To: <CAN4pPGUfrzDia=zH=LhVM7=PS4aEES=mepMrNfrgspzpSJe-CA@mail.gmail.com>
References: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>
 <CAJxY6XovWJcFzuyaA-Ka78cYWcU0MF-SPtqjZwP8Ot6ZYSAm0w@mail.gmail.com>
 <CAN4pPGUfrzDia=zH=LhVM7=PS4aEES=mepMrNfrgspzpSJe-CA@mail.gmail.com>
Message-ID: <CAJxY6Xo3Myzb2fM0usoKi1MP=o=AqcmOvx26AsjERGEC4zQmvg@mail.gmail.com>

Can?t help much on the ZERO_CHECK project, we set the
CMAKE_SUPPRESS_REGENERATION to true which disables that project.

-Caleb

On Mon, May 13, 2019 at 2:35 PM Dustyn Blasig <dustyn at blasig.us> wrote:

> Ah, thanks, we do use EXCLUDE_FROM_ALL but I did not know about
> EXCLUDE_FROM_DEFAULT_BUILD. From the documentation, it sounds like we
> really do want to build the ALL_BUILD target, but I'm not sure how to get
> the ZERO_CHECK project to properly build with msbuild. I can probably use
> EXCLUDE_FROM_DEFAULT_BUILD as a workaround in the meantime, though.
>
> On Mon, May 13, 2019 at 1:15 PM J. Caleb Wherry <calebwherry at gmail.com>
> wrote:
>
>> I do not specify the project name when running my main build, I call
>> msbuild like you do in #2.
>>
>> How do you exclude things from ?all?? I?ve actually ran into issues with
>> VS and how pressing ?Build? in the IDE and running on the command line do
>> different things. This comes down to 2 target properties: EXCLUDE_FROM_ALL
>> and EXCLUDE_FROM_DEFAULT_BUILD.
>>
>> These each do different things so I ended up setting them both to true
>> for all my tests. Give that a shot and see what happens along with the #2
>> way of calling msbuild.
>>
>> -Caleb
>>
>> On Mon, May 13, 2019 at 1:05 PM Dustyn Blasig <dustyn at blasig.us> wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to switch from devenv to msbuild on the command line so we
>>> can use the /m parallel build option. On devenv, I just build the ALL_BUILD
>>> target and it builds properly. However, on msbuild, there are two issues.
>>>
>>> 1. If I specify the ALL_BUILD target on the command line directly, I get
>>> the following errors. (... used to remove large paths)
>>>
>>> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /t:ALL_BUILD /p:Configuration=Release /m || goto :ERROR
>>> *Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>
>>> Build started 5/10/2019 1:01:52 PM.
>>>      1>Project "c:\tmp\...\mysolution.sln" on node 1 (ALL_BUILD target(s)).
>>>      1>ValidateSolutionConfiguration:
>>>          Building solution configuration "Release|x64".
>>>        ValidateProjects:
>>>          The project "ALL_BUILD" is not selected for building in solution configuration "Release|x64".
>>>          The project "Continuous" is not selected for building in solution configuration "Release|x64".
>>>          The project "Experimental" is not selected for building in solution configuration "Release|x64".
>>>          The project "Nightly" is not selected for building in solution configuration "Release|x64".
>>>          The project "NightlyMemoryCheck" is not selected for building in solution configuration "Release|x64".
>>>          The project "RUN_TESTS" is not selected for building in solution configuration "Release|x64".
>>>
>>>          ...
>>>      1>Project "c:\tmp\...\mysolution.sln" (1) is building "...\myproj.vcxproj.metaproj" (2) on node 1 (ALL_BUILD target(s)).*     2>Project "c:\tmp\...\myproj.vcxproj.metaproj" (2) is building "c:\tmp\...\ZERO_CHECK.vcxproj" (54) on node 2 (ALL_BUILD target(s)).
>>> *    54>c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>>>     54>Done Building Project "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target(s)) -- FAILED.
>>>      2>Done Building Project "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target(s)) -- FAILED.
>>>      1>Done Building Project "c:\tmp\...\mysolution.sln" (ALL_BUILD target(s)) -- FAILED.
>>>
>>> Build FAILED.
>>>
>>>        "c:\tmp\...\mysolution.sln" (ALL_BUILD target) (1) ->
>>>        "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target) (2) ->
>>>        "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target) (54) ->
>>>          c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>>>
>>>     0 Warning(s)
>>>     1 Error(s)
>>>
>>>
>>> What is different with the ALL_BUILD target between msbuild and devenv?
>>> I must be calling things improperly on the command line, but I'm not sure
>>> what.
>>>
>>> 2. If I instead leave ALL_BUILD off and just let it build the defaults,
>>> it gets further, but it also trys to build targets that are not enabled
>>> with the "all" target by default like our unit tests which we add through a
>>> hierarchy of targets like "run_tests_...".
>>>
>>> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /p:Configuration=Release /m || goto :ERROR
>>> *
>>>
>>>
>>> Should calling msbuild on just the solution build only the "all" target
>>> by default, or does mbuild just build everything in the solution ignoring
>>> the "all" target stuff?
>>>
>>> Thanks!
>>> --
>>>
>>> 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
>>>
>> --
>> Sent from my iPhone SE
>>
> --
Sent from my iPhone SE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190513/dde3e7bc/attachment.html>

From frodak17 at gmail.com  Mon May 13 15:56:15 2019
From: frodak17 at gmail.com (frodak17)
Date: Mon, 13 May 2019 15:56:15 -0400
Subject: [CMake] ALL_BUILD with msbuild
In-Reply-To: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>
References: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>
Message-ID: <CAM_JqVkFwb9tDVYu7JjZ9RjuJ5xV9zvU6Oe5EvSnONayCj85gw@mail.gmail.com>

On Mon, May 13, 2019 at 1:05 PM Dustyn Blasig <dustyn at blasig.us> wrote:

> Hi All,
>
> I'm trying to switch from devenv to msbuild on the command line so we can
> use the /m parallel build option. On devenv, I just build the ALL_BUILD
> target and it builds properly. However, on msbuild, there are two issues.
>
> 1. If I specify the ALL_BUILD target on the command line directly, I get
> the following errors. (... used to remove large paths)
>
> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /t:ALL_BUILD /p:Configuration=Release /m || goto :ERROR
> *Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Build started 5/10/2019 1:01:52 PM.
>      1>Project "c:\tmp\...\mysolution.sln" on node 1 (ALL_BUILD target(s)).
>      1>ValidateSolutionConfiguration:
>          Building solution configuration "Release|x64".
>        ValidateProjects:
>          The project "ALL_BUILD" is not selected for building in solution configuration "Release|x64".
>          The project "Continuous" is not selected for building in solution configuration "Release|x64".
>          The project "Experimental" is not selected for building in solution configuration "Release|x64".
>          The project "Nightly" is not selected for building in solution configuration "Release|x64".
>          The project "NightlyMemoryCheck" is not selected for building in solution configuration "Release|x64".
>          The project "RUN_TESTS" is not selected for building in solution configuration "Release|x64".
>
>          ...
>      1>Project "c:\tmp\...\mysolution.sln" (1) is building "...\myproj.vcxproj.metaproj" (2) on node 1 (ALL_BUILD target(s)).*     2>Project "c:\tmp\...\myproj.vcxproj.metaproj" (2) is building "c:\tmp\...\ZERO_CHECK.vcxproj" (54) on node 2 (ALL_BUILD target(s)).
> *    54>c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>     54>Done Building Project "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target(s)) -- FAILED.
>      2>Done Building Project "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target(s)) -- FAILED.
>      1>Done Building Project "c:\tmp\...\mysolution.sln" (ALL_BUILD target(s)) -- FAILED.
>
> Build FAILED.
>
>        "c:\tmp\...\mysolution.sln" (ALL_BUILD target) (1) ->
>        "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target) (2) ->
>        "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target) (54) ->
>          c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>
>     0 Warning(s)
>     1 Error(s)
>
>
> What is different with the ALL_BUILD target between msbuild and devenv? I
> must be calling things improperly on the command line, but I'm not sure
> what.
>
> 2. If I instead leave ALL_BUILD off and just let it build the defaults, it
> gets further, but it also trys to build targets that are not enabled with
> the "all" target by default like our unit tests which we add through a
> hierarchy of targets like "run_tests_...".
>
> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /p:Configuration=Release /m || goto :ERROR
> *
>
>
> Should calling msbuild on just the solution build only the "all" target by
> default, or does mbuild just build everything in the solution ignoring the
> "all" target stuff?
>
> Thanks!
> --
>

Personally I've just always used CMake to construct the command line by
using:
cmake --build . --config Release -j

Which constructs the command:
msbuild ALL_BUILD.vcxproj /p:Configuration=Release /m

I've been told that CMake targets do not translate to the targets usable by
the /target switch.

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

From dustyn at blasig.us  Mon May 13 17:28:59 2019
From: dustyn at blasig.us (Dustyn Blasig)
Date: Mon, 13 May 2019 16:28:59 -0500
Subject: [CMake] ALL_BUILD with msbuild
In-Reply-To: <CAM_JqVkFwb9tDVYu7JjZ9RjuJ5xV9zvU6Oe5EvSnONayCj85gw@mail.gmail.com>
References: <CAN4pPGVUoCR0DR3rea9O5_ohqwv68ZkJJG-Q3CqZMR2--G0=bg@mail.gmail.com>
 <CAM_JqVkFwb9tDVYu7JjZ9RjuJ5xV9zvU6Oe5EvSnONayCj85gw@mail.gmail.com>
Message-ID: <CAN4pPGVbSyLvDQP91XYwPPQoK3SVKoU+mG2Rhn=iN7KwPJKe1g@mail.gmail.com>

Yay, just building ALL_BUILD.vcxproj directly worked! I did not realize we
didn't need to build the solution for things to work. Thanks!

On Mon, May 13, 2019 at 2:56 PM frodak17 <frodak17 at gmail.com> wrote:

>
>
> On Mon, May 13, 2019 at 1:05 PM Dustyn Blasig <dustyn at blasig.us> wrote:
>
>> Hi All,
>>
>> I'm trying to switch from devenv to msbuild on the command line so we can
>> use the /m parallel build option. On devenv, I just build the ALL_BUILD
>> target and it builds properly. However, on msbuild, there are two issues.
>>
>> 1. If I specify the ALL_BUILD target on the command line directly, I get
>> the following errors. (... used to remove large paths)
>>
>> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /t:ALL_BUILD /p:Configuration=Release /m || goto :ERROR
>> *Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> Build started 5/10/2019 1:01:52 PM.
>>      1>Project "c:\tmp\...\mysolution.sln" on node 1 (ALL_BUILD target(s)).
>>      1>ValidateSolutionConfiguration:
>>          Building solution configuration "Release|x64".
>>        ValidateProjects:
>>          The project "ALL_BUILD" is not selected for building in solution configuration "Release|x64".
>>          The project "Continuous" is not selected for building in solution configuration "Release|x64".
>>          The project "Experimental" is not selected for building in solution configuration "Release|x64".
>>          The project "Nightly" is not selected for building in solution configuration "Release|x64".
>>          The project "NightlyMemoryCheck" is not selected for building in solution configuration "Release|x64".
>>          The project "RUN_TESTS" is not selected for building in solution configuration "Release|x64".
>>
>>          ...
>>      1>Project "c:\tmp\...\mysolution.sln" (1) is building "...\myproj.vcxproj.metaproj" (2) on node 1 (ALL_BUILD target(s)).*     2>Project "c:\tmp\...\myproj.vcxproj.metaproj" (2) is building "c:\tmp\...\ZERO_CHECK.vcxproj" (54) on node 2 (ALL_BUILD target(s)).
>> *    54>c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>>     54>Done Building Project "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target(s)) -- FAILED.
>>      2>Done Building Project "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target(s)) -- FAILED.
>>      1>Done Building Project "c:\tmp\...\mysolution.sln" (ALL_BUILD target(s)) -- FAILED.
>>
>> Build FAILED.
>>
>>        "c:\tmp\...\mysolution.sln" (ALL_BUILD target) (1) ->
>>        "c:\tmp\...\myproj.vcxproj.metaproj" (ALL_BUILD target) (2) ->
>>        "c:\tmp\...\ZERO_CHECK.vcxproj" (ALL_BUILD target) (54) ->
>>          c:\tmp\...\ZERO_CHECK.vcxproj : error MSB4057: The target "ALL_BUILD" does not exist in the project.
>>
>>     0 Warning(s)
>>     1 Error(s)
>>
>>
>> What is different with the ALL_BUILD target between msbuild and devenv? I
>> must be calling things improperly on the command line, but I'm not sure
>> what.
>>
>> 2. If I instead leave ALL_BUILD off and just let it build the defaults,
>> it gets further, but it also trys to build targets that are not enabled
>> with the "all" target by default like our unit tests which we add through a
>> hierarchy of targets like "run_tests_...".
>>
>> *c:\tmp\...>msbuild c:\tmp\...\mysolution.sln /p:Configuration=Release /m || goto :ERROR
>> *
>>
>>
>> Should calling msbuild on just the solution build only the "all" target
>> by default, or does mbuild just build everything in the solution ignoring
>> the "all" target stuff?
>>
>> Thanks!
>> --
>>
>
> Personally I've just always used CMake to construct the command line by
> using:
> cmake --build . --config Release -j
>
> Which constructs the command:
> msbuild ALL_BUILD.vcxproj /p:Configuration=Release /m
>
> I've been told that CMake targets do not translate to the targets usable
> by the /target switch.
>
> --
> F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190513/01a71c17/attachment-0001.html>

From zehner.paul at jaxa.jp  Mon May 13 22:58:05 2019
From: zehner.paul at jaxa.jp (=?iso-2022-jp?B?WmVobmVyGyRCISEbKEJQYXVs?=)
Date: Tue, 14 May 2019 02:58:05 +0000
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <CAFzjYVoNhiBP=WK+5OR_=KoQB0f0QoHE8Owz6WpspyvYt6Mqiw@mail.gmail.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
 <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>
 <TY1PR01MB1883FA83D31C6111C15E1016F4330@TY1PR01MB1883.jpnprd01.prod.outlook.com>,
 <CAFzjYVoNhiBP=WK+5OR_=KoQB0f0QoHE8Owz6WpspyvYt6Mqiw@mail.gmail.com>
Message-ID: <TY1PR01MB1883067FEF7951468A372305F4080@TY1PR01MB1883.jpnprd01.prod.outlook.com>

Robert,

so that all users could benefit from the improved compiler detection :)
That is my plan! If I can make a compiler module which works well enough, I will submit it as a merge request.

Regarding the detection of MPI with FindMPI, I failed to detect the MPI compiler using `MPI_CXX_COMPILER_FLAGS`. But using the normal Fujitsu compiler binary (not the wrapper) and setting `MPI_CXX_COMPILER`, I can detect it.

The problem is now that it does not detect the STL anymore at compiling time: "error: namespace "std" has no member "array"" (note that I used to build the project with a hand made Makefile, so the source code is valid). I checked the `include` directory of the compiler and it contains the Array header, though. In other warnings, I clearly see that this `include` directory is used. What is wrong here?

Best regards,


--

Paul Zehner, Ph. D.

Invited Researcher

Numerical Simulation Research Unit

Japan Aerospace Exploration Agency

7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo

182-8522, Japan

Tel. +81-50-3362-7933

Fax. +81-422-40-3327

zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp>

www.jaxa.jp<http://www.jaxa.jp>

________________________________
From: Robert Maynard <robert.maynard at kitware.com>
Sent: Thursday, May 9, 2019 23:29
To: Zehner?Paul
Cc: Kai Wolf; cmake at cmake.org
Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler

The goal would be to upstream the compiler changes to cmake so that
all users could benefit from the improved compiler detection :)

I would look at the FindMPI docs on locating the correct mpi compiler:
https://cmake.org/cmake/help/v3.14/module/FindMPI.html#variables-for-locating-mpi
. It looks like what you will need to specify is
MPI_<lang>_COMPILER_FLAGS

On Wed, May 8, 2019 at 10:15 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
>
> Thank you for your answer.
>
> This means I have to override `/usr/share/cmake/Modules/Compiler/Fujitsu-DetermineCompiler.cmake`? This is not unfeasible, but it may seems tricky to my users. Since detecting compiler version is not a crucial task, maybe I will keep this file as it and concentrate on other ones.
>
> Another question I have is regarding MPI. The `find_package(MPI REQUIRED)` directive fails with "Could NOT find MPI (missing: MPI_CXX_FOUND)". I have no clue on how to help the detection of MPI. The compiler I give to CMake is actually an MPI wrapper that only needs one argument to enable MPI features. I tried with some exotic-named GCC compilers at my lab (which are MPI wrappers as well) and it could detect MPI with no problem. Where should I start?
>
> Best regards,
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp<http://www.jaxa.jp>
>
> ________________________________
> From: Robert Maynard <robert.maynard at kitware.com>
> Sent: Thursday, May 9, 2019 3:12
> To: Zehner?Paul
> Cc: Kai Wolf; cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> I believe the only way is to have your version of
> Fujitsu-DetermineCompiler.cmake be installed over the one provided by
> CMake. When it comes to known compilers CMake explicitly includes the
> version it ships.
>
> On Tue, May 7, 2019 at 11:01 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> >
> > Robert,
> >
> > Thank you for the advice.
> >
> > As I want to take account of compiler version, I overrided the `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in the folder of `CMAKE_MODULE_PATH`. However, the installation `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should I do?
> >
> > Best regards,
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.paul at jaxa.jp
> >
> > www.jaxa.jp<http://www.jaxa.jp>
> >
> > ________________________________
> > From: Robert Maynard <robert.maynard at kitware.com>
> > Sent: Friday, April 26, 2019 23:32
> > To: Zehner?Paul
> > Cc: Kai Wolf; cmake at cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > For an initial implementation I would base the work on the PGI
> > compiler module (
> > https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> > ) not the GNU-CXX module.
> > This will allow you to add a new compiler with only meta-language
> > flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> > having to manually build the feature tables.
> >
> > On Fri, Apr 26, 2019 at 3:58 AM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> > >
> > > Kai,
> > >
> > >
> > > Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration.
> > >
> > >
> > > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request.
> > >
> > >
> > > --
> > >
> > > Paul Zehner, Ph. D.
> > >
> > > Invited Researcher
> > >
> > > Numerical Simulation Research Unit
> > >
> > > Japan Aerospace Exploration Agency
> > >
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > >
> > > 182-8522, Japan
> > >
> > > Tel. +81-50-3362-7933
> > >
> > > Fax. +81-422-40-3327
> > >
> > > zehner.paul at jaxa.jp
> > >
> > > www.jaxa.jp<http://www.jaxa.jp>
> > >
> > >
> > >
> > > ________________________________
> > > From: Kai Wolf <kai.wolf at gmail.com>
> > > Sent: Friday, April 26, 2019 16:22
> > > To: Zehner?Paul
> > > Cc: cmake at cmake.org
> > > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> > >
> > > If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake
> > > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust
> > > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> > >
> > > I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which
> > > you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> > >
> > >
> > > Greetings,
> > >
> > > Kai
> > >
> > > http://kai-wolf.me
> > > http://effective-cmake.com
> > >
> > > Am 26.04.2019 um 07:35 schrieb Zehner?Paul <zehner.paul at jaxa.jp>:
> > >
> > > Hello Cmake community,
> > >
> > > I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler.
> > >
> > > I tested it on a simple project, and the line:
> > >
> > > ```cmake
> > > target_compile_features(test PUBLIC cxx_std_11)
> > > ```
> > >
> > > fails with this message:
> > >
> > > ```
> > > CMake Error at CMakeLists.txt:15 (target_compile_features):
> > >   target_compile_features no known features for CXX compiler
> > >
> > >   "Fujitsu"
> > >
> > >   version .
> > >
> > > ```
> > >
> > > So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features:
> > >
> > > ```cmake
> > > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > > project(foobar CXX)
> > > message("Your C++ compiler supports these C++ features:")
> > > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> > >     message("${i}")
> > > endforeach()
> > > ```
> > >
> > > and no feature are listed.
> > >
> > > So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu?
> > >
> > > Thanks for your help,
> > >
> > > --
> > > Paul Zehner, Ph. D.
> > > Invited Researcher
> > > Numerical Simulation Research Unit
> > > Japan Aerospace Exploration Agency
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > > 182-8522, Japan
> > > Tel. +81-50-3362-7933
> > > Fax. +81-422-40-3327
> > > zehner.paul at jaxa.jp
> > > www.jaxa.jp<http://www.jaxa.jp>
> > > --
> > >
> > > 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
> > >
> > >
> > > --
> > >
> > > 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/20190514/fd83b1ac/attachment-0001.html>

From robert.maynard at kitware.com  Tue May 14 14:23:33 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 14 May 2019 14:23:33 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.13.5 available for download
Message-ID: <CAFzjYVppXfwwy5dBJ0F=AkED1RuJHHwxnb-eZgotP-LjLLsT9A@mail.gmail.com>

We are pleased to announce that CMake 3.13.5 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.13.5 since 3.13.4:

Brad King (3):
  target_link_libraries: Fix static library private deps in other dirs
  Help: Add 3.13.5 release notes
  CMake 3.13.5

Nils Gladitz (1):
  CMake: Fix WiX installer downgrades with versioned binaries

From robert.maynard at kitware.com  Tue May 14 14:25:29 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 14 May 2019 14:25:29 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.14.4 available for download
Message-ID: <CAFzjYVoArY6s9zPwcSXxsWahVi7r4WbYPamwGw1aYUqwFqbxXg@mail.gmail.com>

We are pleased to announce that CMake 3.14.4 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.14.4 since 3.14.3:

Alex Turbov (2):
  FindBoost: Record compiler features for Boost 1.67 and above
  FindBoost: Fix compiler features for `fiber` and `context`

Alexandru Croitor (1):
  iOS: Fix try_compile FILE_COPY not to fail

Brad King (3):
  target_link_libraries: Fix static library private deps in other dirs
  Help: Add 3.14.4 release notes
  CMake 3.14.4

Daniele E. Domenichelli (1):
  FindSWIG: Support swig4.0

Gregor Jasny (2):
  Apple: Preserve high resolution mtime for static libraries
  Apple: Properly lookup XCTest for iOS and tvOS

Marc Chevrier (2):
  FindPython: NumPy: fix erroneous dependencies management
  FindPython: ensure variable Python_RUNTIME_LIBRARY_DIRS is set correctly

From dmacq at instantiations.com  Wed May 15 18:39:25 2019
From: dmacq at instantiations.com (Donald MacQueen [|])
Date: Wed, 15 May 2019 18:39:25 -0400
Subject: [CMake] How to use sudo in CTest
Message-ID: <e23f6183-9519-1f84-d525-bc7ad0a94a3e@instantiations.com>

I have a suite of CTests that install and test our product on Ubuntu.

The installer requires sudo to run. I have been running the whole suite 
as sudo, which is not a great idea.

So I have toyed with trying to run just the installer with sudo, but no 
luck so far.

I configured sudo to run without asking for a password and that runs fine.

But these CTest COMMANDS do not:

add_test(NAME install COMMAND sudo ./vainstall aParameter )

add_test(NAME install COMMAND "sudo ./vainstall aParameter" )

What am I doing wrong?

Thanks in advance.

-- 
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 hex7c3 at gmail.com  Thu May 16 17:05:01 2019
From: hex7c3 at gmail.com (hex)
Date: Thu, 16 May 2019 22:05:01 +0100
Subject: [CMake] Language Dependency for TCL?
Message-ID: <54a316ee-e402-9eb3-515e-90dba630e579@gmail.com>

hello,

I am setting up a TCL project so I disabled all language variables:

*cmake_minimum_required(VERSION 2.4)**
**
**project(P LANGUAGES NONE)**
**find_package(TCL)*


however, this fails with

*-- Could NOT find TCL (missing: TCL_LIBRARY) **
**-- Could NOT find TCLTK (missing: TCL_LIBRARY TK_LIBRARY) **
**-- Could NOT find TK (missing: TK_LIBRARY) *


If I instead add languages to the project the TCL package works. This 
makes me wonder what dependencies TCL has with standard languages. Is 
the package incomplete? Why do I need to use a language that I do not 
intend to use?

for example:

*cmake_minimum_required(VERSION 2.4)**
**
**project(P LANGUAGES C)**
**find_package(TCL)**
*

*-- Found Tclsh: /usr/bin/tclsh (found version "8.6") **
**-- Found TCL: /usr/lib/x86_64-linux-gnu/libtcl.so **
**-- Found TCLTK: /usr/lib/x86_64-linux-gnu/libtcl.so **
**-- Found TK: /usr/lib/x86_64-linux-gnu/libtk.so *


thank you

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

From zteam at naver.com  Thu May 16 20:53:34 2019
From: zteam at naver.com (Gelryun)
Date: Thu, 16 May 2019 17:53:34 -0700 (MST)
Subject: [CMake] Why is the binary md5sum value different?
Message-ID: <1558054414136-0.post@n2.nabble.com>

I write MakefileList.txt like this.

------------------------------------------------------------------------
include_directories(${COMMINC_DIR} ${DBINC_DIR} ./)
link_directories(${DBLIB_DIR} ${COMMLIB_DIR})

set(DBUSERID withdb/ufdb)
PREPROCESS_ORACLE_FILES(ACK_db.pc ${DBUSERID} "${DBINC_DIR};${COMMINC_DIR}")

set(ACK_P_SRCS
        ACK_db.c ACK_p.c)

set(ACK_C_SRCS
        ACK_db.c ACK_c.c)

add_executable(ACK_p ${ACK_P_SRCS})
add_executable(ACK_c ${ACK_C_SRCS})


target_link_libraries(ACK_p ${DEF_P_LIBS} ${DBLIB})
target_link_libraries(ACK_c ${DEF_C_LIBS} ${DBLIB})

install(TARGETS ACK_p DESTINATION ${BIN_DIR})
install(TARGETS ACK_c DESTINATION ${BIN_DIR})
----------------------------------------------------------------------------------

When I install it, the md5sum value of the binaries there is different.

Why is the binary md5sum value different?

EX) _ Size is Same
$>md5sum DMACK_c
68ff336ffa2a454672c451bd3ad66369  DMACK_c
$> md5sum ../bin/DMACK_c
369c9a12e3dd58504e2180a008b12eb6  ../bin/DMACK_c




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

From mlg420sniperxxx69 at gmail.com  Fri May 17 02:55:37 2019
From: mlg420sniperxxx69 at gmail.com (junk email)
Date: Thu, 16 May 2019 23:55:37 -0700
Subject: [CMake] How to Build Subdirectory CMake Project GLFW and Change
 Targets
Message-ID: <CAOLWVF=whWsqAA32ZfSC1+72ve4gjcKfQVPivuMDLSXzJqR2Lg@mail.gmail.com>

Hello,

I am trying to understand how to build a subdirectory project that has its
own CMakeLists.txt file already setup. In this case, I am using the open
source library GLFW to help me with some of my OpenGL applications. Here is
a sample directory structure I am working with.

Root
??? CMakeLists.txt
??? MainProject
??? build
??? glfw-3.3

The folder MainProject is where I will be doing all my own development and
has a src, include, and lib folder associated with it. The glfw-3.3
directory was downloaded from online and has its own CMakeLists.txt file as
mentioned previously. So if I were to build my project from the current
build directory shown here, how should I add the glfw library to it and
also change its target outputs?

Answers online suggest using ExternalProject_Add(), while others say to
simply add_subdirectory() and then change some of the properties. I want to
be able to have a user run the root CMake file and have the targets be
correctly placed (since users might be on different operating systems).
Either way I have not been able to find an explicit example, perhaps my
Googling skills for CMake are lacking, and any help on this would be
appreciated. Thank you for your time.

Best,
mlg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190516/f488edfc/attachment.html>

From gjasny at googlemail.com  Fri May 17 05:23:20 2019
From: gjasny at googlemail.com (Gregor Jasny)
Date: Fri, 17 May 2019 11:23:20 +0200
Subject: [CMake] Why is the binary md5sum value different?
In-Reply-To: <1558054414136-0.post@n2.nabble.com>
References: <1558054414136-0.post@n2.nabble.com>
Message-ID: <8936feec-417d-1253-e0fd-a0acd61c7215@googlemail.com>

On 17.05.19 02:53, Gelryun wrote:
> I write MakefileList.txt like this.
> 
> ------------------------------------------------------------------------
> include_directories(${COMMINC_DIR} ${DBINC_DIR} ./)
> link_directories(${DBLIB_DIR} ${COMMLIB_DIR})
> 
> set(DBUSERID withdb/ufdb)
> PREPROCESS_ORACLE_FILES(ACK_db.pc ${DBUSERID} "${DBINC_DIR};${COMMINC_DIR}")
> 
> set(ACK_P_SRCS
>          ACK_db.c ACK_p.c)
> 
> set(ACK_C_SRCS
>          ACK_db.c ACK_c.c)
> 
> add_executable(ACK_p ${ACK_P_SRCS})
> add_executable(ACK_c ${ACK_C_SRCS})
> ...
> When I install it, the md5sum value of the binaries there is different.
> 
> Why is the binary md5sum value different?

This is probably due to rpaths being re-written (see 
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling).

You could use 
https://manpages.debian.org/testing/diffoscope/diffoscope.1.en.html to 
find out differences between two binaries.

Thanks,
Gregor

From frodak17 at gmail.com  Fri May 17 09:43:38 2019
From: frodak17 at gmail.com (frodak17)
Date: Fri, 17 May 2019 09:43:38 -0400
Subject: [CMake] How to Build Subdirectory CMake Project GLFW and Change
 Targets
In-Reply-To: <CAOLWVF=whWsqAA32ZfSC1+72ve4gjcKfQVPivuMDLSXzJqR2Lg@mail.gmail.com>
References: <CAOLWVF=whWsqAA32ZfSC1+72ve4gjcKfQVPivuMDLSXzJqR2Lg@mail.gmail.com>
Message-ID: <CAM_JqVkh9FSz07ZwoisjKqqJ40_6CJps8Wys3tRpsP18qnaPXw@mail.gmail.com>

On Fri, May 17, 2019 at 2:55 AM junk email <mlg420sniperxxx69 at gmail.com>
wrote:

> Hello,
>
> I am trying to understand how to build a subdirectory project that has its
> own CMakeLists.txt file already setup. In this case, I am using the open
> source library GLFW to help me with some of my OpenGL applications. Here is
> a sample directory structure I am working with.
>
> Root
> ??? CMakeLists.txt
> ??? MainProject
> ??? build
> ??? glfw-3.3
>
> The folder MainProject is where I will be doing all my own development and
> has a src, include, and lib folder associated with it. The glfw-3.3
> directory was downloaded from online and has its own CMakeLists.txt file as
> mentioned previously. So if I were to build my project from the current
> build directory shown here, how should I add the glfw library to it and
> also change its target outputs?
>
> Answers online suggest using ExternalProject_Add(), while others say to
> simply add_subdirectory() and then change some of the properties. I want to
> be able to have a user run the root CMake file and have the targets be
> correctly placed (since users might be on different operating systems).
> Either way I have not been able to find an explicit example, perhaps my
> Googling skills for CMake are lacking, and any help on this would be
> appreciated. Thank you for your time.
>
> Best,
> mlg
>
>
>
If Root/CMakeLists.txt is the root of the source directory it's pretty
simple.  Just use add_subdirectory() as usual.

Again I don't follow why GLFW targets would have to change.  It builds in
the Build directory like everything else.  In this case it would be
Root/build/glfw-3.3 (assuming Root/build is what was supplied on the
command line as something like "cmake -S Root -B Root/build").

For me I downloaded GLFW and put it outside my source tree.  Then I just
used a relative path to it's location.  Because it is outside the source
tree I had to specify the build directory to use.

But GLFW looked to be pretty simple and there wasn't any changes to its
CMakeLists.txt file.  I just set some of the options to blank so that they
wouldn't be built.

This is from the CMakeLists.txt for my directory structure:
set(GLFW_BUILD_DOCS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_TESTS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "" FORCE)
set(GLFW_INSTALL OFF CACHE BOOL "" FORCE)
add_subdirectory(../glfw-3.2.1 glfw)
...
target_link_libraries(application glfw)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190517/b5709cc0/attachment.html>

From frodak17 at gmail.com  Fri May 17 10:00:43 2019
From: frodak17 at gmail.com (frodak17)
Date: Fri, 17 May 2019 10:00:43 -0400
Subject: [CMake] Language Dependency for TCL?
In-Reply-To: <54a316ee-e402-9eb3-515e-90dba630e579@gmail.com>
References: <54a316ee-e402-9eb3-515e-90dba630e579@gmail.com>
Message-ID: <CAM_JqVnXMKnGE89aDJQmZNB+Rp6mAbSa2f75Ti5oss7cnuGZEQ@mail.gmail.com>

On Thu, May 16, 2019 at 5:05 PM hex <hex7c3 at gmail.com> wrote:

> hello,
>
> I am setting up a TCL project so I disabled all language variables:
>
> *cmake_minimum_required(VERSION 2.4)*
>
> *project(P LANGUAGES NONE)*
> *find_package(TCL)*
>
>
> however, this fails with
>
> *-- Could NOT find TCL (missing: TCL_LIBRARY) *
> *-- Could NOT find TCLTK (missing: TCL_LIBRARY TK_LIBRARY) *
> *-- Could NOT find TK (missing: TK_LIBRARY) *
>
>
> If I instead add languages to the project the TCL package works. This
> makes me wonder what dependencies TCL has with standard languages. Is the
> package incomplete? Why do I need to use a language that I do not intend to
> use?
>
> for example:
>
> *cmake_minimum_required(VERSION 2.4)*
>
> *project(P LANGUAGES C)*
> *find_package(TCL)*
>
> *-- Found Tclsh: /usr/bin/tclsh (found version "8.6") *
> *-- Found TCL: /usr/lib/x86_64-linux-gnu/libtcl.so  *
> *-- Found TCLTK: /usr/lib/x86_64-linux-gnu/libtcl.so  *
> *-- Found TK: /usr/lib/x86_64-linux-gnu/libtk.so  *
>
>
> thank you
> --
>
>
Probably because the following isn't properly set if you don't enable a
language:
CMAKE_FIND_LIBRARY_SUFFIXES
CMAKE_FIND_LIBRARY_PREFIXES

You could probably just use "find_package(Tclsh)" to just find the shell.
https://cmake.org/cmake/help/v3.14/module/FindTclsh.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190517/ca03eb88/attachment-0001.html>

From hex7c3 at gmail.com  Sat May 18 09:20:08 2019
From: hex7c3 at gmail.com (hex)
Date: Sat, 18 May 2019 14:20:08 +0100
Subject: [CMake] Language Dependency for TCL?
In-Reply-To: <CAM_JqVnXMKnGE89aDJQmZNB+Rp6mAbSa2f75Ti5oss7cnuGZEQ@mail.gmail.com>
References: <54a316ee-e402-9eb3-515e-90dba630e579@gmail.com>
 <CAM_JqVnXMKnGE89aDJQmZNB+Rp6mAbSa2f75Ti5oss7cnuGZEQ@mail.gmail.com>
Message-ID: <dd0cb897-7bd9-e01d-249e-5a362254ef1b@gmail.com>

I didn't know about Tclsh. I see now it is part of TCL. This is useful, 
thank you.

> Probably because the following isn't properly set if you don't enable 
> a language:
> CMAKE_FIND_LIBRARY_SUFFIXES
> CMAKE_FIND_LIBRARY_PREFIXES
>
> You could probably just use "find_package(Tclsh)" to just find the shell.
> https://cmake.org/cmake/help/v3.14/module/FindTclsh.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190518/08bd3c7d/attachment.html>

From osmanzakir90 at hotmail.com  Sun May 19 15:33:46 2019
From: osmanzakir90 at hotmail.com (Osman Zakir)
Date: Sun, 19 May 2019 19:33:46 +0000
Subject: [CMake] Specifying VS 2019 LLVM toolset on CMake command line?
Message-ID: <SG2PR06MB315812D2B89E8BADABB27DAED3050@SG2PR06MB3158.apcprd06.prod.outlook.com>

How do I specify the VS 2019 LLVM toolset when configuring a build with CMake on the command line?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190519/d6e34443/attachment.html>

From hex7c3 at gmail.com  Mon May 20 10:01:30 2019
From: hex7c3 at gmail.com (hex)
Date: Mon, 20 May 2019 15:01:30 +0100
Subject: [CMake] optional parameters in add_custom_target?
Message-ID: <965b84a0-8926-1799-01da-283f9981e7d8@gmail.com>

The function is defined as

*add_custom_target(Name [ALL] [command1 [args1...]]**
**?? [COMMAND command2 [args2...] ...]**
**?? [DEPENDS depend depend depend ... ]**
**?? [BYPRODUCTS [files...]]**
**?? [WORKING_DIRECTORY dir]**
**?? [COMMENT comment]**
**?? [VERBATIM] [USES_TERMINAL]**
**?? [COMMAND_EXPAND_LISTS]**
**?? [SOURCES src1 [src2...]]**
**)*

While its arguments are all documented, I am confused about its optional 
parameters:

*add_custom_target(Name [ALL] [command1 [args1...]]*

- ALL: target depends on ALL

- command1 [args1...]]: ???


What means command1 [args1...]]? Or, should this read

*add_custom_target(Name [ALL] [COMMAND command1 [args1...]]**
**?? [COMMAND command2 [args2...] ...]*

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

From gjasny at googlemail.com  Mon May 20 11:29:25 2019
From: gjasny at googlemail.com (Gregor Jasny)
Date: Mon, 20 May 2019 17:29:25 +0200
Subject: [CMake] optional parameters in add_custom_target?
In-Reply-To: <965b84a0-8926-1799-01da-283f9981e7d8@gmail.com>
References: <965b84a0-8926-1799-01da-283f9981e7d8@gmail.com>
Message-ID: <b6075d7c-8a22-936c-cfd1-f4043ff0ded7@googlemail.com>

Hello,

On 20.05.19 16:01, hex wrote:
> What means command1 [args1...]]? Or, should this read
> 
> *add_custom_target(Name [ALL] [COMMAND command1 [args1...]]**
> **?? [COMMAND command2 [args2...] ...]*

I believe this is due to backward compatibility (pre 2.6) reasons so 
that you could still write:

add_custom_target(sometarget /bin/true)

Thanks,
Gregor

From tdiff at yandex.ru  Mon May 20 16:38:48 2019
From: tdiff at yandex.ru (A.Dmitrovsky)
Date: Mon, 20 May 2019 23:38:48 +0300
Subject: [CMake] Building CMake with custom OpenSSL
Message-ID: <13282451558384728@myt1-bc8ef50fb490.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190520/6c504d63/attachment.html>

From hex7c3 at gmail.com  Tue May 21 05:44:52 2019
From: hex7c3 at gmail.com (hex)
Date: Tue, 21 May 2019 10:44:52 +0100
Subject: [CMake] cmake doesn't run all tests
In-Reply-To: <DBBPR08MB4315F64D5159D861B5083D7A83070@DBBPR08MB4315.eurprd08.prod.outlook.com>
References: <DBBPR08MB4315F64D5159D861B5083D7A83070@DBBPR08MB4315.eurprd08.prod.outlook.com>
Message-ID: <dccd393b-29c6-1a74-54bc-fc6d16a8cdb0@gmail.com>

> hello,
>
> I have two modules in my CMake project:
>
> /root//
> //??? foo//
> //??? ??? CMakeLists.txt//
> //??? ??? src//
> //??? ??? ??? foo.c//
> //??? ??? tests//
> //??????? ??? foo_unit_test.c//
> //??????? ??? CMakeLists.txt//
> //??? CMakeLists.txt//
> //??? moo//
> //??? ??? CMakeLists.txt//
> //??? ??? src//
> //??? ??? ??? moo.c//
> //??? ??? tests//
> //??????? ??? CMakeLists.txt//
> //??????? ??? moo_unit_test.c//
> /
> my root project has:
>
> /enable_testing()//
> //
> //add_subdirectory(adder)//
> //add_subdirectory(viterbi_encoder)/
>
>
> and each module has:
>
> /add_subdirectory(tests)/
>
>
> For the tests I am using add_test() and make all test.
>
> yet, this only runs the tests within the first add_subdirectory. Other 
> modules are ignored.
>
> How can I run all tests at once?
>
> Thank you in advance.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190521/7cc1b26f/attachment.html>

From eric.noulard at gmail.com  Tue May 21 06:11:27 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 21 May 2019 12:11:27 +0200
Subject: [CMake] cmake doesn't run all tests
In-Reply-To: <dccd393b-29c6-1a74-54bc-fc6d16a8cdb0@gmail.com>
References: <DBBPR08MB4315F64D5159D861B5083D7A83070@DBBPR08MB4315.eurprd08.prod.outlook.com>
 <dccd393b-29c6-1a74-54bc-fc6d16a8cdb0@gmail.com>
Message-ID: <CAPASGLr237uqbvoA9A92Cc_bPNAf5J7Ag2yupKU6KJG4Z_aDWw@mail.gmail.com>

Le mar. 21 mai 2019 ? 11:45, hex <hex7c3 at gmail.com> a ?crit :

> hello,
>
> I have two modules in my CMake project:
>
> *root*
> *??? foo*
> *?   ??? CMakeLists.txt*
> *?   ??? src*
> *?   ?   ??? foo.c*
> *?   ??? tests*
> *?       ??? foo_unit_test.c*
> *?       ??? CMakeLists.txt*
> *??? CMakeLists.txt*
> *??? moo*
> *    ??? CMakeLists.txt*
> *    ??? src*
> *    ?   ??? moo.c*
> *    ??? tests*
> *        ??? CMakeLists.txt*
> *        ??? moo_unit_test.c*
>
> my root project has:
>
> *enable_testing()*
>
> *add_subdirectory(adder)*
> *add_subdirectory(viterbi_encoder)*
>
>
> and each module has:
>
> *add_subdirectory(tests)*
>
>
> For the tests I am using add_test() and make all test.
>
> yet, this only runs the tests within the first add_subdirectory. Other
> modules are ignored.
>
> Do the CMakeLists.txt in the sub-directory have their own project command
or is your main top-level CMakeLists.txt the only CMakeLists.txt with
project  command ?

How can I run all tests at once?
>
> How do yu run the tests?

make tests ?
ninja tests ?
ctest ?

What does
$ ctest -N
says?

This should work at least it "works-for-me" so there must be some
difference between the CMakeLists.txt in the directory that works and in
the directory that does not.
Do you have a sample setup which exhibit the issue that you can share?


Thank you in advance.
>
> --
>
> 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/20190521/cffbfb8b/attachment.html>

From hex7c3 at gmail.com  Tue May 21 07:08:04 2019
From: hex7c3 at gmail.com (hex)
Date: Tue, 21 May 2019 12:08:04 +0100
Subject: [CMake] cmake doesn't run all tests
In-Reply-To: <CAPASGLr237uqbvoA9A92Cc_bPNAf5J7Ag2yupKU6KJG4Z_aDWw@mail.gmail.com>
References: <DBBPR08MB4315F64D5159D861B5083D7A83070@DBBPR08MB4315.eurprd08.prod.outlook.com>
 <dccd393b-29c6-1a74-54bc-fc6d16a8cdb0@gmail.com>
 <CAPASGLr237uqbvoA9A92Cc_bPNAf5J7Ag2yupKU6KJG4Z_aDWw@mail.gmail.com>
Message-ID: <72380a5b-f1d2-e715-677d-ef0db56eaa45@gmail.com>

hello Eric,

Some of my recent changes prevented my function to add a build target. 
It was building either one or the other but not both. Therefore, half of 
the tests where missing.

You are right it is working correctly now.

thank you for your patience.

> This should work at least it "works-for-me" so there must be some 
> difference between the CMakeLists.txt in the directory that works and 
> in the directory that does not.
> Do you have a sample setup which exhibit the issue that you can share?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190521/643dc525/attachment.html>

From robert.maynard at kitware.com  Tue May 21 13:34:21 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 21 May 2019 13:34:21 -0400
Subject: [CMake] Building CMake with custom OpenSSL
In-Reply-To: <13282451558384728@myt1-bc8ef50fb490.qloud-c.yandex.net>
References: <13282451558384728@myt1-bc8ef50fb490.qloud-c.yandex.net>
Message-ID: <CAFzjYVpuY7GnAJiPHcPepznetrg-Sd=NPZsH=_7V0B-Lz4K53g@mail.gmail.com>

I don't believe that we test CMake with that configuration of OpenSSL.
If it works, I cant promise it will continue to work going forward.

On Mon, May 20, 2019 at 4:44 PM A.Dmitrovsky <tdiff at yandex.ru> wrote:
>
> Hi,
>
> I am building CMake (on x64 linux) with custom OpenSSL and wondering if there are any CMake requirements on how OpenSSL should be compiled. Specifically, I'm interested to know if it is valid to link CMake with single-threaded OpenSSL library (configured with "no-threads" option).
>
> May be it is documented somewhere?
>
> Regards,
> Anton
> --
>
> 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 sz.richard at gmail.com  Wed May 22 01:48:37 2019
From: sz.richard at gmail.com (Richard Szabo)
Date: Wed, 22 May 2019 07:48:37 +0200
Subject: [CMake] transitive linkage of OBJECT library targets
Message-ID: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>

Hi cmakers

I'm trying to get the following example working:
```
cmake_minimum_required(VERSION 3.14)
project(test_object_lib_nesting)

set(CMAKE_CXX_STANDARD 14)

add_library(first_object_lib OBJECT first.cpp)

add_library(second_object_lib OBJECT second.cpp)

target_link_libraries(second_object_lib first_object_lib)

add_executable(test_object_lib_nesting main.cpp)

target_link_libraries(test_object_lib_nesting second_object_lib)
```

The problem I have that the linker command line will have only the
second.cpp.o for linking the first.cpp.o will not be added as link
object to the exe. Causing missing symbols on exe linkage.

How to transitively resolve and link "nested" Object library targets ?.

From hex7c3 at gmail.com  Wed May 22 03:57:30 2019
From: hex7c3 at gmail.com (hex)
Date: Wed, 22 May 2019 08:57:30 +0100
Subject: [CMake] transitive linkage of OBJECT library targets
In-Reply-To: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
References: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
Message-ID: <0d8f55f1-c14a-abe1-71f1-d65905e1d679@gmail.com>

Without cycling dependencies you can do something like this:

/add_executable(test_object_lib_nesting main.cpp)//
//
//target_link_libraries(test_object_lib_nesting//
//??? second_object_lib//
//??? first_object_lib//
//)/

> The problem I have that the linker command line will have only the
> second.cpp.o for linking the first.cpp.o will not be added as link
> object to the exe. Causing missing symbols on exe linkage.
>
> How to transitively resolve and link "nested" Object library targets ?.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190522/2d6e7645/attachment.html>

From workbench at gmx.at  Wed May 22 05:08:36 2019
From: workbench at gmx.at (Steven Truppe)
Date: Wed, 22 May 2019 11:08:36 +0200
Subject: [CMake] Problems with ExternalProject_Add
Message-ID: <ea6ea973-5983-a9d4-1846-0806d61dad80@gmx.at>

Hi everyone,


i'm trying to use ExternalProject_Add like the following:

set(BOOST_VERSION 1.68.0)
set(BOOST_VERSION_NODOTS 1_68_0)
set(BOOST_URI https://dl.bintray.com/boostorg/release/${BOOST_VERSION}/source/boost_${BOOST_VERSION_NODOTS}.tar.gz)
set(BOOST_HASH 5d8b4503582fffa9eefdb9045359c239)

ExternalProject_Add(external_boost
         PREFIX ${CMAKE_BINARY_DIR}/boost
		URL ${BOOST_URL}
         DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost
		URL_HASH MD5=${BOOST_HASH}
         CONFIGURE_COMMAND  cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ./bootstrab --prefix=${OUTPUT_PATH}/boost
		BUILD_COMMAND  cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ./b2
		BUILD_IN_SOURCE 1
		INSTALL_DIR ${OUTPUT_PATH}/boost

The problem is that he tells me that the md5 sum isn't correct, but i did md5sum ${BOOST_URL}.


I now play around with this for nearnly an hour and i allways get the same error.

I hope someone here can help me out.

best regards,
Steven Truppe

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

From workbench at gmx.at  Wed May 22 07:37:55 2019
From: workbench at gmx.at (Steven Truppe)
Date: Wed, 22 May 2019 13:37:55 +0200
Subject: [CMake] Troubles with booost and ExternalLibraries_Add
Message-ID: <25a6c869-e1fe-4ced-6d93-a1c2d88a6c69@gmx.at>

Hi everyone,


i'm trying to get the boost library working with cmake and
externalproject_add:


https://paste.debian.net/1082645/


best regards!


From petr.kmoch at gmail.com  Wed May 22 07:56:48 2019
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 22 May 2019 13:56:48 +0200
Subject: [CMake] transitive linkage of OBJECT library targets
In-Reply-To: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
References: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
Message-ID: <CAKohaZf=bzqG7+fA_DNvKMzhsnQy-wJUKuOvO9zvFxmHoFujMg@mail.gmail.com>

Hi Richard,

does it help if you specify the linking as PUBLIC? I.e.:

target_link_libraries(second_object_lib PUBLIC first_object_lib)

Petr

On Wed, 22 May 2019 at 07:48, Richard Szabo <sz.richard at gmail.com> wrote:

> Hi cmakers
>
> I'm trying to get the following example working:
> ```
> cmake_minimum_required(VERSION 3.14)
> project(test_object_lib_nesting)
>
> set(CMAKE_CXX_STANDARD 14)
>
> add_library(first_object_lib OBJECT first.cpp)
>
> add_library(second_object_lib OBJECT second.cpp)
>
> target_link_libraries(second_object_lib first_object_lib)
>
> add_executable(test_object_lib_nesting main.cpp)
>
> target_link_libraries(test_object_lib_nesting second_object_lib)
> ```
>
> The problem I have that the linker command line will have only the
> second.cpp.o for linking the first.cpp.o will not be added as link
> object to the exe. Causing missing symbols on exe linkage.
>
> How to transitively resolve and link "nested" Object library targets ?.
> --
>
> 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/20190522/b3a846d8/attachment-0001.html>

From robert.maynard at kitware.com  Wed May 22 08:25:01 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 22 May 2019 08:25:01 -0400
Subject: [CMake] transitive linkage of OBJECT library targets
In-Reply-To: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
References: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
Message-ID: <CAFzjYVqr-Rx3HjSVfY4AKXQUq2NDqYpd9x8We5+UK650nBvbGQ@mail.gmail.com>

This is a known limitation of the current design. Only directly linked
object library objects are propagated.

For more details on why see: https://gitlab.kitware.com/cmake/cmake/issues/18090

On Wed, May 22, 2019 at 1:48 AM Richard Szabo <sz.richard at gmail.com> wrote:
>
> Hi cmakers
>
> I'm trying to get the following example working:
> ```
> cmake_minimum_required(VERSION 3.14)
> project(test_object_lib_nesting)
>
> set(CMAKE_CXX_STANDARD 14)
>
> add_library(first_object_lib OBJECT first.cpp)
>
> add_library(second_object_lib OBJECT second.cpp)
>
> target_link_libraries(second_object_lib first_object_lib)
>
> add_executable(test_object_lib_nesting main.cpp)
>
> target_link_libraries(test_object_lib_nesting second_object_lib)
> ```
>
> The problem I have that the linker command line will have only the
> second.cpp.o for linking the first.cpp.o will not be added as link
> object to the exe. Causing missing symbols on exe linkage.
>
> How to transitively resolve and link "nested" Object library targets ?.
> --
>
> 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 dk at ventas.de  Wed May 22 08:23:07 2019
From: dk at ventas.de (Daniel Kroker)
Date: Wed, 22 May 2019 14:23:07 +0200
Subject: [CMake] Problems with cross compile for android
Message-ID: <b6a089e0-e54c-4660-57e5-89173cda7c51@ventas.de>

Hello,

i have some problems with cross compile for android.
i need to build libssh for android.

If i run CMake like:
cmake .. -DCMAKE_SYSTEM_NAME=Android
-DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/home/da/Android/standalone-toolchain-4.9
-DCMAKE_SYSTEM_VERSION=21

i get the following error:

?-mtune=xscale -funwind-tables -no-canonical-prefixes? -g? -fPIE -pie
-Wl,--gc-sections -Wl,-z,nocopyreloc?
CMakeFiles/cmTC_88c04.dir/testCCompiler.c.o? -o cmTC_88c04
???
/home/da/Android/standalone-toolchain-4.9/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld:
error: cannot open crtbegin_dynamic.o: No such file or directory
???
/home/da/Android/standalone-toolchain-4.9/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld:
error: cannot open crtend_android.o: No such file or directory
??? external/jemalloc/src/jemalloc.c:1422: error: undefined reference to
'pthread_atfork'
??? external/jemalloc/src/jemalloc.c:1422: error: undefined reference to
'pthread_atfork'
??? external/jemalloc/src/jemalloc.c:1422: error: undefined reference to
'pthread_atfork'
??? external/jemalloc/src/jemalloc.c:1422: error: undefined reference to
'pthread_atfork'
??? external/jemalloc/src/jemalloc.c:1358: error: undefined reference to
'atexit'
??? clang80: error: linker command failed with exit code 1 (use -v to
see invocation)
??? make[1]: *** [CMakeFiles/cmTC_88c04.dir/build.make:87: cmTC_88c04]
Error 1
??? make[1]: Leaving directory
'/home/da/Downloads/libssh-0.7.4/build/CMakeFiles/CMakeTmp'
??? make: *** [Makefile:121: cmTC_88c04/fast] Error 2


if i run
cmake .. -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release
-DCMAKE_SYSTEM_NAME=Android
-DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_ROOT/build/cmake/android.toolchain.cmake
-DANDROID_STL_TYPE=gnustl_static -DCMAKE_SYSTEM_VERSION=21
-DANDROID_TOOLCHAIN=clang -DANDROID_PLATFORM=android-21
-DANDROID_ABI=arm64-v8a

i get the following message:
-- Performing Test HAVE_COMPILER__FUNCTION__ - Failed
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - not found
-- Looking for stdint.h
-- Looking for stdint.h - not found
-- Looking for stddef.h
-- Looking for stddef.h - not found
-- Check size of unsigned short
-- Check size of unsigned short - failed
-- Check size of unsigned int
-- Check size of unsigned int - failed
-- Check size of unsigned long
-- Check size of unsigned long - failed
CMake Error at /usr/share/cmake-3.13/Modules/TestBigEndian.cmake:49
(message):
? no suitable type found
Call Stack (most recent call first):
? ConfigureChecks.cmake:271 (test_big_endian)
? CMakeLists.txt:80 (include)

looks like that he doesnt find any header file.

Whats the best way to cross compile under linux for android?
Thanks for any suggestions.

Regards
Daniel


From niels_dekker_address_until_2024 at xs4all.nl  Wed May 22 09:37:10 2019
From: niels_dekker_address_until_2024 at xs4all.nl (Niels Dekker)
Date: Wed, 22 May 2019 15:37:10 +0200
Subject: [CMake] Visual Studio platform name ("Win32",
 "x64") back on CMake GUI window?
Message-ID: <996503fb90ae5a58023bbbf7e71355ab@xs4all.nl>

Previous versions of CMake GUI (prior to CMake 3.14) always displayed 
the name of the selected platform (typically "Win32" or "Win64") with 
the current generator, for example:

   "Current Generator: Visual Studio 14 2015 Win64"

It was very convenient to have the platform name displayed on the main 
window of the CMake GUI.

When a new Visual Studio project is generated "from scratch" by CMake 
3.14, the platform name is no longer displayed with the Current 
Generator. As I just tested with CMake 3.14.4, generating for VS2017 
x64.

Would it be possible to get the VS platform name back onto the CMake GUI 
main window?


Kind regards, Niels
-- 
Niels Dekker
Scientific programmer
LKEB, Leiden University Medical Center

From rcdailey.lists at gmail.com  Wed May 22 09:58:04 2019
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Wed, 22 May 2019 08:58:04 -0500
Subject: [CMake] How to use Ninja on Windows with MSVC?
Message-ID: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>

>From the command line, I want to generate Ninja build scripts that
utilize a specific version of MSVC compiler. Basically I'd like the
combination of `-G"Visual Studio 15 2017"` with regards to its ability
to find the C and C++ compiler on the system via registry/environment
variables, and `-G"Ninja"` with regards to it being the build driver
for that compiler.

Is this even possible?

From haocheng.liu at kitware.com  Wed May 22 10:10:17 2019
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Wed, 22 May 2019 10:10:17 -0400
Subject: [CMake] How to use Ninja on Windows with MSVC?
In-Reply-To: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
References: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
Message-ID: <CACbTE7MOAkkaFaQ+CrAU+g9EY_djx5kqxjPoTKy-iTU8qdArcg@mail.gmail.com>

You can run `CMake -GNinja <path to source folder>` in a visual studio
command line prompt where It could find the right C/C++ compiler via the
environment. Normally you can find the command line prompt in the windows
menu.

On Wed, May 22, 2019 at 9:58 AM Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> From the command line, I want to generate Ninja build scripts that
> utilize a specific version of MSVC compiler. Basically I'd like the
> combination of `-G"Visual Studio 15 2017"` with regards to its ability
> to find the C and C++ compiler on the system via registry/environment
> variables, and `-G"Ninja"` with regards to it being the build driver
> for that compiler.
>
> Is this even possible?
> --
>
> 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
>


-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
1712 Route 9, Suite 300
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190522/fdaeccda/attachment.html>

From marc.chevrier at gmail.com  Wed May 22 10:18:14 2019
From: marc.chevrier at gmail.com (Marc CHEVRIER)
Date: Wed, 22 May 2019 16:18:14 +0200
Subject: [CMake] How to use Ninja on Windows with MSVC?
In-Reply-To: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
References: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
Message-ID: <0fc5f430-5952-4301-a085-94f9f63b299c@Spark>

The easiest way is to launch a CMD with the correct development environment (see for example?https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs).

Le 22 mai 2019 ? 15:58 +0200, Robert Dailey <rcdailey.lists at gmail.com>, a ?crit :
> From the command line, I want to generate Ninja build scripts that
> utilize a specific version of MSVC compiler. Basically I'd like the
> combination of `-G"Visual Studio 15 2017"` with regards to its ability
> to find the C and C++ compiler on the system via registry/environment
> variables, and `-G"Ninja"` with regards to it being the build driver
> for that compiler.
>
> Is this even possible?
> --
>
> 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/20190522/df2507f6/attachment-0001.html>

From mike.jackson at bluequartz.net  Wed May 22 11:26:59 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 22 May 2019 11:26:59 -0400
Subject: [CMake] How to use Ninja on Windows with MSVC?
In-Reply-To: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
References: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
Message-ID: <12E5BA4D-1A99-4C61-BCF9-EB33C840E07F@bluequartz.net>

Do this all the time both for our CDash nightlies and when I am developing on Windows. The essential pieces of the puzzle are the following:

1: Ninja needs to be on your path
2: The compilers need to be on your path.

1 can be solved in a few different ways. The brute force is to edit the system path variable and place the folder containing Ninja into the system path. I do NOT recommend doing this. Repeat. DON'T DO IT. You can edit your "User" PATH environment variable and add to the PATH. This is the more recommended way but a bit tedious to get into that dialog box to adjust. We will come back to this..

For 2, use the "Visual Studio Command Prompt" which has all the paths to the compilers setup for you. Now the question becomes, how to combine 1 and 2. My own solution (which is far from optimal, but works) is that I setup my own "short cut" to a command prompt that launches my own custom .bat file that sits on my desktop. In that .bat file is basically a copy of the vcvarsall.bat file and then I add to that my own specific PATH values for things like Qt, hdf5, cmake, ninja that on located on my system. I keep both the shortcut and the .bat file on my desktop so all I need to do is double click to get a correctly configured command prompt for my dev environment. If a version of something changes I just edit the .bat file and I am ready to go. You can then also do "cmake-gui.exe ." from inside a build folder to have CMake-Gui launch with all the correctly identified compilers. 

I am happy to share the .bat file if you are interested. I have it updated for VS2017 at the moment but have been doing it this way since VS2013.

--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>

?On 5/22/19, 9:58 AM, "CMake on behalf of Robert Dailey" <cmake-bounces at cmake.org on behalf of rcdailey.lists at gmail.com> wrote:

    From the command line, I want to generate Ninja build scripts that
    utilize a specific version of MSVC compiler. Basically I'd like the
    combination of `-G"Visual Studio 15 2017"` with regards to its ability
    to find the C and C++ compiler on the system via registry/environment
    variables, and `-G"Ninja"` with regards to it being the build driver
    for that compiler.
    
    Is this even possible?
    -- 
    



From juan.e.sanchez at gmail.com  Wed May 22 11:41:14 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Wed, 22 May 2019 10:41:14 -0500
Subject: [CMake] How to use Ninja on Windows with MSVC?
In-Reply-To: <12E5BA4D-1A99-4C61-BCF9-EB33C840E07F@bluequartz.net>
References: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
 <12E5BA4D-1A99-4C61-BCF9-EB33C840E07F@bluequartz.net>
Message-ID: <CAEHOsR1-+hkC4X+bz1DsUTnPh0QK-6_-Gjk7HUKZhgvgeyFukA@mail.gmail.com>

On Wed, May 22, 2019 at 10:27 AM Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> Do this all the time both for our CDash nightlies and when I am developing
> on Windows. The essential pieces of the puzzle are the following:
>
> 1: Ninja needs to be on your path
> 2: The compilers need to be on your path.
>
> 1 can be solved in a few different ways. The brute force is to edit the
> system path variable and place the folder containing Ninja into the system
> path. I do NOT recommend doing this. Repeat. DON'T DO IT. You can edit your
> "User" PATH environment variable and add to the PATH. This is the more
> recommended way but a bit tedious to get into that dialog box to adjust. We
> will come back to this..
>
> For 2, use the "Visual Studio Command Prompt" which has all the paths to
> the compilers setup for you. Now the question becomes, how to combine 1 and
> 2. My own solution (which is far from optimal, but works) is that I setup
> my own "short cut" to a command prompt that launches my own custom .bat
> file that sits on my desktop. In that .bat file is basically a copy of the
> vcvarsall.bat file and then I add to that my own specific PATH values for
> things like Qt, hdf5, cmake, ninja that on located on my system. I keep
> both the shortcut and the .bat file on my desktop so all I need to do is
> double click to get a correctly configured command prompt for my dev
> environment. If a version of something changes I just edit the .bat file
> and I am ready to go. You can then also do "cmake-gui.exe ." from inside a
> build folder to have CMake-Gui launch with all the correctly identified
> compilers.
>

For this option, you can use the batch command, "call", to read in the
environment of another ".bat" script, so that you do not have to make
copies of the vcvarsall.bat files.  As long as you are not using "setlocal"
in a script, then the environment variables will propagate up to the caller.

 For example your script can have (for VS 2015) :
call "%VS140COMNTOOLS%VsVars32.bat"

and the add lines setting additional PATH values.

Regards,

Juan



>
> I am happy to share the .bat file if you are interested. I have it updated
> for VS2017 at the moment but have been doing it this way since VS2013.
>
> --
> Michael Jackson | Owner, President
>       BlueQuartz Software
> [e] mike.jackson at bluequartz.net
> [w] www.bluequartz.net <http://www.bluequartz.net>
>
> ?On 5/22/19, 9:58 AM, "CMake on behalf of Robert Dailey" <
> cmake-bounces at cmake.org on behalf of rcdailey.lists at gmail.com> wrote:
>
>     From the command line, I want to generate Ninja build scripts that
>     utilize a specific version of MSVC compiler. Basically I'd like the
>     combination of `-G"Visual Studio 15 2017"` with regards to its ability
>     to find the C and C++ compiler on the system via registry/environment
>     variables, and `-G"Ninja"` with regards to it being the build driver
>     for that compiler.
>
>     Is this even possible?
>     --
>
>
>
> --
>
> 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/20190522/b6f60b6d/attachment.html>

From mellery451 at gmail.com  Wed May 22 11:44:01 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Wed, 22 May 2019 08:44:01 -0700
Subject: [CMake] How to use Ninja on Windows with MSVC?
In-Reply-To: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
References: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
Message-ID: <35EB4C6D-B988-45B7-AEA9-058433F61585@gmail.com>



> On May 22, 2019, at 6:58 AM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> 
> From the command line, I want to generate Ninja build scripts that
> utilize a specific version of MSVC compiler. Basically I'd like the
> combination of `-G"Visual Studio 15 2017"` with regards to its ability
> to find the C and C++ compiler on the system via registry/environment
> variables, and `-G"Ninja"` with regards to it being the build driver
> for that compiler.
> 
> Is this even possible?
> ? 


In addition to the other suggestions about using a MSVC command prompt (which work just fine for manual builds), Here?s what I?ve done when needing to automate the build using powershell:


Invoke-BatchFile "${env:ProgramFiles(x86)}\\Microsoft Visual Studio\\2017\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat" x86_amd64
Get-ChildItem env:* | Sort-Object name


?which invokes the vcvarsall batch and imports all of the environment vars that were set by that invocation. vcvarsall is provided exactly for the purpose of setting your env for building and it supports a few different arch arguments to select the right toolchain.

HTH,
Mike



From agatakrason at gmail.com  Wed May 22 12:02:28 2019
From: agatakrason at gmail.com (=?UTF-8?Q?Agata_Kraso=C5=84?=)
Date: Wed, 22 May 2019 18:02:28 +0200
Subject: [CMake] question ? [cmake could not find a include_dir]
Message-ID: <CAKKYitPuCGc8VB-9-eevK+ssHGjK6i3i_iSDrMygoCd=YhKNMA@mail.gmail.com>

Hello,

I am trying to build from source an application.
I add in cmake-gui : XIOT_INCLUDE_DIR - path do include dir
When I compile on linux ...
It gives me an error:

[image: Screenshot_20190522_175230.png]
[image: Screenshot_20190522_175209.png]

Do you have any idea ?
What could be a problem?

I would appreciate for any help.

Best,
Agata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190522/1fc36869/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20190522_175230.png
Type: image/png
Size: 79268 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190522/1fc36869/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20190522_175209.png
Type: image/png
Size: 175192 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190522/1fc36869/attachment-0003.png>

From robert.maynard at kitware.com  Wed May 22 12:03:00 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 22 May 2019 12:03:00 -0400
Subject: [CMake] Visual Studio platform name ("Win32",
 "x64") back on CMake GUI window?
In-Reply-To: <996503fb90ae5a58023bbbf7e71355ab@xs4all.nl>
References: <996503fb90ae5a58023bbbf7e71355ab@xs4all.nl>
Message-ID: <CAFzjYVoS6pdaWKxRYupzK6tH=+mhjZTjjL=Xnta=bx4nO=X2sw@mail.gmail.com>

Can you submit this to our issue tracker please (
https://gitlab.kitware.com/cmake/cmake/issues )

On Wed, May 22, 2019 at 9:44 AM Niels Dekker
<niels_dekker_address_until_2024 at xs4all.nl> wrote:
>
> Previous versions of CMake GUI (prior to CMake 3.14) always displayed
> the name of the selected platform (typically "Win32" or "Win64") with
> the current generator, for example:
>
>    "Current Generator: Visual Studio 14 2015 Win64"
>
> It was very convenient to have the platform name displayed on the main
> window of the CMake GUI.
>
> When a new Visual Studio project is generated "from scratch" by CMake
> 3.14, the platform name is no longer displayed with the Current
> Generator. As I just tested with CMake 3.14.4, generating for VS2017
> x64.
>
> Would it be possible to get the VS platform name back onto the CMake GUI
> main window?
>
>
> Kind regards, Niels
> --
> Niels Dekker
> Scientific programmer
> LKEB, Leiden University Medical Center
> --
>
> 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 niels_dekker_address_until_2024 at xs4all.nl  Wed May 22 12:38:26 2019
From: niels_dekker_address_until_2024 at xs4all.nl (Niels Dekker)
Date: Wed, 22 May 2019 18:38:26 +0200
Subject: [CMake] Visual Studio platform name ("Win32",
 "x64") back on CMake GUI window?
In-Reply-To: <CAFzjYVoS6pdaWKxRYupzK6tH=+mhjZTjjL=Xnta=bx4nO=X2sw@mail.gmail.com>
References: <996503fb90ae5a58023bbbf7e71355ab@xs4all.nl>
 <CAFzjYVoS6pdaWKxRYupzK6tH=+mhjZTjjL=Xnta=bx4nO=X2sw@mail.gmail.com>
Message-ID: <d1197716517eaca09a75d4f9f4a00d87@xs4all.nl>

Thanks for your support, Robert! Here it is:

   #19290 "Visual Studio platform name Current Generator back on CMake 
GUI window?"
   https://gitlab.kitware.com/cmake/cmake/issues/19290

Kind regards, Niels

On 2019-05-22, Robert Maynard wrote:
> Can you submit this to our issue tracker please (
> https://gitlab.kitware.com/cmake/cmake/issues )
> 
> On Wed, May 22, 2019 at 9:44 AM Niels Dekker wrote:
>> 
>> Previous versions of CMake GUI (prior to CMake 3.14) always displayed
>> the name of the selected platform (typically "Win32" or "Win64") with
>> the current generator, for example:
>> 
>>    "Current Generator: Visual Studio 14 2015 Win64"
>> 
>> It was very convenient to have the platform name displayed on the main
>> window of the CMake GUI.
>> 
>> When a new Visual Studio project is generated "from scratch" by CMake
>> 3.14, the platform name is no longer displayed with the Current
>> Generator. As I just tested with CMake 3.14.4, generating for VS2017
>> x64.
>> 
>> Would it be possible to get the VS platform name back onto the CMake 
>> GUI
>> main window?

-- 
Niels Dekker
Scientific programmer
LKEB, Leiden University Medical Center

From post at hendrik-sattler.de  Wed May 22 12:31:14 2019
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 22 May 2019 18:31:14 +0200
Subject: [CMake] question ? [cmake could not find a include_dir]
In-Reply-To: <CAKKYitPuCGc8VB-9-eevK+ssHGjK6i3i_iSDrMygoCd=YhKNMA@mail.gmail.com>
References: <CAKKYitPuCGc8VB-9-eevK+ssHGjK6i3i_iSDrMygoCd=YhKNMA@mail.gmail.com>
Message-ID: <CDBBA035-8463-463E-ADC8-3CF51B8F351C@hendrik-sattler.de>

How about using the same build directory?


Am 22. Mai 2019 18:02:28 MESZ schrieb "Agata Kraso?" <agatakrason at gmail.com>:
>Hello,
>
>I am trying to build from source an application.
>I add in cmake-gui : XIOT_INCLUDE_DIR - path do include dir
>When I compile on linux ...
>It gives me an error:
>
>[image: Screenshot_20190522_175230.png]
>[image: Screenshot_20190522_175209.png]
>
>Do you have any idea ?
>What could be a problem?
>
>I would appreciate for any help.
>
>Best,
>Agata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190522/a8b1d658/attachment.html>

From rcdailey.lists at gmail.com  Wed May 22 13:34:38 2019
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Wed, 22 May 2019 12:34:38 -0500
Subject: [CMake] How to use Ninja on Windows with MSVC?
In-Reply-To: <35EB4C6D-B988-45B7-AEA9-058433F61585@gmail.com>
References: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
 <35EB4C6D-B988-45B7-AEA9-058433F61585@gmail.com>
Message-ID: <CAHd499CFFNddVuAV=Skd2szmtS6oeCUzUxcEMuELMm1h4hhE4g@mail.gmail.com>

Thanks everyone. I fully understand about compilers being on PATH or
setting the CMAKE_<LANG>_COMPILER variables. However, what is really
important is the system introspection done by CMake to find the IDEs
when you select the visual studio generators. I was hoping that logic
could be shared. This would save a lot of work in setting up
environment and/or hunting down vcvars batch files.

On Wed, May 22, 2019 at 10:44 AM Michael Ellery <mellery451 at gmail.com> wrote:
>
>
>
> > On May 22, 2019, at 6:58 AM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> >
> > From the command line, I want to generate Ninja build scripts that
> > utilize a specific version of MSVC compiler. Basically I'd like the
> > combination of `-G"Visual Studio 15 2017"` with regards to its ability
> > to find the C and C++ compiler on the system via registry/environment
> > variables, and `-G"Ninja"` with regards to it being the build driver
> > for that compiler.
> >
> > Is this even possible?
> > ?
>
>
> In addition to the other suggestions about using a MSVC command prompt (which work just fine for manual builds), Here?s what I?ve done when needing to automate the build using powershell:
>
>
> Invoke-BatchFile "${env:ProgramFiles(x86)}\\Microsoft Visual Studio\\2017\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat" x86_amd64
> Get-ChildItem env:* | Sort-Object name
>
>
> ?which invokes the vcvarsall batch and imports all of the environment vars that were set by that invocation. vcvarsall is provided exactly for the purpose of setting your env for building and it supports a few different arch arguments to select the right toolchain.
>
> HTH,
> Mike
>
>

From mike.jackson at bluequartz.net  Wed May 22 14:05:25 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 22 May 2019 14:05:25 -0400
Subject: [CMake] How to use Ninja on Windows with MSVC?
In-Reply-To: <CAEHOsR1-+hkC4X+bz1DsUTnPh0QK-6_-Gjk7HUKZhgvgeyFukA@mail.gmail.com>
References: <CAHd499Bwp0gV0hG1o1Myki6m+w+XVmuN2wtusBkDCVgkZnVODA@mail.gmail.com>
 <12E5BA4D-1A99-4C61-BCF9-EB33C840E07F@bluequartz.net>
 <CAEHOsR1-+hkC4X+bz1DsUTnPh0QK-6_-Gjk7HUKZhgvgeyFukA@mail.gmail.com>
Message-ID: <890ABA5C-7C0D-4FF3-A523-0F04BC3BE948@bluequartz.net>

Cool tip. Didn?t know that. I should compact my script a bit. I do that for the Intel Fortran compiler that we use but didn?t think of it for the vcvarsall.bat file.

 

--

Mike Jackson 

 

From: Juan Sanchez <juan.e.sanchez at gmail.com>
Date: Wednesday, May 22, 2019 at 11:41 AM
To: Michael Jackson <mike.jackson at bluequartz.net>
Cc: Robert Dailey <rcdailey.lists at gmail.com>, CMake <cmake at cmake.org>
Subject: Re: [CMake] How to use Ninja on Windows with MSVC?

 

 

 

On Wed, May 22, 2019 at 10:27 AM Michael Jackson <mike.jackson at bluequartz.net> wrote:

Do this all the time both for our CDash nightlies and when I am developing on Windows. The essential pieces of the puzzle are the following:

1: Ninja needs to be on your path
2: The compilers need to be on your path.

1 can be solved in a few different ways. The brute force is to edit the system path variable and place the folder containing Ninja into the system path. I do NOT recommend doing this. Repeat. DON'T DO IT. You can edit your "User" PATH environment variable and add to the PATH. This is the more recommended way but a bit tedious to get into that dialog box to adjust. We will come back to this..

For 2, use the "Visual Studio Command Prompt" which has all the paths to the compilers setup for you. Now the question becomes, how to combine 1 and 2. My own solution (which is far from optimal, but works) is that I setup my own "short cut" to a command prompt that launches my own custom .bat file that sits on my desktop. In that .bat file is basically a copy of the vcvarsall.bat file and then I add to that my own specific PATH values for things like Qt, hdf5, cmake, ninja that on located on my system. I keep both the shortcut and the .bat file on my desktop so all I need to do is double click to get a correctly configured command prompt for my dev environment. If a version of something changes I just edit the .bat file and I am ready to go. You can then also do "cmake-gui.exe ." from inside a build folder to have CMake-Gui launch with all the correctly identified compilers. 

 

For this option, you can use the batch command, "call", to read in the environment of another ".bat" script, so that you do not have to make copies of the vcvarsall.bat files.  As long as you are not using "setlocal" in a script, then the environment variables will propagate up to the caller.

 

 For example your script can have (for VS 2015) :

call "%VS140COMNTOOLS%VsVars32.bat"  

 

and the add lines setting additional PATH values.

 

Regards,

 

Juan

 

 


I am happy to share the .bat file if you are interested. I have it updated for VS2017 at the moment but have been doing it this way since VS2013.

--
Michael Jackson | Owner, President
      BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>

?On 5/22/19, 9:58 AM, "CMake on behalf of Robert Dailey" <cmake-bounces at cmake.org on behalf of rcdailey.lists at gmail.com> wrote:

    From the command line, I want to generate Ninja build scripts that
    utilize a specific version of MSVC compiler. Basically I'd like the
    combination of `-G"Visual Studio 15 2017"` with regards to its ability
    to find the C and C++ compiler on the system via registry/environment
    variables, and `-G"Ninja"` with regards to it being the build driver
    for that compiler.

    Is this even possible?
    -- 



-- 

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/20190522/dd3c3cab/attachment-0001.html>

From sz.richard at gmail.com  Wed May 22 14:33:05 2019
From: sz.richard at gmail.com (Richard Szabo)
Date: Wed, 22 May 2019 20:33:05 +0200
Subject: [CMake] transitive linkage of OBJECT library targets
In-Reply-To: <CAFzjYVqr-Rx3HjSVfY4AKXQUq2NDqYpd9x8We5+UK650nBvbGQ@mail.gmail.com>
References: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
 <CAFzjYVqr-Rx3HjSVfY4AKXQUq2NDqYpd9x8We5+UK650nBvbGQ@mail.gmail.com>
Message-ID: <CAFJ6FuEiNo6ZOAc_CTjLQ4rGb0Jf7jtUqrhDV5-+1fejzm8FBA@mail.gmail.com>

With Public it is still the same problem :(

cmake_minimum_required(VERSION 3.14)
project(test_object_lib_nesting)

set(CMAKE_CXX_STANDARD 14)

add_library(first_object_lib OBJECT first.cpp)

add_library(second_object_lib OBJECT second.cpp)

target_link_libraries(second_object_lib PUBLIC first_object_lib)

add_executable(test_object_lib_nesting main.cpp)

target_link_libraries(test_object_lib_nesting second_object_lib)


/cmake -E cmake_link_script
CMakeFiles/test_object_lib_nesting.dir/link.txt --verbose=1
/usr/bin/clang++-6.0  -g
CMakeFiles/test_object_lib_nesting.dir/main.cpp.o
CMakeFiles/second_object_lib.dir/second.cpp.o  -o
test_object_lib_nesting
CMakeFiles/second_object_lib.dir/second.cpp.o: In function
`Second::get_second()':
/home/csita/CLionProjects/test_object_lib_nesting/second.cpp:10:
undefined reference to `First::get_first() const'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I read the issue and it seems that there is no solution jet ....

Is there an easy / not so easy workaround ?
I have a dependency tree which can go down to 20 - 30 libs. (code
generator ) also diamond graph. :(.

Cheers
Richard

On Wed, 22 May 2019 at 14:25, Robert Maynard <robert.maynard at kitware.com> wrote:
>
> This is a known limitation of the current design. Only directly linked
> object library objects are propagated.
>
> For more details on why see: https://gitlab.kitware.com/cmake/cmake/issues/18090
>
> On Wed, May 22, 2019 at 1:48 AM Richard Szabo <sz.richard at gmail.com> wrote:
> >
> > Hi cmakers
> >
> > I'm trying to get the following example working:
> > ```
> > cmake_minimum_required(VERSION 3.14)
> > project(test_object_lib_nesting)
> >
> > set(CMAKE_CXX_STANDARD 14)
> >
> > add_library(first_object_lib OBJECT first.cpp)
> >
> > add_library(second_object_lib OBJECT second.cpp)
> >
> > target_link_libraries(second_object_lib first_object_lib)
> >
> > add_executable(test_object_lib_nesting main.cpp)
> >
> > target_link_libraries(test_object_lib_nesting second_object_lib)
> > ```
> >
> > The problem I have that the linker command line will have only the
> > second.cpp.o for linking the first.cpp.o will not be added as link
> > object to the exe. Causing missing symbols on exe linkage.
> >
> > How to transitively resolve and link "nested" Object library targets ?.
> > --
> >
> > 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 sz.richard at gmail.com  Wed May 22 14:58:20 2019
From: sz.richard at gmail.com (Richard Szabo)
Date: Wed, 22 May 2019 20:58:20 +0200
Subject: [CMake] transitive linkage of OBJECT library targets
In-Reply-To: <CAFJ6FuEiNo6ZOAc_CTjLQ4rGb0Jf7jtUqrhDV5-+1fejzm8FBA@mail.gmail.com>
References: <CAFJ6FuFw2vGYCLoh-mV6YUAf1hZrz-fUT8eMh9iHnrd1vZZRyA@mail.gmail.com>
 <CAFzjYVqr-Rx3HjSVfY4AKXQUq2NDqYpd9x8We5+UK650nBvbGQ@mail.gmail.com>
 <CAFJ6FuEiNo6ZOAc_CTjLQ4rGb0Jf7jtUqrhDV5-+1fejzm8FBA@mail.gmail.com>
Message-ID: <CAFJ6FuG4qKU+y0X_t84JmXp2p9htUg-X2YDw+9hKt34HA-AQtQ@mail.gmail.com>

The reason going to object libs instead of static libs is the
limitation of windows dynamic libraries that export simbols must be in
the liner command line object it can not be added to the static
libraries linked to the dlls.
with gcc this problem can be solved with

-Wl,--whole-archive
.... libs with export
-Wl,--no-whole-archive

but I did not find something similar to MSVC .... and have the problem
that I have have code generators between user code and core runtime
which generate c++ code in separate libs.

So my idea was to use object libs to solve the problem but now I face
the issue with the transitive linkage. :(.

Cheers
Richard





On Wed, 22 May 2019 at 20:33, Richard Szabo <sz.richard at gmail.com> wrote:
>
> With Public it is still the same problem :(
>
> cmake_minimum_required(VERSION 3.14)
> project(test_object_lib_nesting)
>
> set(CMAKE_CXX_STANDARD 14)
>
> add_library(first_object_lib OBJECT first.cpp)
>
> add_library(second_object_lib OBJECT second.cpp)
>
> target_link_libraries(second_object_lib PUBLIC first_object_lib)
>
> add_executable(test_object_lib_nesting main.cpp)
>
> target_link_libraries(test_object_lib_nesting second_object_lib)
>
>
> /cmake -E cmake_link_script
> CMakeFiles/test_object_lib_nesting.dir/link.txt --verbose=1
> /usr/bin/clang++-6.0  -g
> CMakeFiles/test_object_lib_nesting.dir/main.cpp.o
> CMakeFiles/second_object_lib.dir/second.cpp.o  -o
> test_object_lib_nesting
> CMakeFiles/second_object_lib.dir/second.cpp.o: In function
> `Second::get_second()':
> /home/csita/CLionProjects/test_object_lib_nesting/second.cpp:10:
> undefined reference to `First::get_first() const'
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> I read the issue and it seems that there is no solution jet ....
>
> Is there an easy / not so easy workaround ?
> I have a dependency tree which can go down to 20 - 30 libs. (code
> generator ) also diamond graph. :(.
>
> Cheers
> Richard
>
> On Wed, 22 May 2019 at 14:25, Robert Maynard <robert.maynard at kitware.com> wrote:
> >
> > This is a known limitation of the current design. Only directly linked
> > object library objects are propagated.
> >
> > For more details on why see: https://gitlab.kitware.com/cmake/cmake/issues/18090
> >
> > On Wed, May 22, 2019 at 1:48 AM Richard Szabo <sz.richard at gmail.com> wrote:
> > >
> > > Hi cmakers
> > >
> > > I'm trying to get the following example working:
> > > ```
> > > cmake_minimum_required(VERSION 3.14)
> > > project(test_object_lib_nesting)
> > >
> > > set(CMAKE_CXX_STANDARD 14)
> > >
> > > add_library(first_object_lib OBJECT first.cpp)
> > >
> > > add_library(second_object_lib OBJECT second.cpp)
> > >
> > > target_link_libraries(second_object_lib first_object_lib)
> > >
> > > add_executable(test_object_lib_nesting main.cpp)
> > >
> > > target_link_libraries(test_object_lib_nesting second_object_lib)
> > > ```
> > >
> > > The problem I have that the linker command line will have only the
> > > second.cpp.o for linking the first.cpp.o will not be added as link
> > > object to the exe. Causing missing symbols on exe linkage.
> > >
> > > How to transitively resolve and link "nested" Object library targets ?.
> > > --
> > >
> > > 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  Thu May 23 04:40:38 2019
From: workbench at gmx.at (Steven Truppe)
Date: Thu, 23 May 2019 10:40:38 +0200
Subject: [CMake] Troubles compiling llvm
Message-ID: <06d122b3-f734-6acf-dc06-5ecbf03bfaa5@gmx.at>

Hi everyone,

i'm trying to compile llvm with ExternalProject_Add and get the
following error:

-- Installing: /usr/lib/ocaml/llvm/llvm.mli
CMake Error at bindings/ocaml/llvm/cmake_install.cmake:49 (file):
 ? file INSTALL cannot copy file
"/home/stuv/linux-projects/programming/bsEdit/build_files/Release/llvm/src/external_llvm-build/bindings/ocaml/llvm/llvm.mli"
 ? to "/usr/lib/ocaml/llvm/llvm.mli".
Call Stack (most recent call first):
 ? bindings/ocaml/cmake_install.cmake:42 (include)
 ? cmake_install.cmake:64 (include)


Makefile:128: die Regel f?r Ziel ?install? scheiterte
make[3]: *** [install] Fehler 1
CMakeFiles/external_llvm.dir/build.make:73: die Regel f?r Ziel
?../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install?
scheiterte
make[2]: ***
[../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install]
Fehler 2
CMakeFiles/Makefile2:72: die Regel f?r Ziel
?CMakeFiles/external_llvm.dir/all? scheiterte
make[1]: *** [CMakeFiles/external_llvm.dir/all] Fehler 2
Makefile:83: die Regel f?r Ziel ?all? scheiterte
make: *** [all] Fehler 2

set(LLVM_EXTRA_ARGS
 ??? -DLLVM_USE_CRT_RELEASE=MT
 ??? -DLLVM_USE_CRT_DEBUG=MTd
 ??? -DLLVM_INCLUDE_TESTS=OFF
 ??? -DLLVM_TARGETS_TO_BUILD=X86
 ??? -DLLVM_INCLUDE_EXAMPLES=OFF
 ??? -DLLVM_ENABLE_TERMINFO=OFF
 ??? -DLLVM_BUILD_EXAMPLES=ON
)

set(LLVM_GENERATOR "Unix Makefiles")


ExternalProject_Add(external_llvm
 ??? URL ${LLVM_URL}
 ??? DOWNLOAD_DIR download/llvm
 ??? URL_HASH MD5=${LLVM_HASH}
 ??? CMAKE_GENERATOR ${LLVM_GENERATOR}
 ??? PREFIX ${OUTPUT_PATH}/llvm
 ??? CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/llvm
${DEFAULT_CMAKE_FLAGS} ${LLVM_EXTRA_ARGS}
 ??? INSTALL_DIR ${OUTPUT_PATH}/llvm
)

I followed the instructions from llvm.org but i still get this error
during installation (the build process works fine but during install i
get this error).


best regards!


From doenges at mvtec.com  Thu May 23 05:28:39 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Thu, 23 May 2019 11:28:39 +0200
Subject: [CMake] Troubles compiling llvm
In-Reply-To: <06d122b3-f734-6acf-dc06-5ecbf03bfaa5@gmx.at>
References: <06d122b3-f734-6acf-dc06-5ecbf03bfaa5@gmx.at>
Message-ID: <179ad972-3802-c464-33a6-62ab029531a8@mvtec.com>

Hi Steven,

I would assume the problem is that you do not have write permissions for 
/usr/lib. You either need to give yourself the appropriate rights, our 
run the build as root (which is probably a very bad idea). If you don't 
want to actually install to /usr/lib, you can pass a different 
CMAKE_INSTALL_PREFIX to the build via ExternalProject_Add's CMAKE_ARGS 
argument, i.e. something like

ExternalProject_Add(xxx
 ? ...
 ? CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<where to install LLVM to>
 ? ...


Am 23.05.19 um 10:40 schrieb Steven Truppe:
> Hi everyone,
>
> i'm trying to compile llvm with ExternalProject_Add and get the
> following error:
>
> -- Installing: /usr/lib/ocaml/llvm/llvm.mli
> CMake Error at bindings/ocaml/llvm/cmake_install.cmake:49 (file):
> ? file INSTALL cannot copy file
> "/home/stuv/linux-projects/programming/bsEdit/build_files/Release/llvm/src/external_llvm-build/bindings/ocaml/llvm/llvm.mli" 
>
> ? to "/usr/lib/ocaml/llvm/llvm.mli".
> Call Stack (most recent call first):
> ? bindings/ocaml/cmake_install.cmake:42 (include)
> ? cmake_install.cmake:64 (include)
>
>
> Makefile:128: die Regel f?r Ziel ?install? scheiterte
> make[3]: *** [install] Fehler 1
> CMakeFiles/external_llvm.dir/build.make:73: die Regel f?r Ziel
> ?../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install? 
>
> scheiterte
> make[2]: ***
> [../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install] 
>
> Fehler 2
> CMakeFiles/Makefile2:72: die Regel f?r Ziel
> ?CMakeFiles/external_llvm.dir/all? scheiterte
> make[1]: *** [CMakeFiles/external_llvm.dir/all] Fehler 2
> Makefile:83: die Regel f?r Ziel ?all? scheiterte
> make: *** [all] Fehler 2
>
> set(LLVM_EXTRA_ARGS
> ??? -DLLVM_USE_CRT_RELEASE=MT
> ??? -DLLVM_USE_CRT_DEBUG=MTd
> ??? -DLLVM_INCLUDE_TESTS=OFF
> ??? -DLLVM_TARGETS_TO_BUILD=X86
> ??? -DLLVM_INCLUDE_EXAMPLES=OFF
> ??? -DLLVM_ENABLE_TERMINFO=OFF
> ??? -DLLVM_BUILD_EXAMPLES=ON
> )
>
> set(LLVM_GENERATOR "Unix Makefiles")
>
>
> ExternalProject_Add(external_llvm
> ??? URL ${LLVM_URL}
> ??? DOWNLOAD_DIR download/llvm
> ??? URL_HASH MD5=${LLVM_HASH}
> ??? CMAKE_GENERATOR ${LLVM_GENERATOR}
> ??? PREFIX ${OUTPUT_PATH}/llvm
> ??? CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/llvm
> ${DEFAULT_CMAKE_FLAGS} ${LLVM_EXTRA_ARGS}
> ??? INSTALL_DIR ${OUTPUT_PATH}/llvm
> )
>
> I followed the instructions from llvm.org but i still get this error
> during installation (the build process works fine but during install i
> get this error).
>
>
> 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/20190523/a1af25d2/attachment-0001.html>

From AlbrechtS.fltk at online.de  Thu May 23 05:37:44 2019
From: AlbrechtS.fltk at online.de (Albrecht Schlosser)
Date: Thu, 23 May 2019 11:37:44 +0200
Subject: [CMake] Troubles compiling llvm
In-Reply-To: <06d122b3-f734-6acf-dc06-5ecbf03bfaa5@gmx.at>
References: <06d122b3-f734-6acf-dc06-5ecbf03bfaa5@gmx.at>
Message-ID: <010c9efb-4703-c5f3-3923-bb9aaa758797@online.de>

Am 23.05.2019 10:40 schrieb Steven Truppe:

> i'm trying to compile llvm with ExternalProject_Add and get the
> following error:
> 
> -- Installing: /usr/lib/ocaml/llvm/llvm.mli
> CMake Error at bindings/ocaml/llvm/cmake_install.cmake:49 (file):
>  ? file INSTALL cannot copy file
> "/home/stuv/linux-projects/programming/bsEdit/build_files/Release/llvm/src/external_llvm-build/bindings/ocaml/llvm/llvm.mli" 
> 
>  ? to "/usr/lib/ocaml/llvm/llvm.mli".
> Call Stack (most recent call first):
>  ? bindings/ocaml/cmake_install.cmake:42 (include)
>  ? cmake_install.cmake:64 (include)

This sounds like you need access rights, you probably need to use:

$ sudo make install

(unless the file doesn't exist, but I assume this would be another error 
message)


From doenges at mvtec.com  Thu May 23 06:37:17 2019
From: doenges at mvtec.com (Eric Doenges)
Date: Thu, 23 May 2019 12:37:17 +0200
Subject: [CMake] Troubles compiling llvm
In-Reply-To: <179ad972-3802-c464-33a6-62ab029531a8@mvtec.com>
References: <06d122b3-f734-6acf-dc06-5ecbf03bfaa5@gmx.at>
 <179ad972-3802-c464-33a6-62ab029531a8@mvtec.com>
Message-ID: <fae9442b-dca2-49cd-2ac0-36c0546da53d@mvtec.com>

To answer myself:

I just saw that you already set CMAKE_INSTALL_PREFIX, so ignore that 
part of my answer. Unfortunately, as far as I am aware it is not 
possible to split building with ExternalProject_Add into separate build 
and install steps, so your options essentially boil down to:

1) Give yourself write permissions for ${OUTPUT_PATH} and run the build. 
You should then probably remove write access for ${OUTPUT_PATH} again 
once you are done.

2) Run the entire build as root.

Since you should be doing as little as possible as root, I would 
strongly suggest option 1.

Am 23.05.19 um 11:28 schrieb Eric Doenges:
>
> Hi Steven,
>
> I would assume the problem is that you do not have write permissions 
> for /usr/lib. You either need to give yourself the appropriate rights, 
> our run the build as root (which is probably a very bad idea). If you 
> don't want to actually install to /usr/lib, you can pass a different 
> CMAKE_INSTALL_PREFIX to the build via ExternalProject_Add's CMAKE_ARGS 
> argument, i.e. something like
>
> ExternalProject_Add(xxx
> ? ...
> ? CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<where to install LLVM to>
> ? ...
>
>
> Am 23.05.19 um 10:40 schrieb Steven Truppe:
>> Hi everyone,
>>
>> i'm trying to compile llvm with ExternalProject_Add and get the
>> following error:
>>
>> -- Installing: /usr/lib/ocaml/llvm/llvm.mli
>> CMake Error at bindings/ocaml/llvm/cmake_install.cmake:49 (file):
>> ? file INSTALL cannot copy file
>> "/home/stuv/linux-projects/programming/bsEdit/build_files/Release/llvm/src/external_llvm-build/bindings/ocaml/llvm/llvm.mli" 
>>
>> ? to "/usr/lib/ocaml/llvm/llvm.mli".
>> Call Stack (most recent call first):
>> ? bindings/ocaml/cmake_install.cmake:42 (include)
>> ? cmake_install.cmake:64 (include)
>>
>>
>> Makefile:128: die Regel f?r Ziel ?install? scheiterte
>> make[3]: *** [install] Fehler 1
>> CMakeFiles/external_llvm.dir/build.make:73: die Regel f?r Ziel
>> ?../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install? 
>>
>> scheiterte
>> make[2]: ***
>> [../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install] 
>>
>> Fehler 2
>> CMakeFiles/Makefile2:72: die Regel f?r Ziel
>> ?CMakeFiles/external_llvm.dir/all? scheiterte
>> make[1]: *** [CMakeFiles/external_llvm.dir/all] Fehler 2
>> Makefile:83: die Regel f?r Ziel ?all? scheiterte
>> make: *** [all] Fehler 2
>>
>> set(LLVM_EXTRA_ARGS
>> ??? -DLLVM_USE_CRT_RELEASE=MT
>> ??? -DLLVM_USE_CRT_DEBUG=MTd
>> ??? -DLLVM_INCLUDE_TESTS=OFF
>> ??? -DLLVM_TARGETS_TO_BUILD=X86
>> ??? -DLLVM_INCLUDE_EXAMPLES=OFF
>> ??? -DLLVM_ENABLE_TERMINFO=OFF
>> ??? -DLLVM_BUILD_EXAMPLES=ON
>> )
>>
>> set(LLVM_GENERATOR "Unix Makefiles")
>>
>>
>> ExternalProject_Add(external_llvm
>> ??? URL ${LLVM_URL}
>> ??? DOWNLOAD_DIR download/llvm
>> ??? URL_HASH MD5=${LLVM_HASH}
>> ??? CMAKE_GENERATOR ${LLVM_GENERATOR}
>> ??? PREFIX ${OUTPUT_PATH}/llvm
>> ??? CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/llvm
>> ${DEFAULT_CMAKE_FLAGS} ${LLVM_EXTRA_ARGS}
>> ??? INSTALL_DIR ${OUTPUT_PATH}/llvm
>> )
>>
>> I followed the instructions from llvm.org but i still get this error
>> during installation (the build process works fine but during install i
>> get this error).
>>
>>
>> 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
>
-- 

*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/20190523/7c7ad68a/attachment.html>

From haiomaio2 at mailbox.org  Thu May 23 07:52:42 2019
From: haiomaio2 at mailbox.org (Haio Maio)
Date: Thu, 23 May 2019 13:52:42 +0200 (CEST)
Subject: [CMake] cmake + ccache -> cross-compile -> toolchain wrapper
Message-ID: <763100569.75526.1558612363083@office.mailbox.org>

How do you use cmake + ccache to cross compile in combination with a toolchain compiler wrapper (from crosstool-NG)?

The situation:
cross-compile for arm with a sdk + cmake + ccache

The sdk installation

$ sdk-dat-arm$ ll host/usr/bin/
arm-am3354-linux-gnueabihf-c++ -> ext-toolchain-wrapper*
arm-am3354-linux-gnueabihf-cc -> ext-toolchain-wrapper*
arm-am3354-linux-gnueabihf-cpp -> ext-toolchain-wrapper*
arm-am3354-linux-gnueabihf-g++ -> ext-toolchain-wrapper*
arm-am3354-linux-gnueabihf-gcc -> ext-toolchain-wrapper*
arm-am3354-linux-gnueabihf-gcc-4.9.4 -> ext-toolchain-wrapper*


ccache configuration

/usr/local/bin$ ls -al
arm-am3354-linux-gnueabihf-g++ -> ccache
arm-am3354-linux-gnueabihf-gcc -> ccache
cc -> ccache
ccache
g++ -> ccache
gcc -> ccache

/usr/local/bin/arm-am3354-linux-gnueabihf-gcc --version
arm-am3354-linux-gnueabihf-gcc (crosstool-NG ) 4.9.4 20150629 (prerelease)

cmake configuration

set(CMAKE_C_COMPILER_LAUNCHER ccache)
set(CMAKE_C_COMPILER arm-am3354-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER_LAUNCHER ccache)
set(CMAKE_CXX_COMPILER arm-am3354-linux-gnueabihf-g++)

Executing cmake

$ cmake ....
-- Check for working C compiler: /usr/local/bin/arm-am3354-linux-gnueabihf-gcc
-- Check for working C compiler: /usr/local/bin/arm-am3354-linux-gnueabihf-gcc -- works -- Check for working CXX compiler: /usr/local/bin/arm-am3354-linux-gnueabihf-g++
-- Check for working CXX compiler: /usr/local/bin/arm-am3354-linux-gnueabihf-g++ -- works

Compiling with the above cmake configuration fails ...

-- The CXX compiler identification is GNU 4.9.4
-- Check for working C compiler: /usr/local/bin/arm-am3354-linux-gnueabihf-gcc
-- Check for working CXX compiler: /usr/local/bin/arm-am3354-linux-gnueabihf-g++ -- Check for working CXX compiler: /usr/local/bin/arm-am3354-linux-gnueabihf-g++ -- works
In file included from ... fatal error: libudev.h: No such file or directory compilation terminated.

without the LAUNCHER it compiles successively.

The libudev.h is defined for inclusion in
path/CXX.includecache:libudev.h


Any idea of whats the reason for the compilation failure, i.e. why with the LAUNCHER it wont find the include?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190523/94ca2c54/attachment.html>

From robert.maynard at kitware.com  Thu May 23 16:14:59 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 23 May 2019 16:14:59 -0400
Subject: [CMake] Specifying VS 2019 LLVM toolset on CMake command line?
In-Reply-To: <SG2PR06MB315812D2B89E8BADABB27DAED3050@SG2PR06MB3158.apcprd06.prod.outlook.com>
References: <SG2PR06MB315812D2B89E8BADABB27DAED3050@SG2PR06MB3158.apcprd06.prod.outlook.com>
Message-ID: <CAFzjYVoSNxDNRZWD7pEQerG4piEDyzFhp+tEumR5qmPi7jbhwg@mail.gmail.com>

I believe it is "-T llvm" when using the Visual Studio Generators


On Sun, May 19, 2019 at 3:33 PM Osman Zakir <osmanzakir90 at hotmail.com> wrote:
>
> How do I specify the VS 2019 LLVM toolset when configuring a build with CMake on the command line?
> --
>
> 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 zehner.paul at jaxa.jp  Fri May 24 05:48:39 2019
From: zehner.paul at jaxa.jp (=?iso-2022-jp?B?WmVobmVyGyRCISEbKEJQYXVs?=)
Date: Fri, 24 May 2019 09:48:39 +0000
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <TY1PR01MB1883067FEF7951468A372305F4080@TY1PR01MB1883.jpnprd01.prod.outlook.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
 <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>
 <TY1PR01MB1883FA83D31C6111C15E1016F4330@TY1PR01MB1883.jpnprd01.prod.outlook.com>,
 <CAFzjYVoNhiBP=WK+5OR_=KoQB0f0QoHE8Owz6WpspyvYt6Mqiw@mail.gmail.com>,
 <TY1PR01MB1883067FEF7951468A372305F4080@TY1PR01MB1883.jpnprd01.prod.outlook.com>
Message-ID: <TY1PR01MB188388875258DE7E27203A43F4020@TY1PR01MB1883.jpnprd01.prod.outlook.com>

Hello all,

So, I managed to configure my `Fujitsu-CXX.cmake` file to use the Fujitsu C++ compiler with MPI as well. The problem of not detecting headers of the STL (like `array`) was due to the fact the C++ standard flag was not set correctly.

I am facing another problem though: the linker needs the C++ standard flag to be set, which is not something GCC needs. I could not find a way to make `CMAKE_CXX**_STANDARD_COMPILE_OPTION` applied to the linker as well. What I am missing?

Best regards,


--

Paul Zehner, Ph. D.

Invited Researcher

Numerical Simulation Research Unit

Japan Aerospace Exploration Agency

7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo

182-8522, Japan

Tel. +81-50-3362-7933

Fax. +81-422-40-3327

zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp>

www.jaxa.jp<http://www.jaxa.jp>

________________________________
From: CMake <cmake-bounces at cmake.org> on behalf of Zehner?Paul <zehner.paul at jaxa.jp>
Sent: Tuesday, May 14, 2019 11:58
To: Robert Maynard
Cc: cmake at cmake.org
Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler

Robert,

so that all users could benefit from the improved compiler detection :)
That is my plan! If I can make a compiler module which works well enough, I will submit it as a merge request.

Regarding the detection of MPI with FindMPI, I failed to detect the MPI compiler using `MPI_CXX_COMPILER_FLAGS`. But using the normal Fujitsu compiler binary (not the wrapper) and setting `MPI_CXX_COMPILER`, I can detect it.

The problem is now that it does not detect the STL anymore at compiling time: "error: namespace "std" has no member "array"" (note that I used to build the project with a hand made Makefile, so the source code is valid). I checked the `include` directory of the compiler and it contains the Array header, though. In other warnings, I clearly see that this `include` directory is used. What is wrong here?

Best regards,


--

Paul Zehner, Ph. D.

Invited Researcher

Numerical Simulation Research Unit

Japan Aerospace Exploration Agency

7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo

182-8522, Japan

Tel. +81-50-3362-7933

Fax. +81-422-40-3327

zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp>

www.jaxa.jp<http://www.jaxa.jp>

________________________________
From: Robert Maynard <robert.maynard at kitware.com>
Sent: Thursday, May 9, 2019 23:29
To: Zehner?Paul
Cc: Kai Wolf; cmake at cmake.org
Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler

The goal would be to upstream the compiler changes to cmake so that
all users could benefit from the improved compiler detection :)

I would look at the FindMPI docs on locating the correct mpi compiler:
https://cmake.org/cmake/help/v3.14/module/FindMPI.html#variables-for-locating-mpi
. It looks like what you will need to specify is
MPI_<lang>_COMPILER_FLAGS

On Wed, May 8, 2019 at 10:15 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
>
> Thank you for your answer.
>
> This means I have to override `/usr/share/cmake/Modules/Compiler/Fujitsu-DetermineCompiler.cmake`? This is not unfeasible, but it may seems tricky to my users. Since detecting compiler version is not a crucial task, maybe I will keep this file as it and concentrate on other ones.
>
> Another question I have is regarding MPI. The `find_package(MPI REQUIRED)` directive fails with "Could NOT find MPI (missing: MPI_CXX_FOUND)". I have no clue on how to help the detection of MPI. The compiler I give to CMake is actually an MPI wrapper that only needs one argument to enable MPI features. I tried with some exotic-named GCC compilers at my lab (which are MPI wrappers as well) and it could detect MPI with no problem. Where should I start?
>
> Best regards,
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp<http://www.jaxa.jp>
>
> ________________________________
> From: Robert Maynard <robert.maynard at kitware.com>
> Sent: Thursday, May 9, 2019 3:12
> To: Zehner?Paul
> Cc: Kai Wolf; cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> I believe the only way is to have your version of
> Fujitsu-DetermineCompiler.cmake be installed over the one provided by
> CMake. When it comes to known compilers CMake explicitly includes the
> version it ships.
>
> On Tue, May 7, 2019 at 11:01 PM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> >
> > Robert,
> >
> > Thank you for the advice.
> >
> > As I want to take account of compiler version, I overrided the `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in the folder of `CMAKE_MODULE_PATH`. However, the installation `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should I do?
> >
> > Best regards,
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.paul at jaxa.jp
> >
> > www.jaxa.jp<http://www.jaxa.jp>
> >
> > ________________________________
> > From: Robert Maynard <robert.maynard at kitware.com>
> > Sent: Friday, April 26, 2019 23:32
> > To: Zehner?Paul
> > Cc: Kai Wolf; cmake at cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > For an initial implementation I would base the work on the PGI
> > compiler module (
> > https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> > ) not the GNU-CXX module.
> > This will allow you to add a new compiler with only meta-language
> > flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> > having to manually build the feature tables.
> >
> > On Fri, Apr 26, 2019 at 3:58 AM Zehner?Paul <zehner.paul at jaxa.jp> wrote:
> > >
> > > Kai,
> > >
> > >
> > > Thanks for your answer and for your presentation. So, I will try to add support for this Fujitsu compiler. Is there a list of the common compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a source of inspiration.
> > >
> > >
> > > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will propose it as a merge request.
> > >
> > >
> > > --
> > >
> > > Paul Zehner, Ph. D.
> > >
> > > Invited Researcher
> > >
> > > Numerical Simulation Research Unit
> > >
> > > Japan Aerospace Exploration Agency
> > >
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > >
> > > 182-8522, Japan
> > >
> > > Tel. +81-50-3362-7933
> > >
> > > Fax. +81-422-40-3327
> > >
> > > zehner.paul at jaxa.jp
> > >
> > > www.jaxa.jp<http://www.jaxa.jp>
> > >
> > >
> > >
> > > ________________________________
> > > From: Kai Wolf <kai.wolf at gmail.com>
> > > Sent: Friday, April 26, 2019 16:22
> > > To: Zehner?Paul
> > > Cc: cmake at cmake.org
> > > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> > >
> > > If you want to add support to your specific compiler, you could add or extend another Fujitsu-DetermineCompiler.cmake
> > > file and append your CMAKE_MODULE_PATH in order to CMake to find it. You probably also need to adjust
> > > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> > >
> > > I gave a talk a few years ago that shortly explains the whole process of CMake initialization and compiler verification which
> > > you can find here: https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> > >
> > >
> > > Greetings,
> > >
> > > Kai
> > >
> > > http://kai-wolf.me
> > > http://effective-cmake.com
> > >
> > > Am 26.04.2019 um 07:35 schrieb Zehner?Paul <zehner.paul at jaxa.jp>:
> > >
> > > Hello Cmake community,
> > >
> > > I would like to use Cmake to build research simulation programs in a Fujitsu supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) does not support any compile feature for the Fujitsu C++ compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new to Cmake. Searching for similar issues, I found only this [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html), which talk about basic support of the compiler.
> > >
> > > I tested it on a simple project, and the line:
> > >
> > > ```cmake
> > > target_compile_features(test PUBLIC cxx_std_11)
> > > ```
> > >
> > > fails with this message:
> > >
> > > ```
> > > CMake Error at CMakeLists.txt:15 (target_compile_features):
> > >   target_compile_features no known features for CXX compiler
> > >
> > >   "Fujitsu"
> > >
> > >   version .
> > >
> > > ```
> > >
> > > So, it seems that the compiler is detected (without its version), but compile features are not known. To be sure, I ran this simple test to list any supported features:
> > >
> > > ```cmake
> > > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > > project(foobar CXX)
> > > message("Your C++ compiler supports these C++ features:")
> > > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> > >     message("${i}")
> > > endforeach()
> > > ```
> > >
> > > and no feature are listed.
> > >
> > > So, what should I do from now on? Are there some people here using Cmake with Fujitsu who could help me? Should I propose a patch with the different compile features of the compiler? Or should I address it to Fujitsu?
> > >
> > > Thanks for your help,
> > >
> > > --
> > > Paul Zehner, Ph. D.
> > > Invited Researcher
> > > Numerical Simulation Research Unit
> > > Japan Aerospace Exploration Agency
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > > 182-8522, Japan
> > > Tel. +81-50-3362-7933
> > > Fax. +81-422-40-3327
> > > zehner.paul at jaxa.jp
> > > www.jaxa.jp<http://www.jaxa.jp>
> > > --
> > >
> > > 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
> > >
> > >
> > > --
> > >
> > > 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/20190524/658cb545/attachment-0001.html>

From patrick.griffiths at gmail.com  Fri May 24 08:09:28 2019
From: patrick.griffiths at gmail.com (Patrick Griffiths)
Date: Fri, 24 May 2019 06:09:28 -0600
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <TY1PR01MB188388875258DE7E27203A43F4020@TY1PR01MB1883.jpnprd01.prod.outlook.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
 <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>
 <TY1PR01MB1883FA83D31C6111C15E1016F4330@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <CAFzjYVoNhiBP=WK+5OR_=KoQB0f0QoHE8Owz6WpspyvYt6Mqiw@mail.gmail.com>
 <TY1PR01MB1883067FEF7951468A372305F4080@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <TY1PR01MB188388875258DE7E27203A43F4020@TY1PR01MB1883.jpnprd01.prod.outlook.com>
Message-ID: <CANqUTaQD+13h1aoWwPYZrm_ZjyKP9w1FmS-L4=QwqBxsHY1BkQ@mail.gmail.com>

A naive grep tells me the IAR compiler detection sets CMAKE_CXX_LINK_FLAGS
in its compiler detection. Maybe that'd work for you?


On Fri, May 24, 2019 at 3:48 AM Zehner Paul <zehner.paul at jaxa.jp> wrote:

> Hello all,
>
> So, I managed to configure my `Fujitsu-CXX.cmake` file to use the Fujitsu
> C++ compiler with MPI as well. The problem of not detecting headers of the
> STL (like `array`) was due to the fact the C++ standard flag was not set
> correctly.
>
> I am facing another problem though: the linker needs the C++ standard flag
> to be set, which is not something GCC needs. I could not find a way to make
> `CMAKE_CXX**_STANDARD_COMPILE_OPTION` applied to the linker as well. What I
> am missing?
>
> Best regards,
>
> --
>
> *Paul Zehner, Ph. D.*
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> *Japan Aerospace Exploration Agency*
>
> *7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo*
>
> *182-8522, Japan*
>
> *Tel. +81-50-3362-7933*
>
> *Fax. +81-422-40-3327*
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp
> ------------------------------
> *From:* CMake <cmake-bounces at cmake.org> on behalf of Zehner Paul <
> zehner.paul at jaxa.jp>
> *Sent:* Tuesday, May 14, 2019 11:58
> *To:* Robert Maynard
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Support of compile features for Fujitsu C++
> Compiler
>
> Robert,
>
> so that all users could benefit from the improved compiler detection :)
> That is my plan! If I can make a compiler module which works well enough,
> I will submit it as a merge request.
>
> Regarding the detection of MPI with FindMPI, I failed to detect the MPI
> compiler using `MPI_CXX_COMPILER_FLAGS`. But using the normal Fujitsu
> compiler binary (not the wrapper) and setting `MPI_CXX_COMPILER`, I can
> detect it.
>
> The problem is now that it does not detect the STL anymore at compiling
> time: "error: namespace "std" has no member "array"" (note that I used to
> build the project with a hand made Makefile, so the source code is valid).
> I checked the `include` directory of the compiler and it contains the Array
> header, though. In other warnings, I clearly see that this `include`
> directory is used. What is wrong here?
>
> Best regards,
>
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp <zehner.paul at jaxa.jp>>
>
> www.jaxa.jp<http://www.jaxa.jp>
>
> ________________________________
> From: Robert Maynard <robert.maynard at kitware.com>
> Sent: Thursday, May 9, 2019 23:29
> To: Zehner Paul
> Cc: Kai Wolf; cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> The goal would be to upstream the compiler changes to cmake so that
> all users could benefit from the improved compiler detection :)
>
> I would look at the FindMPI docs on locating the correct mpi compiler:
>
> https://cmake.org/cmake/help/v3.14/module/FindMPI.html#variables-for-locating-mpi
> . It looks like what you will need to specify is
> MPI_<lang>_COMPILER_FLAGS
>
> On Wed, May 8, 2019 at 10:15 PM Zehner Paul <zehner.paul at jaxa.jp> wrote:
> >
> > Thank you for your answer.
> >
> > This means I have to override
> `/usr/share/cmake/Modules/Compiler/Fujitsu-DetermineCompiler.cmake`? This
> is not unfeasible, but it may seems tricky to my users. Since detecting
> compiler version is not a crucial task, maybe I will keep this file as it
> and concentrate on other ones.
> >
> > Another question I have is regarding MPI. The `find_package(MPI
> REQUIRED)` directive fails with "Could NOT find MPI (missing:
> MPI_CXX_FOUND)". I have no clue on how to help the detection of MPI. The
> compiler I give to CMake is actually an MPI wrapper that only needs one
> argument to enable MPI features. I tried with some exotic-named GCC
> compilers at my lab (which are MPI wrappers as well) and it could detect
> MPI with no problem. Where should I start?
> >
> > Best regards,
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.paul at jaxa.jp
> >
> > www.jaxa.jp<http://www.jaxa.jp>
> >
> > ________________________________
> > From: Robert Maynard <robert.maynard at kitware.com>
> > Sent: Thursday, May 9, 2019 3:12
> > To: Zehner Paul
> > Cc: Kai Wolf; cmake at cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > I believe the only way is to have your version of
> > Fujitsu-DetermineCompiler.cmake be installed over the one provided by
> > CMake. When it comes to known compilers CMake explicitly includes the
> > version it ships.
> >
> > On Tue, May 7, 2019 at 11:01 PM Zehner Paul <zehner.paul at jaxa.jp> wrote:
> > >
> > > Robert,
> > >
> > > Thank you for the advice.
> > >
> > > As I want to take account of compiler version, I overrided the
> `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in
> the folder of `CMAKE_MODULE_PATH`. However, the installation
> `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should
> I do?
> > >
> > > Best regards,
> > >
> > > --
> > >
> > > Paul Zehner, Ph. D.
> > >
> > > Invited Researcher
> > >
> > > Numerical Simulation Research Unit
> > >
> > > Japan Aerospace Exploration Agency
> > >
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > >
> > > 182-8522, Japan
> > >
> > > Tel. +81-50-3362-7933
> > >
> > > Fax. +81-422-40-3327
> > >
> > > zehner.paul at jaxa.jp
> > >
> > > www.jaxa.jp<http://www.jaxa.jp>
> > >
> > > ________________________________
> > > From: Robert Maynard <robert.maynard at kitware.com>
> > > Sent: Friday, April 26, 2019 23:32
> > > To: Zehner Paul
> > > Cc: Kai Wolf; cmake at cmake.org
> > > Subject: Re: [CMake] Support of compile features for Fujitsu C++
> Compiler
> > >
> > > For an initial implementation I would base the work on the PGI
> > > compiler module (
> > >
> https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> > > ) not the GNU-CXX module.
> > > This will allow you to add a new compiler with only meta-language
> > > flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> > > having to manually build the feature tables.
> > >
> > > On Fri, Apr 26, 2019 at 3:58 AM Zehner Paul <zehner.paul at jaxa.jp>
> wrote:
> > > >
> > > > Kai,
> > > >
> > > >
> > > > Thanks for your answer and for your presentation. So, I will try to
> add support for this Fujitsu compiler. Is there a list of the common
> compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a
> source of inspiration.
> > > >
> > > >
> > > > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will
> propose it as a merge request.
> > > >
> > > >
> > > > --
> > > >
> > > > Paul Zehner, Ph. D.
> > > >
> > > > Invited Researcher
> > > >
> > > > Numerical Simulation Research Unit
> > > >
> > > > Japan Aerospace Exploration Agency
> > > >
> > > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > > >
> > > > 182-8522, Japan
> > > >
> > > > Tel. +81-50-3362-7933
> > > >
> > > > Fax. +81-422-40-3327
> > > >
> > > > zehner.paul at jaxa.jp
> > > >
> > > > www.jaxa.jp<http://www.jaxa.jp>
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: Kai Wolf <kai.wolf at gmail.com>
> > > > Sent: Friday, April 26, 2019 16:22
> > > > To: Zehner Paul
> > > > Cc: cmake at cmake.org
> > > > Subject: Re: [CMake] Support of compile features for Fujitsu C++
> Compiler
> > > >
> > > > If you want to add support to your specific compiler, you could add
> or extend another Fujitsu-DetermineCompiler.cmake
> > > > file and append your CMAKE_MODULE_PATH in order to CMake to find it.
> You probably also need to adjust
> > > > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> > > >
> > > > I gave a talk a few years ago that shortly explains the whole
> process of CMake initialization and compiler verification which
> > > > you can find here:
> https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> > > >
> > > >
> > > > Greetings,
> > > >
> > > > Kai
> > > >
> > > > http://kai-wolf.me
> > > > http://effective-cmake.com
> > > >
> > > > Am 26.04.2019 um 07:35 schrieb Zehner Paul <zehner.paul at jaxa.jp>:
> > > >
> > > > Hello Cmake community,
> > > >
> > > > I would like to use Cmake to build research simulation programs in a
> Fujitsu supercomputer environment. Unfortunately, it seems that Cmake
> (version 3.14) does not support any compile feature for the Fujitsu C++
> compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I
> add I am pretty new to Cmake. Searching for similar issues, I found only
> this [thread](
> https://cmake.org/pipermail/cmake-developers/2014-August/010989.html),
> which talk about basic support of the compiler.
> > > >
> > > > I tested it on a simple project, and the line:
> > > >
> > > > ```cmake
> > > > target_compile_features(test PUBLIC cxx_std_11)
> > > > ```
> > > >
> > > > fails with this message:
> > > >
> > > > ```
> > > > CMake Error at CMakeLists.txt:15 (target_compile_features):
> > > >   target_compile_features no known features for CXX compiler
> > > >
> > > >   "Fujitsu"
> > > >
> > > >   version .
> > > >
> > > > ```
> > > >
> > > > So, it seems that the compiler is detected (without its version),
> but compile features are not known. To be sure, I ran this simple test to
> list any supported features:
> > > >
> > > > ```cmake
> > > > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > > > project(foobar CXX)
> > > > message("Your C++ compiler supports these C++ features:")
> > > > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> > > >     message("${i}")
> > > > endforeach()
> > > > ```
> > > >
> > > > and no feature are listed.
> > > >
> > > > So, what should I do from now on? Are there some people here using
> Cmake with Fujitsu who could help me? Should I propose a patch with the
> different compile features of the compiler? Or should I address it to
> Fujitsu?
> > > >
> > > > Thanks for your help,
> > > >
> > > > --
> > > > Paul Zehner, Ph. D.
> > > > Invited Researcher
> > > > Numerical Simulation Research Unit
> > > > Japan Aerospace Exploration Agency
> > > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > > > 182-8522, Japan
> > > > Tel. +81-50-3362-7933
> > > > Fax. +81-422-40-3327
> > > > zehner.paul at jaxa.jp
> > > > www.jaxa.jp<http://www.jaxa.jp>
> > > > --
> > > >
> > > > 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
> > > >
> > > >
> > > > --
> > > >
> > > > 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
> --
>
> 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/20190524/a37a3ace/attachment-0001.html>

From haiomaio2 at mailbox.org  Fri May 24 13:38:56 2019
From: haiomaio2 at mailbox.org (Haio Maio)
Date: Fri, 24 May 2019 19:38:56 +0200 (CEST)
Subject: [CMake] Manually-specified variables were not used by the project
Message-ID: <171703559.10607.1558719536682@office.mailbox.org>

Manually-specified variables were not used by the project
MY_VAR

when I call 

cmake -DMY_VAR= ...


The goal is
if(NOT DEFINED MY_VAR)
...
else()
...
if()

in order to tell cmake over the command line what to do.

How to achieve this ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190524/51405457/attachment.html>

From bill at classdesign.com  Fri May 24 13:55:01 2019
From: bill at classdesign.com (Bill Somerville)
Date: Fri, 24 May 2019 18:55:01 +0100
Subject: [CMake] Dependency cycle - why?
In-Reply-To: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>
References: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>
Message-ID: <b3dcde8d-8b8d-6bb5-774e-c9685c899fd6@classdesign.com>

On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file (MAKE_DIRECTORY ${GOPATH})
>
> set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
> set (build_command ${GO} build)
> set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
> add_custom_command (OUTPUT ${output}
>    COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} ${sources}
>    DEPENDS ${sources}
>    VERBATIM)
> add_custom_target (callback_generator_target DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${output})
> add_executable (callback_generator IMPORTED)
> set_target_properties (callback_generator
>    PROPERTIES
>    IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
>    )
> add_dependencies (callback_generator callback_generator_target)
>
> add_custom_target (server ALL DEPENDS callback_generator)
>
> which gives this error:
>
> >cmake --version
> cmake --version
> cmake version 3.14.3
>
> >cmake -G "MinGW Makefiles" ..\..
> cmake -G "MinGW Makefiles" ..\..
> -- Configuring done
> CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
>    "callback_generator_target" of type UTILITY
>      depends on "callback_generator_target" (strong)
> The component contains at least one cycle consisting of strong dependencies (created by add_dependencies) that cannot be broken.
>
> The set_target_properties () call seems to be part of the problem but 
> I don't understand why.
>
> Regards
> Bill Somerville.
>
Hi again,

answering my own post since no one has replied. Clearly my question was 
too specific. Let me try again with a more general question. I have 
tools that can generate executables (programs, static libraries, and 
shared libraries, including DLL import libraries on MS Windows). These 
tools are not directly supported by CMake but they are both needed 
within a project that uses them and installs them as the project 
artefacts. How do I integrate, for example a shared library, into a 
CMake project as if it were produced by a supported toolchain like C or 
C++? The library is produced by an add_custom_target() command (not 
add_custom_command() since the underlying tools do their own dependency 
checking so it is right to run the target commands every build). I need 
to have a target that I can use in target_link_libraries() and 
install(TARGETS ...) just like one would with a CMake generated library 
made with add_library() and programs made with add_executable().

If it helps the tools that are not supported by CMake are the Go 
language build tools. The project builds some Go programs as utilities 
but the main project artefact is a shared library with a C language API 
built using the cgo tools. There are many of C and C++ test programs and 
example programs as well in the project which need to link against the 
project shared library etc.

Regards
Bill Somerville.

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

From robert.maynard at kitware.com  Fri May 24 15:23:13 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 24 May 2019 15:23:13 -0400
Subject: [CMake] Dependency cycle - why?
In-Reply-To: <b3dcde8d-8b8d-6bb5-774e-c9685c899fd6@classdesign.com>
References: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>
 <b3dcde8d-8b8d-6bb5-774e-c9685c899fd6@classdesign.com>
Message-ID: <CAFzjYVpR56er82DBW6DzsbSCwAviQ+mNO+NF6SaXvuiweHSyoQ@mail.gmail.com>

Hi,

The goal that you have is fully supported by CMake. You have just run
into a bug in CMake, and you should report this to
https://gitlab.kitware.com/cmake/cmake/issues .
Basically at a very high level the name out the add_executable target
`callback_generator` is the same as the internal name that CMake is
using for the add_custom_command. This than causes some logic in CMake
(cmTargetTraceDependencies) to incorrectly build another link between
the add_custom_command and your add_executable.

The easiest way to solve this issue is name the add_executable target
to have a different name than the output of your custom command minus
file extension. So maybe something like  `callback_generator_exec`

On Fri, May 24, 2019 at 2:02 PM Bill Somerville <bill at classdesign.com> wrote:
>
> On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file (MAKE_DIRECTORY ${GOPATH})
>
> set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
> set (build_command ${GO} build)
> set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
> add_custom_command (OUTPUT ${output}
>   COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} ${sources}
>   DEPENDS ${sources}
>   VERBATIM)
> add_custom_target (callback_generator_target DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${output})
> add_executable (callback_generator IMPORTED)
> set_target_properties (callback_generator
>   PROPERTIES
>   IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
>   )
> add_dependencies (callback_generator callback_generator_target)
>
> add_custom_target (server ALL DEPENDS callback_generator)
>
> which gives this error:
>
> >cmake --version
> cmake --version
> cmake version 3.14.3
>
> >cmake -G "MinGW Makefiles" ..\..
> cmake -G "MinGW Makefiles" ..\..
> -- Configuring done
> CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
>   "callback_generator_target" of type UTILITY
>     depends on "callback_generator_target" (strong)
> The component contains at least one cycle consisting of strong dependencies (created by add_dependencies) that cannot be broken.
>
> The set_target_properties () call seems to be part of the problem but I don't understand why.
>
> Regards
> Bill Somerville.
>
> Hi again,
>
> answering my own post since no one has replied. Clearly my question was too specific. Let me try again with a more general question. I have tools that can generate executables (programs, static libraries, and shared libraries, including DLL import libraries on MS Windows). These tools are not directly supported by CMake but they are both needed within a project that uses them and installs them as the project artefacts. How do I integrate, for example a shared library, into a CMake project as if it were produced by a supported toolchain like C or C++? The library is produced by an add_custom_target() command (not add_custom_command() since the underlying tools do their own dependency checking so it is right to run the target commands every build). I need to have a target that I can use in target_link_libraries() and install(TARGETS ...) just like one would with a CMake generated library made with add_library() and programs made with add_executable().
>
> If it helps the tools that are not supported by CMake are the Go language build tools. The project builds some Go programs as utilities but the main project artefact is a shared library with a C language API built using the cgo tools. There are many of C and C++ test programs and example programs as well in the project which need to link against the project shared library etc.
>
> Regards
> Bill Somerville.
>
> --
>
> 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 Alan.W.Irwin1234 at gmail.com  Fri May 24 16:58:19 2019
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Fri, 24 May 2019 13:58:19 -0700 (PDT)
Subject: [CMake] Manually-specified variables were not used by the
 project
In-Reply-To: <171703559.10607.1558719536682@office.mailbox.org>
References: <171703559.10607.1558719536682@office.mailbox.org>
Message-ID: <nycvar.QRO.7.76.1905241345100.23191@zreyva.zlyna.ubzr>

On 2019-05-24 19:38+0200 Haio Maio wrote:

> Manually-specified variables were not used by the project
> MY_VAR
>
> when I call
>
> cmake -DMY_VAR= ...
>
>
> The goal is
> if(NOT DEFINED MY_VAR)
> ...
> else()
> ...
> if()
>
> in order to tell cmake over the command line what to do.
>
> How to achieve this ?

This functionality just works for me (using cmake version 3.13.4).

For example, here is a simple test case:

irwin at merlin> cat /tmp/CMakeLists.txt 
if(NOT DEFINED MY_VAR)
   message(STATUS "MY_VAR is not DEFINED")
else()
   message(STATUS "MY_VAR is DEFINED")
endif()

irwin at merlin> cmake -P /tmp/CMakeLists.txt 
-- MY_VAR is not DEFINED
irwin at merlin> cmake -DMY_VAR=OFF -P /tmp/CMakeLists.txt 
-- MY_VAR is DEFINED
irwin at merlin> cmake -DMY_VAR=ON -P /tmp/CMakeLists.txt 
-- MY_VAR is DEFINED

So just like the documentation says at <https://cmake.org/cmake/help/latest/command/if.html>
what is tested is whether *any* true or false value has been set.  What is more problematic
is how to make sure the variable is not set with the -D option, and the only way I
know how to do that is the first test above (i.e., do not use -DMY_VAR=??? at all).

I hope this simple example helps you to figure out what is going on with your more complex
example.

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 bill at classdesign.com  Sat May 25 07:51:28 2019
From: bill at classdesign.com (Bill Somerville)
Date: Sat, 25 May 2019 12:51:28 +0100
Subject: [CMake] Dependency cycle - why?
In-Reply-To: <CAFzjYVpR56er82DBW6DzsbSCwAviQ+mNO+NF6SaXvuiweHSyoQ@mail.gmail.com>
References: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>
 <b3dcde8d-8b8d-6bb5-774e-c9685c899fd6@classdesign.com>
 <CAFzjYVpR56er82DBW6DzsbSCwAviQ+mNO+NF6SaXvuiweHSyoQ@mail.gmail.com>
Message-ID: <52120453-2ea9-27aa-d17f-a3b5b4db7bfa@classdesign.com>

Hi Robert,

thanks for that, the target name change does seem to help but I am still 
unable to achieve my goal. Here is a simplified example that 
demonstrates the problem:

cmake_minimum_required (VERSION? 3.1.0 FATAL_ERROR)
project (demo LANGUAGES NONE)
add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch prog${CMAKE_EXECUTABLE_SUFFIX})
add_executable (prog IMPORTED)
add_dependencies (prog prog_target)
set_target_properties (prog PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
install (TARGETS prog RUNTIME DESTINATION bin)

which gives the following error at CMake configuration:

CMake Error at CMakeLists.txt:7 (install):
   install TARGETS given target "prog" which does not exist.


-- Configuring incomplete, errors occurred!

So the target that 'add_executable(name IMPORTED)' creates is not a real 
executable target. I can change its properties but the 'install(TARGETS 
...)' command thinks it does not exist. Note that a executable target is 
a very simple demonstration and I understand that I can use 
'install(PROGRAM ...)' just about as easily, but when it comes to a 
shared library it gets a lot more complex when using, exporting, and 
instlling it, and it seems that IMPORTED targets fall well short of 
useful when they are actually produced by the current CMake project.

I can understand that an IMPORTED target is perhaps not meant to be 
installable but if so then your statement that "The goal that you have 
is fully supported by CMake" seems to be incorrect. To reiterate, I am 
trying to use foreign tools to make binary targets and wish to have 
CMake treat them *as if* they were created by supported languages like 
C, ++, or Fortran. Am I still missing something?

Regards
Bill Somerville.

On 24/05/2019 20:23, Robert Maynard wrote:
> Hi,
>
> The goal that you have is fully supported by CMake. You have just run
> into a bug in CMake, and you should report this to
> https://gitlab.kitware.com/cmake/cmake/issues .
> Basically at a very high level the name out the add_executable target
> `callback_generator` is the same as the internal name that CMake is
> using for the add_custom_command. This than causes some logic in CMake
> (cmTargetTraceDependencies) to incorrectly build another link between
> the add_custom_command and your add_executable.
>
> The easiest way to solve this issue is name the add_executable target
> to have a different name than the output of your custom command minus
> file extension. So maybe something like  `callback_generator_exec`
>
> On Fri, May 24, 2019 at 2:02 PM Bill Somerville <bill at classdesign.com> wrote:
>> On 13/05/2019 12:03, Bill Somerville wrote:
>>
>> Hi folks,
>>
>> I am struggling to understand what the problem is with this:
>>
>> find_program (GO go)
>> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
>> file (MAKE_DIRECTORY ${GOPATH})
>>
>> set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
>> set (build_command ${GO} build)
>> set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
>> add_custom_command (OUTPUT ${output}
>>    COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} ${sources}
>>    DEPENDS ${sources}
>>    VERBATIM)
>> add_custom_target (callback_generator_target DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${output})
>> add_executable (callback_generator IMPORTED)
>> set_target_properties (callback_generator
>>    PROPERTIES
>>    IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
>>    )
>> add_dependencies (callback_generator callback_generator_target)
>>
>> add_custom_target (server ALL DEPENDS callback_generator)
>>
>> which gives this error:
>>
>>> cmake --version
>> cmake --version
>> cmake version 3.14.3
>>
>>> cmake -G "MinGW Makefiles" ..\..
>> cmake -G "MinGW Makefiles" ..\..
>> -- Configuring done
>> CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
>>    "callback_generator_target" of type UTILITY
>>      depends on "callback_generator_target" (strong)
>> The component contains at least one cycle consisting of strong dependencies (created by add_dependencies) that cannot be broken.
>>
>> The set_target_properties () call seems to be part of the problem but I don't understand why.
>>
>> Regards
>> Bill Somerville.
>>
>> Hi again,
>>
>> answering my own post since no one has replied. Clearly my question was too specific. Let me try again with a more general question. I have tools that can generate executables (programs, static libraries, and shared libraries, including DLL import libraries on MS Windows). These tools are not directly supported by CMake but they are both needed within a project that uses them and installs them as the project artefacts. How do I integrate, for example a shared library, into a CMake project as if it were produced by a supported toolchain like C or C++? The library is produced by an add_custom_target() command (not add_custom_command() since the underlying tools do their own dependency checking so it is right to run the target commands every build). I need to have a target that I can use in target_link_libraries() and install(TARGETS ...) just like one would with a CMake generated library made with add_library() and programs made with add_executable().
>>
>> If it helps the tools that are not supported by CMake are the Go language build tools. The project builds some Go programs as utilities but the main project artefact is a shared library with a C language API built using the cgo tools. There are many of C and C++ test programs and example programs as well in the project which need to link against the project shared library etc.
>>
>> Regards
>> Bill Somerville.
>>
>> --
>>
>> 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/20190525/a35bb45f/attachment-0001.html>

From eric.noulard at gmail.com  Sat May 25 10:47:05 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Sat, 25 May 2019 16:47:05 +0200
Subject: [CMake] Dependency cycle - why?
In-Reply-To: <52120453-2ea9-27aa-d17f-a3b5b4db7bfa@classdesign.com>
References: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>
 <b3dcde8d-8b8d-6bb5-774e-c9685c899fd6@classdesign.com>
 <CAFzjYVpR56er82DBW6DzsbSCwAviQ+mNO+NF6SaXvuiweHSyoQ@mail.gmail.com>
 <52120453-2ea9-27aa-d17f-a3b5b4db7bfa@classdesign.com>
Message-ID: <CAPASGLpQW-_U7JL-GmYRfAZLPp1LBZoK7kJGe=AcJHCTU4vTBw@mail.gmail.com>

Le sam. 25 mai 2019 ? 13:51, Bill Somerville <bill at classdesign.com> a
?crit :

> Hi Robert,
>
> thanks for that, the target name change does seem to help but I am still
> unable to achieve my goal. Here is a simplified example that demonstrates
> the problem:
>
> cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
> project (demo LANGUAGES NONE)
> add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch prog${CMAKE_EXECUTABLE_SUFFIX})
> add_executable (prog IMPORTED)
> add_dependencies (prog prog_target)
> set_target_properties (prog PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
> install (TARGETS prog RUNTIME DESTINATION bin)
>
> which gives the following error at CMake configuration:
>
> CMake Error at CMakeLists.txt:7 (install):
>   install TARGETS given target "prog" which does not exist.
>
>
> -- Configuring incomplete, errors occurred!
>
> So the target that 'add_executable(name IMPORTED)' creates is not a real
> executable target. I can change its properties but the 'install(TARGETS
> ...)' command thinks it does not exist. Note that a executable target is a
> very simple demonstration and I understand that I can use 'install(PROGRAM
> ...)' just about as easily, but when it comes to a shared library it gets a
> lot more complex when using, exporting, and instlling it, and it seems that
> IMPORTED targets fall well short of useful when they are actually produced
> by the current CMake project.
>
> I can understand that an IMPORTED target is perhaps not meant to be
> installable
>

Robert will give his advice on that but I bet IMPORTED target were never
meant to be drop-in *replacement* of genuine target.

They were meant to ease *reference to* object/lib:executable that are
outside the build of the project.
e.g the doc says:
https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
"An IMPORTED library target references a library file located outside the
project"

Nmelly a target that is "already installed somewhere" and that you want to
reference in your CMake build.


> but if so then your statement that "The goal that you have is fully
> supported by CMake" seems to be incorrect. To reiterate, I am trying to use
> foreign tools to make binary targets and wish to have CMake treat them *as
> if* they were created by supported languages like C, ++, or Fortran. Am I
> still missing something?
>

My opinion is that IMPORTED target are not designed (as of today) for that
purpose.

When you want to do what you seem to want you need to either:
1) add a "new LANGUAGE" (you seem to be willing to add golang)
    see:
https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
    and may be: https://github.com/aadidenko/golang-cmake-example (or fork
of this)

2) define a set of custom macros that mimic genuine target behaviour.
    may be see: https://github.com/cpconduce/go_cmake

If you want to have a look at existing similar example shippped with CMake,
have a look at UseJava.cmake module (
https://cmake.org/cmake/help/latest/module/UseJava.html)
You'll see that you have
add_jar, which is similar to add_executable and create a custom target
and
install_jar which is similar to install on genuine target but plays with
target properties and install(FILES...) in order to mimic that.
see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake

I'm not developing with golang but AFAIK go has a builtin "build system" so
bringing go as a language in CMake may not be the best option,
but again I am no Go expert.

The only reference of that kind of thing I found in the CMake mailing list
is oldish:
https://cmake.org/pipermail/cmake-developers/2011-August/013715.html

May be adding the support for "install" command for IMPORTED target is
doable but this seems to be a feature request to be discussed on developer
mailing list;
Regards,
Eric


> Regards
> Bill Somerville.
>
> On 24/05/2019 20:23, Robert Maynard wrote:
>
> Hi,
>
> The goal that you have is fully supported by CMake. You have just run
> into a bug in CMake, and you should report this tohttps://gitlab.kitware.com/cmake/cmake/issues .
> Basically at a very high level the name out the add_executable target
> `callback_generator` is the same as the internal name that CMake is
> using for the add_custom_command. This than causes some logic in CMake
> (cmTargetTraceDependencies) to incorrectly build another link between
> the add_custom_command and your add_executable.
>
> The easiest way to solve this issue is name the add_executable target
> to have a different name than the output of your custom command minus
> file extension. So maybe something like  `callback_generator_exec`
>
> On Fri, May 24, 2019 at 2:02 PM Bill Somerville <bill at classdesign.com> <bill at classdesign.com> wrote:
>
> On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file (MAKE_DIRECTORY ${GOPATH})
>
> set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
> set (build_command ${GO} build)
> set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
> add_custom_command (OUTPUT ${output}
>   COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} ${sources}
>   DEPENDS ${sources}
>   VERBATIM)
> add_custom_target (callback_generator_target DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${output})
> add_executable (callback_generator IMPORTED)
> set_target_properties (callback_generator
>   PROPERTIES
>   IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
>   )
> add_dependencies (callback_generator callback_generator_target)
>
> add_custom_target (server ALL DEPENDS callback_generator)
>
> which gives this error:
>
>
> cmake --version
>
> cmake --version
> cmake version 3.14.3
>
>
> cmake -G "MinGW Makefiles" ..\..
>
> cmake -G "MinGW Makefiles" ..\..
> -- Configuring done
> CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
>   "callback_generator_target" of type UTILITY
>     depends on "callback_generator_target" (strong)
> The component contains at least one cycle consisting of strong dependencies (created by add_dependencies) that cannot be broken.
>
> The set_target_properties () call seems to be part of the problem but I don't understand why.
>
> Regards
> Bill Somerville.
>
> Hi again,
>
> answering my own post since no one has replied. Clearly my question was too specific. Let me try again with a more general question. I have tools that can generate executables (programs, static libraries, and shared libraries, including DLL import libraries on MS Windows). These tools are not directly supported by CMake but they are both needed within a project that uses them and installs them as the project artefacts. How do I integrate, for example a shared library, into a CMake project as if it were produced by a supported toolchain like C or C++? The library is produced by an add_custom_target() command (not add_custom_command() since the underlying tools do their own dependency checking so it is right to run the target commands every build). I need to have a target that I can use in target_link_libraries() and install(TARGETS ...) just like one would with a CMake generated library made with add_library() and programs made with add_executable().
>
> If it helps the tools that are not supported by CMake are the Go language build tools. The project builds some Go programs as utilities but the main project artefact is a shared library with a C language API built using the cgo tools. There are many of C and C++ test programs and example programs as well in the project which need to link against the project shared library etc.
>
> Regards
> Bill Somerville.
>
> --
>
> 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
>


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

From bill at classdesign.com  Sat May 25 13:15:42 2019
From: bill at classdesign.com (Bill Somerville)
Date: Sat, 25 May 2019 18:15:42 +0100
Subject: [CMake] Dependency cycle - why?
In-Reply-To: <CAPASGLpQW-_U7JL-GmYRfAZLPp1LBZoK7kJGe=AcJHCTU4vTBw@mail.gmail.com>
References: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>
 <b3dcde8d-8b8d-6bb5-774e-c9685c899fd6@classdesign.com>
 <CAFzjYVpR56er82DBW6DzsbSCwAviQ+mNO+NF6SaXvuiweHSyoQ@mail.gmail.com>
 <52120453-2ea9-27aa-d17f-a3b5b4db7bfa@classdesign.com>
 <CAPASGLpQW-_U7JL-GmYRfAZLPp1LBZoK7kJGe=AcJHCTU4vTBw@mail.gmail.com>
Message-ID: <2409068a-865a-4ba2-6089-3f7ae6c6d065@classdesign.com>

Hi Eric,

thanks for the comprehensive reply to my query. My follow up comments in 
line below.

On 25/05/2019 15:47, Eric Noulard wrote:
> Le?sam. 25 mai 2019 ??13:51, Bill Somerville <bill at classdesign.com 
> <mailto:bill at classdesign.com>> a ?crit?:
>
>     Hi Robert,
>
>     thanks for that, the target name change does seem to help but I am
>     still unable to achieve my goal. Here is a simplified example that
>     demonstrates the problem:
>
>     cmake_minimum_required (VERSION? 3.1.0 FATAL_ERROR)
>     project (demo LANGUAGES NONE)
>     add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch prog${CMAKE_EXECUTABLE_SUFFIX})
>     add_executable (prog IMPORTED)
>     add_dependencies (prog prog_target)
>     set_target_properties (prog PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
>     install (TARGETS prog RUNTIME DESTINATION bin)
>
>     which gives the following error at CMake configuration:
>
>     CMake Error at CMakeLists.txt:7 (install):
>        install TARGETS given target "prog" which does not exist.
>
>
>     -- Configuring incomplete, errors occurred!
>
>     So the target that 'add_executable(name IMPORTED)' creates is not
>     a real executable target. I can change its properties but the
>     'install(TARGETS ...)' command thinks it does not exist. Note that
>     a executable target is a very simple demonstration and I
>     understand that I can use 'install(PROGRAM ...)' just about as
>     easily, but when it comes to a shared library it gets a lot more
>     complex when using, exporting, and instlling it, and it seems that
>     IMPORTED targets fall well short of useful when they are actually
>     produced by the current CMake project.
>
>     I can understand that an IMPORTED target is perhaps not meant to
>     be installable
>
>
> Robert will give his advice on that but I bet IMPORTED target were 
> never meant to be drop-in *replacement* of genuine target.
>
> They were meant to ease *reference to* object/lib:executable that are 
> outside the build of the project.
> e.g the doc says: 
> https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
> "An IMPORTED library target references a library file located outside 
> the project"
>
> Nmelly a target that is "already installed somewhere" and that you 
> want to reference in your CMake build.
That is fine but I don't see why there is a problem with making IMPORTED 
targets better CMake citizens, it should be down to the CMake script 
author as to whether they take advantage of that. What is there now is a 
lie and the add_*(target ... IMPORTED ...) commands are not doing what 
they should IMHO.
>
>     but if so then your statement that "The goal that you have is
>     fully supported by CMake" seems to be incorrect. To reiterate, I
>     am trying to use foreign tools to make binary targets and wish to
>     have CMake treat them *as if* they were created by supported
>     languages like C, ++, or Fortran. Am I still missing something?
>
>
> My opinion is that IMPORTED target are not designed (as of today) for 
> that purpose.
Agreed.
>
> When you want to do what you seem to want you need to either:
> 1) add a "new LANGUAGE" (you seem to be willing to add golang)
> ? ? see: 
> https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
> ? ? and may be: https://github.com/aadidenko/golang-cmake-example (or 
> fork of this)
I am not sure that adding a new CMake supported language is right for 
Go. For the Go ecosystem the Go build tools do the right thing and CMake 
is largely unnecessary. Particularly the Go build system deals with 
dependencies internally so I don't see how it could be added to CMake 
without using the lower level Go tools and having to list many source 
dependencies that the high level Go build system deals with without 
fuss. Note that I am dealing with cgo which allows Go language static or 
shared libraries to interoperate with other languages via a C API. This 
is where CMake needs to join in because a project using cgo is likely to 
build tests, tools, and libraries in languages that CMake does support. 
As far as I can see the Go build system support is weak in providing a 
"package" from, for example, a cgo shared library, it just builds the 
shared object and header files and stops there.
>
> 2) define a set of custom macros that mimic genuine target behaviour.
> ? ? may be see: https://github.com/cpconduce/go_cmake
This is exactly where I started but it only covers tools written in Go 
and uses install(PROGRAMS ...) to install them. It uses 
add_custom_command() which means all source dependencies must be 
specified for reliable rebuilds, which is effectively discarding the 
dependency management of the Go build system. It would be very fragile 
in a large project and doesn't address the cgo capabilities to create 
libraries. My queries here are exactly because I am trying to extend 
this approach to tools and libraries that play well in the CMake 
ecosystem, without sacrificing the advantages of the Go build system. I 
can, and have, written CMake functions that use add_custom_target() to 
defer Go builds to the Go build system, but am failing so far to bridge 
the results with CMake. Clearly at present IMPORTED targets do not work 
for this, so I guess I am asking how to do this another way, e.g. by 
setting all the necessary target properties to make my targets proper 
CMake citizens?
>
> If you want to have a look at existing similar example shippped with 
> CMake, have a look at UseJava.cmake module 
> (https://cmake.org/cmake/help/latest/module/UseJava.html)
> You'll see that you have
> add_jar, which is similar to add_executable and create a custom target
> and
> install_jar which is similar to install on genuine target but plays 
> with target properties and install(FILES...) in order to mimic that.
> see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake
This looks more interesting and complete but the first thing I note is 
that it does not really integrate with the CMake ecosystem, instead it 
has a parallel set of commands (add|install|find|export)_jar() that 
mimic the CMake equivalents. That may work well for Java, even including 
a foreign function interface as it seems to support JNI, but there is a 
key difference. A Java class file is linked purely at runtime so there 
is no need for CMake to know about how to link the JAR file to a native 
executable target (it uses add_library(target INTERFACE ...) to 
integrate the generated API headers). With Go and cgo the generated 
library *is a native library*, just as Go tools are native binaries, and 
to use them seamlessly in CMake they have to behave as any other 
imported or built executable target, a parallel set of CMake commands 
that do not integrate the target will not get the job done.
>
> I'm not developing with golang but AFAIK go has a builtin "build 
> system" so bringing go as a language in CMake may not be the best option,
> but again I am no Go expert.

You are correct and this is exactly why I am looking for a way to hook 
the products of the Go build system into CMake rather than trying to add 
it as a supported language. I do not know enough abut the low level Go 
build system commands to understand if they are suitable for driving 
from CMake like it does for C, C++, or Fortran compilers and the target 
system linker but that seems to be the wrong approach, I'd rather use 
the top level 'go build' command and tell CMake about what I expect it 
to build and what top level targets I want to be up to date before that 
step. This seems to be a simple add_custom_target() invocation. There is 
a small penalty that the 'go build' command will always run but that's 
fine since I expect 'go build' to do minimal re-builds based on its own 
dependency tracking.

The approach I am current trying is to treat cgo libraries as INTERFACE 
libraries and having my CMake scripts reference the library binaries by 
their path by misusing target_link_libraries(so_library_target INTERFACE 
...) to hook things up. This doesn't help with installing the library 
target but that can be done using install(PROGRAMS ...). That at least 
allows install(EXPORT ...) to work, I think - I have not yet tried 
importing the shared library into anther CMake project.

>
> The only reference of that kind of thing I found in the CMake mailing 
> list is oldish:
> https://cmake.org/pipermail/cmake-developers/2011-August/013715.html
That link shows exactly why using the Go build tools as a custom target 
command is right IMHO, it also doesn't address using the product of the 
build in the same or other projects.
>
> May be adding the support for "install" command for IMPORTED target is 
> doable but this seems to be a feature request to be discussed on 
> developer mailing list;

I think there is justification since a CMake script author decides 
whether to take advantage of it. It seems to me that there is stuff that 
is internal to the CMake C++ application similar to properties but not 
addressable by the script author. Of course it all depends how complex 
that stuff is and whether if can be addressed by either some new target 
properties or extra arguments to the add_(executable|library)(target 
IMPORTED) commands. The latter seems easiest as the internal logic and 
data model need not be exposed for misuse by script authors.

If there really is not a practical way to build a library or tool with a 
foreign toolchain in CMake and have it integrated like the ones produced 
by supported languages then I will raise an issue on the development 
forum, but TBH I am disappointed that manipulating existing target 
properties is not sufficient. Custom targets seem to fall well short of 
what they promise.

> Regards,
> Eric
Regards
Bill Somerville.


>
>
>     Regards
>     Bill Somerville.
>
>     On 24/05/2019 20:23, Robert Maynard wrote:
>>     Hi,
>>
>>     The goal that you have is fully supported by CMake. You have just run
>>     into a bug in CMake, and you should report this to
>>     https://gitlab.kitware.com/cmake/cmake/issues  .
>>     Basically at a very high level the name out the add_executable target
>>     `callback_generator` is the same as the internal name that CMake is
>>     using for the add_custom_command. This than causes some logic in CMake
>>     (cmTargetTraceDependencies) to incorrectly build another link between
>>     the add_custom_command and your add_executable.
>>
>>     The easiest way to solve this issue is name the add_executable target
>>     to have a different name than the output of your custom command minus
>>     file extension. So maybe something like  `callback_generator_exec`
>>

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

From craig.scott at crascit.com  Sun May 26 08:02:18 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sun, 26 May 2019 22:02:18 +1000
Subject: [CMake] Problems with ExternalProject_Add
In-Reply-To: <ea6ea973-5983-a9d4-1846-0806d61dad80@gmx.at>
References: <ea6ea973-5983-a9d4-1846-0806d61dad80@gmx.at>
Message-ID: <CA+dygYmoZNYeeR1OQ959RyiBJTQtPUgON3b5-GJOVsazn1x0gQ@mail.gmail.com>

On Wed, May 22, 2019 at 7:13 PM Steven Truppe <workbench at gmx.at> wrote:

> Hi everyone,
>
>
> i'm trying to use ExternalProject_Add like the following:
>
> set(BOOST_VERSION 1.68.0)
> set(BOOST_VERSION_NODOTS 1_68_0)
> set(BOOST_URI https://dl.bintray.com/boostorg/release/${BOOST_VERSION}/source/boost_${BOOST_VERSION_NODOTS}.tar.gz)
> set(BOOST_HASH 5d8b4503582fffa9eefdb9045359c239)
>
> ExternalProject_Add(external_boost
>         PREFIX ${CMAKE_BINARY_DIR}/boost
> 		URL ${BOOST_URL}
>         DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost
> 		URL_HASH MD5=${BOOST_HASH}
>         CONFIGURE_COMMAND  cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ./bootstrab --prefix=${OUTPUT_PATH}/boost
> 		BUILD_COMMAND  cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ./b2
> 		BUILD_IN_SOURCE 1
> 		INSTALL_DIR ${OUTPUT_PATH}/boost
>
> The problem is that he tells me that the md5 sum isn't correct, but i did md5sum ${BOOST_URL}.
>
>
Looking in the same directory from which you are trying to download, there
is a boost_1_68_0.tar.gz.json file which contains the expected sha256 sum.
You would be better off using that in this case:

set(BOOST_HASH da3411ea45622579d419bfda66f45cd0f8c32a181d84adfa936f5688388995cf)


You'd also need to change the URL_HASH in your call to
ExternalProject_Add():

		URL_HASH SHA256=${BOOST_HASH}


Your ExternalProject_Add() command also seems to have a few typos in
various places (BOOST_URL instead of BOOST_URI, the CONFIGURE_COMMAND
contains ./bootstrab which looks suspicious) and you should use separate
COMMAND entries rather than using && to specify multiple commands for a
given stage. Have a read through the ExternalProject_Add() docs for more
details, specifically the "Miscellaneous Options" subsection.


-- 
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/20190526/2dea2d25/attachment.html>

From workbench at gmx.at  Sun May 26 09:06:59 2019
From: workbench at gmx.at (Steven Truppe)
Date: Sun, 26 May 2019 15:06:59 +0200
Subject: [CMake] Questin about ExternalProject_Add
Message-ID: <12e294be-b4b9-fea6-e558-0db497e46795@gmx.at>

Hi everyone,

i'm trying to create a build system that download all needed libraries
with ExternalProject_Add.

i've the following lines in my CMakeLists.txt:

option(WITH_LIB_GLFW "Support for the GLFW library. (default: 1)" 1)
option(WITH_LIB_NLOHMANN_JSON "Support for the nlohmann JSON library.
(default: 1)" 1)
option(WITH_LIB_ZLIB "Support for the zlib library. (default: 1)" 1)
option(WITH_LIB_ZLMA "Support for the zlma library. (default: 1)" 1)
option(WITH_LIB_FLEX "Support for the flex library. (default: 1)" 1)
option(WITH_LIB_OPENSSL "Support for the OpenSSL library. (default: 1)" 1)
option(WITH_LIB_BZIP2 "Support for the bzip2 library. (default: 1)" 1)
option(WITH_LIB_FREETYPE "Support for the freetype library (default: 1)" 1)
option(WITH_LIB_STB_IMAGE "Support for? JPG, PNG, TGA, BMP, PSD, GIF,
HDR, PIC" 1)
option(WITH_LIB_STB_IMAGE_WRITE "Support to write PNG, TGA and BMP" 1)
option(WITH_LIB_PYTHON "Support for Python embeding" 1)
option(WITH_LIB_BOOST "Support for the boost C++ library" 1)

and later in that file i have:

IF(WITH_LIB_GLFW)
 ??? message(STATUS "WITH_LIB_GLAD")
 ??? include(glad_def)
 ??? include(glad_deps)
 ??? message(STATUS "WITH_LIB_GLFW")
 ??? include(glfw_def)
 ??? include(glfw_deps)
ENDIF()

IF(WITH_LIB_NLOHMANN_JSON)
 ??? message(STATUS "WITH_LIB_NLOHMANN_JSON")
 ??? include(nlohmann_json_def)
 ??? include(nlohmann_json_deps)
ENDIF()

IF(WITH_LIB_STB_IMAGE)
 ??? message(STATUS "WITH_LIB_STB_IMAGE")
 ??? include(stb_image_deps)
ENDIF()

IF(WITH_LIB_STB_IMAGE_WRITE)
 ??? message(STATUS "WITH_LIB_STB_IMAGE_WRITE")
 ??? include(stb_image_write_deps)
ENDIF()


IF(WITH_LIB_FTGL)
 ??? message(STATUS "WITH_LIB_FTGL")
 ??? #??? include(ftgl_defs)
 ??? include(ftgl_deps)
ENDIF()


IF(WITH_LIB_ZLIB)
 ??? message(STATUS "WITH_LIB_ZLIB")
 ??? include(zlib_deps)
ENDIF()

IF(WITH_LIB_FLEX)
 ??? message(STATUS "WITH_LIB_FLEX")
 ??? include(flex_deps)
ENDIF()

IF(WITH_LIB_BISON)
 ??? message(STATUS "WITH_LIB_BISON")
 ??? include(bison_deps)
ENDIF()

IF(WITH_LIB_BZIP2)
 ??? message(STATUS "WITH_LIB_BZIP2")
 ??? include(bzip2_deps)
ENDIF()


IF(WITH_LIB_ZLMA)
 ??? message(STATUS "WITH_LIB_ZLMA")
 ??? include(zlma_deps)
ENDIF()


IF(WITH_LIB_OPENSSL)
 ??? message(STATUS "WITH_LIB_OPENSSL")
 ??? include(openssl_deps)
ENDIF()

IF(WITH_LIB_GETTEXT)
 ??? message(STATUS "WITH_LIB_GETTEXT")
 ??? include(gettext_deps)
ENDIF()

IF(WITH_LIB_FREETYPE)
 ??? message(STATUS "WITH_LIB_FREETYPE")
 ??? include(freetype_deps)
ENDIF()

IF(WITH_LIB_PYTHON)
 ??? message(STATUS "WITH_LIB_PYTHON")
 ??? include(python_defs)
 ??? include(python_deps)
ENDIF()

IF(WITH_LIB_BOOST)
 ??? message(STATUS "WITH_LIB_BOOST")
 ??? include(boost_deps)
ENDIF()

The strange thing is that he does not does it in the right order - he
start's with WITH_LIB_BOOST instead of WITH_LIB_GLFW.


What am i doing wrong here ??


best regards!


From craig.scott at crascit.com  Sun May 26 09:30:53 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sun, 26 May 2019 23:30:53 +1000
Subject: [CMake] Changed behavior of CPACK_PACKAGE_VERSION generation?
In-Reply-To: <HE1PR04MB29881EAAFAE771D096BE56C0FBA70@HE1PR04MB2988.eurprd04.prod.outlook.com>
References: <HE1PR04MB29881EAAFAE771D096BE56C0FBA70@HE1PR04MB2988.eurprd04.prod.outlook.com>
Message-ID: <CA+dygYkSMcFfi0zqnR=gkEbHOZ-ZqH+ENVSkLCfZW9DZH-abSA@mail.gmail.com>

A little late, but finally got a chance to look at this. In CMake 3.12.0,
the CPack version handling in Modules/CPack.cmake was changed to take its
default from the project version, if set. This was implemented but the
following logic:

if(CMAKE_PROJECT_VERSION_PATCH)

    ...

endif()


This introduced a bug in that a legitimate value of 0 was then treated as
FALSE, so the common case of the value being zero was resulting in the
value being ignored and falling back to the old default, which was 1. This
was fixed in CMake 3.12.1 by changing it to the following:

if(CMAKE_PROJECT_VERSION_PATCH GREATER_EQUAL 0)

    ...

endif()


As part of that same change, the following block of code was also added:

if(NOT DEFINED CPACK_PACKAGE_VERSION)

  set(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}")

  if(CPACK_PACKAGE_VERSION_MINOR GREATER_EQUAL 0)

    string(APPEND CPACK_PACKAGE_VERSION ".${CPACK_PACKAGE_VERSION_MINOR}")

    if(CPACK_PACKAGE_VERSION_PATCH GREATER_EQUAL 0)

      string(APPEND CPACK_PACKAGE_VERSION ".${CPACK_PACKAGE_VERSION_PATCH}")

    endif()

  endif()

endif()


Now, your project has been setting CPACK_PACKAGE_VERSION_PATCH to REPLACEME,
which is not a valid number, so the patch version will no longer be getting
appended to CPACK_PACKAGE_VERSION, as you've observed. This explains at
least the history of what happened. I don't know if it was ever considered
valid to set it to anything other than a number, so it isn't clear whether
this should be considered a regression or not. If you feel strongly enough
that it is, I suggest you create an issue in gitlab
<https://gitlab.kitware.com/cmake/cmake/issues/new> and transfer the
details of this email trail to there.





On Thu, Dec 13, 2018 at 5:32 AM Bj?rn Blissing <bjorn.blissing at vti.se>
wrote:

> Hi,
>
> Today we discovered that our generated CPACK_PACKAGE_VERSION variables
> were broken.
> This is probably related to us updating to a newer version of CMake.
>
> Previously we generated this variable by setting the
> CPACK_PACKAGE_VERSION_MAJOR and CPACK_PACKAGE_VERSION_MINOR to fixed
> values, while CPACK_PACKAGE_VERSION_PATCH was set to variable name.
> This name was then replaced by running a custom target just before
> building. In this target the variable name got replaced with the current
> SVN revision number. This have worked the last years, but now the variable
> name just gets omitted when we run "generate" in CMake.
>
> A short example:
> ================
> cmake_minimum_required(VERSION 2.8.9)
> project (hello)
> add_executable(hello helloworld.cpp)
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
> include(CPack)
>
> Would result in the following strings in CPackConfig.cmake:
> -----------------------------------------------------------
> set(CPACK_PACKAGE_VERSION "1.0.REPLACEME")
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
>
>
> But with the CMake 3.12.2 this will be:
> ---------------------------------------
> set(CPACK_PACKAGE_VERSION "1.0")
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
>
>
> So our CPACK_PACKAGE_VERSION will omit the variable name, which in turn
> makes our custom target to fail.
>
> Our quick fix was to add the following line to our CMakeList.txt file:
> SET(CPACK_PACKAGE_VERSION
> "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
>
> My question is: Is this change of behavior intended? Are only numbers
> allowed to be part of the CPack version variable?
>
> Regards
> Bj?rn Blissing
>


-- 
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/20190526/2e0843ca/attachment.html>

From robert.maynard at kitware.com  Mon May 27 07:50:46 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 27 May 2019 07:50:46 -0400
Subject: [CMake] Dependency cycle - why?
In-Reply-To: <CAPASGLpQW-_U7JL-GmYRfAZLPp1LBZoK7kJGe=AcJHCTU4vTBw@mail.gmail.com>
References: <56dc0bc9-930f-e9e8-b8fd-680780f356c3@classdesign.com>
 <b3dcde8d-8b8d-6bb5-774e-c9685c899fd6@classdesign.com>
 <CAFzjYVpR56er82DBW6DzsbSCwAviQ+mNO+NF6SaXvuiweHSyoQ@mail.gmail.com>
 <52120453-2ea9-27aa-d17f-a3b5b4db7bfa@classdesign.com>
 <CAPASGLpQW-_U7JL-GmYRfAZLPp1LBZoK7kJGe=AcJHCTU4vTBw@mail.gmail.com>
Message-ID: <CAFzjYVpD=MAUFjZY5eBUWmcuSC4qk=TeN-MRdpSVcNeUcKWqpw@mail.gmail.com>

I misspoke. I meant that what you want to do with the custom commands
was supported by CMake.

Adding support for extra languages to CMake requires modifications at
the C++ level, if you want full support. Things such as installing,
and generator expressions require C++ level changes.

On Sat, May 25, 2019 at 10:47 AM Eric Noulard <eric.noulard at gmail.com> wrote:
>
>
>
> Le sam. 25 mai 2019 ? 13:51, Bill Somerville <bill at classdesign.com> a ?crit :
>>
>> Hi Robert,
>>
>> thanks for that, the target name change does seem to help but I am still unable to achieve my goal. Here is a simplified example that demonstrates the problem:
>>
>> cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
>> project (demo LANGUAGES NONE)
>> add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch prog${CMAKE_EXECUTABLE_SUFFIX})
>> add_executable (prog IMPORTED)
>> add_dependencies (prog prog_target)
>> set_target_properties (prog PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
>> install (TARGETS prog RUNTIME DESTINATION bin)
>>
>> which gives the following error at CMake configuration:
>>
>> CMake Error at CMakeLists.txt:7 (install):
>>   install TARGETS given target "prog" which does not exist.
>>
>>
>> -- Configuring incomplete, errors occurred!
>>
>> So the target that 'add_executable(name IMPORTED)' creates is not a real executable target. I can change its properties but the 'install(TARGETS ...)' command thinks it does not exist. Note that a executable target is a very simple demonstration and I understand that I can use 'install(PROGRAM ...)' just about as easily, but when it comes to a shared library it gets a lot more complex when using, exporting, and instlling it, and it seems that IMPORTED targets fall well short of useful when they are actually produced by the current CMake project.
>>
>> I can understand that an IMPORTED target is perhaps not meant to be installable
>
>
> Robert will give his advice on that but I bet IMPORTED target were never meant to be drop-in *replacement* of genuine target.

That is correct. Specifically imported targets aren't meant to be
exported or installed. They are meant to represent some item that
already exists on disk, and as such you should install the logic that
constructs the imported targets.
>
> They were meant to ease *reference to* object/lib:executable that are outside the build of the project.
> e.g the doc says: https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
> "An IMPORTED library target references a library file located outside the project"
>
> Nmelly a target that is "already installed somewhere" and that you want to reference in your CMake build.
>
>>
>> but if so then your statement that "The goal that you have is fully supported by CMake" seems to be incorrect. To reiterate, I am trying to use foreign tools to make binary targets and wish to have CMake treat them *as if* they were created by supported languages like C, ++, or Fortran. Am I still missing something?
>
>
> My opinion is that IMPORTED target are not designed (as of today) for that purpose.
>
> When you want to do what you seem to want you need to either:
> 1) add a "new LANGUAGE" (you seem to be willing to add golang)
>     see: https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
>     and may be: https://github.com/aadidenko/golang-cmake-example (or fork of this)
>
> 2) define a set of custom macros that mimic genuine target behaviour.
>     may be see: https://github.com/cpconduce/go_cmake
>
> If you want to have a look at existing similar example shippped with CMake, have a look at UseJava.cmake module (https://cmake.org/cmake/help/latest/module/UseJava.html)
> You'll see that you have
> add_jar, which is similar to add_executable and create a custom target
> and
> install_jar which is similar to install on genuine target but plays with target properties and install(FILES...) in order to mimic that.
> see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake
>
> I'm not developing with golang but AFAIK go has a builtin "build system" so bringing go as a language in CMake may not be the best option,
> but again I am no Go expert.
>
> The only reference of that kind of thing I found in the CMake mailing list is oldish:
> https://cmake.org/pipermail/cmake-developers/2011-August/013715.html
>
> May be adding the support for "install" command for IMPORTED target is doable but this seems to be a feature request to be discussed on developer mailing list;
> Regards,
> Eric
>
>>
>> Regards
>> Bill Somerville.
>>
>> On 24/05/2019 20:23, Robert Maynard wrote:
>>
>> Hi,
>>
>> The goal that you have is fully supported by CMake. You have just run
>> into a bug in CMake, and you should report this to
>> https://gitlab.kitware.com/cmake/cmake/issues .
>> Basically at a very high level the name out the add_executable target
>> `callback_generator` is the same as the internal name that CMake is
>> using for the add_custom_command. This than causes some logic in CMake
>> (cmTargetTraceDependencies) to incorrectly build another link between
>> the add_custom_command and your add_executable.
>>
>> The easiest way to solve this issue is name the add_executable target
>> to have a different name than the output of your custom command minus
>> file extension. So maybe something like  `callback_generator_exec`
>>
>> On Fri, May 24, 2019 at 2:02 PM Bill Somerville <bill at classdesign.com> wrote:
>>
>> On 13/05/2019 12:03, Bill Somerville wrote:
>>
>> Hi folks,
>>
>> I am struggling to understand what the problem is with this:
>>
>> find_program (GO go)
>> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
>> file (MAKE_DIRECTORY ${GOPATH})
>>
>> set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
>> set (build_command ${GO} build)
>> set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
>> add_custom_command (OUTPUT ${output}
>>   COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} ${sources}
>>   DEPENDS ${sources}
>>   VERBATIM)
>> add_custom_target (callback_generator_target DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${output})
>> add_executable (callback_generator IMPORTED)
>> set_target_properties (callback_generator
>>   PROPERTIES
>>   IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
>>   )
>> add_dependencies (callback_generator callback_generator_target)
>>
>> add_custom_target (server ALL DEPENDS callback_generator)
>>
>> which gives this error:
>>
>> cmake --version
>>
>> cmake --version
>> cmake version 3.14.3
>>
>> cmake -G "MinGW Makefiles" ..\..
>>
>> cmake -G "MinGW Makefiles" ..\..
>> -- Configuring done
>> CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
>>   "callback_generator_target" of type UTILITY
>>     depends on "callback_generator_target" (strong)
>> The component contains at least one cycle consisting of strong dependencies (created by add_dependencies) that cannot be broken.
>>
>> The set_target_properties () call seems to be part of the problem but I don't understand why.
>>
>> Regards
>> Bill Somerville.
>>
>> Hi again,
>>
>> answering my own post since no one has replied. Clearly my question was too specific. Let me try again with a more general question. I have tools that can generate executables (programs, static libraries, and shared libraries, including DLL import libraries on MS Windows). These tools are not directly supported by CMake but they are both needed within a project that uses them and installs them as the project artefacts. How do I integrate, for example a shared library, into a CMake project as if it were produced by a supported toolchain like C or C++? The library is produced by an add_custom_target() command (not add_custom_command() since the underlying tools do their own dependency checking so it is right to run the target commands every build). I need to have a target that I can use in target_link_libraries() and install(TARGETS ...) just like one would with a CMake generated library made with add_library() and programs made with add_executable().
>>
>> If it helps the tools that are not supported by CMake are the Go language build tools. The project builds some Go programs as utilities but the main project artefact is a shared library with a C language API built using the cgo tools. There are many of C and C++ test programs and example programs as well in the project which need to link against the project shared library etc.
>>
>> Regards
>> Bill Somerville.
>>
>> --
>>
>> 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
>
>
>
> --
> Eric

From j.wuttke at fz-juelich.de  Mon May 27 11:51:54 2019
From: j.wuttke at fz-juelich.de (Joachim Wuttke)
Date: Mon, 27 May 2019 17:51:54 +0200
Subject: [CMake] how to link a test with library in build directory,
 not with installed version?
Message-ID: <38457f95-c93d-45e6-f0e4-117c86fb5030@fz-juelich.de>

How to link a test with a library as obtained in the build directory,
not with the installed version, which may be outdated?

Disclosure: cross-posted from https://stackoverflow.com/questions/56328326.

== Use case ==

Suppose

   cmake; make; ctest; make install

works fine:
- generates libA,
- runs testB,
- installs libA to ${CMAKE_INSTALL_LIBDIR}.

Now I modify libA, and rerun
   make; ctest.
No reaction to my modifications:
   ldd testB
shows that the installed version of libA is used.
Which is plain nonsense for a test.

The test should always use the local version of libA, never the installed one.

== Towards a solution ==

I saw a lot of advise that involves RPATH, but found no variant that helps.

So I hard-coded the path by changing
   target_link_libraries(testB PRIVATE A)
into
   target_link_libraries(testB PRIVATE ${CMAKE_BINARY_DIR}/lib/libA.so).

This works, but is no longer platform independent.
How to solve my problem in a way that also works under Windows?

- Joachim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5110 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://cmake.org/pipermail/cmake/attachments/20190527/2ea52c36/attachment.bin>

From aaron at assonance.org  Tue May 28 13:24:50 2019
From: aaron at assonance.org (Aaron Cohen)
Date: Tue, 28 May 2019 13:24:50 -0400
Subject: [CMake] how to link a test with library in build directory,
 not with installed version?
In-Reply-To: <38457f95-c93d-45e6-f0e4-117c86fb5030@fz-juelich.de>
References: <38457f95-c93d-45e6-f0e4-117c86fb5030@fz-juelich.de>
Message-ID: <CAFSZm+iNnFeNvBc1ggJfg0GkUuD+jrzJLST1m0re6xumB0T1kQ@mail.gmail.com>

For "modern cmake", you should:

1) When building libA:
a) Create an alias to your library (add_library A::A ALIAS A). This will
ensure that users are explicitly linking against a _target_ and not a file
named "libA" which just happens to match the name of the target you are
attempting to use.
b) Arrange that AConfig.cmake is installed to
/usr/lib/cmake/A/AConfig.cmake, which also exports an A::A target. This is
the "installed" version of the library, for consumers.

2) In your test CmakeLists, link against A::A rather than just A.

I believe that will work the way you want.

--Aaron

On Mon, May 27, 2019 at 11:58 AM Joachim Wuttke <j.wuttke at fz-juelich.de>
wrote:

> How to link a test with a library as obtained in the build directory,
> not with the installed version, which may be outdated?
>
> Disclosure: cross-posted from https://stackoverflow.com/questions/56328326
> .
>
> == Use case ==
>
> Suppose
>
>    cmake; make; ctest; make install
>
> works fine:
> - generates libA,
> - runs testB,
> - installs libA to ${CMAKE_INSTALL_LIBDIR}.
>
> Now I modify libA, and rerun
>    make; ctest.
> No reaction to my modifications:
>    ldd testB
> shows that the installed version of libA is used.
> Which is plain nonsense for a test.
>
> The test should always use the local version of libA, never the installed
> one.
>
> == Towards a solution ==
>
> I saw a lot of advise that involves RPATH, but found no variant that helps.
>
> So I hard-coded the path by changing
>    target_link_libraries(testB PRIVATE A)
> into
>    target_link_libraries(testB PRIVATE ${CMAKE_BINARY_DIR}/lib/libA.so).
>
> This works, but is no longer platform independent.
> How to solve my problem in a way that also works under Windows?
>
> - Joachim
>
> --
>
> 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/20190528/25517fb5/attachment.html>

From aaron at assonance.org  Tue May 28 13:28:05 2019
From: aaron at assonance.org (Aaron Cohen)
Date: Tue, 28 May 2019 13:28:05 -0400
Subject: [CMake] how to link a test with library in build directory,
 not with installed version?
In-Reply-To: <CAFSZm+iNnFeNvBc1ggJfg0GkUuD+jrzJLST1m0re6xumB0T1kQ@mail.gmail.com>
References: <38457f95-c93d-45e6-f0e4-117c86fb5030@fz-juelich.de>
 <CAFSZm+iNnFeNvBc1ggJfg0GkUuD+jrzJLST1m0re6xumB0T1kQ@mail.gmail.com>
Message-ID: <CAFSZm+jBAcwHDcAtBKqmxm-9o5dhA-LqGM9Par1KWTg7GG9_ag@mail.gmail.com>

On Tue, May 28, 2019 at 1:24 PM Aaron Cohen <aaron at assonance.org> wrote:

> b) Arrange that AConfig.cmake is installed to
> /usr/lib/cmake/A/AConfig.cmake, which also exports an A::A target. This is
> the "installed" version of the library, for consumers.
>

I was originally writing a longer answer and forgot to remove this part.
You don't actually need to create/install this file if you are just
concerned with testing within your project. (It's good to do in general,
it's just un-related to your question).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190528/a656cd66/attachment.html>

From zehner.paul at jaxa.jp  Wed May 29 02:20:57 2019
From: zehner.paul at jaxa.jp (=?iso-2022-jp?B?WmVobmVyGyRCISEbKEJQYXVs?=)
Date: Wed, 29 May 2019 06:20:57 +0000
Subject: [CMake] Support of compile features for Fujitsu C++ Compiler
In-Reply-To: <CANqUTaQD+13h1aoWwPYZrm_ZjyKP9w1FmS-L4=QwqBxsHY1BkQ@mail.gmail.com>
References: <TY2PR01MB49863699A339B13CB22F2CE5F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <AECD123B-8984-45E0-9282-225B3C672069@gmail.com>
 <TY2PR01MB4986915BBCF752F93552E091F43E0@TY2PR01MB4986.jpnprd01.prod.outlook.com>
 <CAFzjYVrxoN+4np2j=7s72v5rVTbEx4=rALiR94h7JxGAf+z77g@mail.gmail.com>
 <TY1PR01MB1883C4E63E86E85CB7C937E3F4320@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <CAFzjYVprAviPnT_uuphq=qTcxdoRaJeMANCxRcMqNfEPqoCJ2A@mail.gmail.com>
 <TY1PR01MB1883FA83D31C6111C15E1016F4330@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <CAFzjYVoNhiBP=WK+5OR_=KoQB0f0QoHE8Owz6WpspyvYt6Mqiw@mail.gmail.com>
 <TY1PR01MB1883067FEF7951468A372305F4080@TY1PR01MB1883.jpnprd01.prod.outlook.com>
 <TY1PR01MB188388875258DE7E27203A43F4020@TY1PR01MB1883.jpnprd01.prod.outlook.com>,
 <CANqUTaQD+13h1aoWwPYZrm_ZjyKP9w1FmS-L4=QwqBxsHY1BkQ@mail.gmail.com>
Message-ID: <TY1PR01MB18834BFB89DADB3A19F6C1A3F41F0@TY1PR01MB1883.jpnprd01.prod.outlook.com>

Dear all,

A naive grep tells me the IAR compiler detection sets CMAKE_CXX_LINK_FLAGS
in its compiler detection.

If I use `CMAKE_CXX_LINK_FLAGS`, I have to pass the option manually, which is not convenient. I was looking for something more automatic:

  1.  I set `cxx_std_14` in `target_compile_feature` of my `CMakeLists.txt`;
  2.  Then `CMAKE_CXX14_STANDARD_COMPILE_OPTION` is added to the compiler flags (which is the case);
  3.  Then `CMAKE_CXX14_STANDARD_LINK_OPTION` (or `CMAKE_CXX14_STANDARD_COMPILE_OPTION` by default) is added to the linker flags.

I cannot find in the documentation if such a thing is possible. Is it?

Best regards,


--

Paul Zehner, Ph. D.

Invited Researcher

Numerical Simulation Research Unit

Japan Aerospace Exploration Agency

7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo

182-8522, Japan

Tel. +81-50-3362-7933

Fax. +81-422-40-3327

zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp>

www.jaxa.jp<http://www.jaxa.jp>

________________________________
From: CMake <cmake-bounces at cmake.org> on behalf of Patrick Griffiths <patrick.griffiths at gmail.com>
Sent: Friday, May 24, 2019 21:09
To: cmake at cmake.org
Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler

A naive grep tells me the IAR compiler detection sets CMAKE_CXX_LINK_FLAGS
in its compiler detection. Maybe that'd work for you?


On Fri, May 24, 2019 at 3:48 AM Zehner Paul <zehner.paul at jaxa.jp> wrote:

> Hello all,
>
> So, I managed to configure my `Fujitsu-CXX.cmake` file to use the Fujitsu
> C++ compiler with MPI as well. The problem of not detecting headers of the
> STL (like `array`) was due to the fact the C++ standard flag was not set
> correctly.
>
> I am facing another problem though: the linker needs the C++ standard flag
> to be set, which is not something GCC needs. I could not find a way to make
> `CMAKE_CXX**_STANDARD_COMPILE_OPTION` applied to the linker as well. What I
> am missing?
>
> Best regards,
>
> --
>
> *Paul Zehner, Ph. D.*
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> *Japan Aerospace Exploration Agency*
>
> *7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo*
>
> *182-8522, Japan*
>
> *Tel. +81-50-3362-7933*
>
> *Fax. +81-422-40-3327*
>
> zehner.paul at jaxa.jp
>
> www.jaxa.jp<http://www.jaxa.jp>
> ------------------------------
> *From:* CMake <cmake-bounces at cmake.org> on behalf of Zehner Paul <
> zehner.paul at jaxa.jp>
> *Sent:* Tuesday, May 14, 2019 11:58
> *To:* Robert Maynard
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Support of compile features for Fujitsu C++
> Compiler
>
> Robert,
>
> so that all users could benefit from the improved compiler detection :)
> That is my plan! If I can make a compiler module which works well enough,
> I will submit it as a merge request.
>
> Regarding the detection of MPI with FindMPI, I failed to detect the MPI
> compiler using `MPI_CXX_COMPILER_FLAGS`. But using the normal Fujitsu
> compiler binary (not the wrapper) and setting `MPI_CXX_COMPILER`, I can
> detect it.
>
> The problem is now that it does not detect the STL anymore at compiling
> time: "error: namespace "std" has no member "array"" (note that I used to
> build the project with a hand made Makefile, so the source code is valid).
> I checked the `include` directory of the compiler and it contains the Array
> header, though. In other warnings, I clearly see that this `include`
> directory is used. What is wrong here?
>
> Best regards,
>
>
> --
>
> Paul Zehner, Ph. D.
>
> Invited Researcher
>
> Numerical Simulation Research Unit
>
> Japan Aerospace Exploration Agency
>
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
>
> 182-8522, Japan
>
> Tel. +81-50-3362-7933
>
> Fax. +81-422-40-3327
>
> zehner.paul at jaxa.jp<mailto:zehner.paul at jaxa.jp <zehner.paul at jaxa.jp>>
>
> www.jaxa.jp<http://www.jaxa.jp>
>
> ________________________________
> From: Robert Maynard <robert.maynard at kitware.com>
> Sent: Thursday, May 9, 2019 23:29
> To: Zehner Paul
> Cc: Kai Wolf; cmake at cmake.org
> Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
>
> The goal would be to upstream the compiler changes to cmake so that
> all users could benefit from the improved compiler detection :)
>
> I would look at the FindMPI docs on locating the correct mpi compiler:
>
> https://cmake.org/cmake/help/v3.14/module/FindMPI.html#variables-for-locating-mpi
> . It looks like what you will need to specify is
> MPI_<lang>_COMPILER_FLAGS
>
> On Wed, May 8, 2019 at 10:15 PM Zehner Paul <zehner.paul at jaxa.jp> wrote:
> >
> > Thank you for your answer.
> >
> > This means I have to override
> `/usr/share/cmake/Modules/Compiler/Fujitsu-DetermineCompiler.cmake`? This
> is not unfeasible, but it may seems tricky to my users. Since detecting
> compiler version is not a crucial task, maybe I will keep this file as it
> and concentrate on other ones.
> >
> > Another question I have is regarding MPI. The `find_package(MPI
> REQUIRED)` directive fails with "Could NOT find MPI (missing:
> MPI_CXX_FOUND)". I have no clue on how to help the detection of MPI. The
> compiler I give to CMake is actually an MPI wrapper that only needs one
> argument to enable MPI features. I tried with some exotic-named GCC
> compilers at my lab (which are MPI wrappers as well) and it could detect
> MPI with no problem. Where should I start?
> >
> > Best regards,
> >
> > --
> >
> > Paul Zehner, Ph. D.
> >
> > Invited Researcher
> >
> > Numerical Simulation Research Unit
> >
> > Japan Aerospace Exploration Agency
> >
> > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> >
> > 182-8522, Japan
> >
> > Tel. +81-50-3362-7933
> >
> > Fax. +81-422-40-3327
> >
> > zehner.paul at jaxa.jp
> >
> > www.jaxa.jp<http://www.jaxa.jp>
> >
> > ________________________________
> > From: Robert Maynard <robert.maynard at kitware.com>
> > Sent: Thursday, May 9, 2019 3:12
> > To: Zehner Paul
> > Cc: Kai Wolf; cmake at cmake.org
> > Subject: Re: [CMake] Support of compile features for Fujitsu C++ Compiler
> >
> > I believe the only way is to have your version of
> > Fujitsu-DetermineCompiler.cmake be installed over the one provided by
> > CMake. When it comes to known compilers CMake explicitly includes the
> > version it ships.
> >
> > On Tue, May 7, 2019 at 11:01 PM Zehner Paul <zehner.paul at jaxa.jp> wrote:
> > >
> > > Robert,
> > >
> > > Thank you for the advice.
> > >
> > > As I want to take account of compiler version, I overrided the
> `Fujitsu-DetermineCompiler.cmake` file by copy-pasting and editing it in
> the folder of `CMAKE_MODULE_PATH`. However, the installation
> `Fujitsu-DetermineCompiler.cmake` file is always used instead. What should
> I do?
> > >
> > > Best regards,
> > >
> > > --
> > >
> > > Paul Zehner, Ph. D.
> > >
> > > Invited Researcher
> > >
> > > Numerical Simulation Research Unit
> > >
> > > Japan Aerospace Exploration Agency
> > >
> > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > >
> > > 182-8522, Japan
> > >
> > > Tel. +81-50-3362-7933
> > >
> > > Fax. +81-422-40-3327
> > >
> > > zehner.paul at jaxa.jp
> > >
> > > www.jaxa.jp<http://www.jaxa.jp>
> > >
> > > ________________________________
> > > From: Robert Maynard <robert.maynard at kitware.com>
> > > Sent: Friday, April 26, 2019 23:32
> > > To: Zehner Paul
> > > Cc: Kai Wolf; cmake at cmake.org
> > > Subject: Re: [CMake] Support of compile features for Fujitsu C++
> Compiler
> > >
> > > For an initial implementation I would base the work on the PGI
> > > compiler module (
> > >
> https://gitlab.kitware.com/cmake/cmake/blob/v3.14.3/Modules/Compiler/PGI-CXX.cmake
> > > ) not the GNU-CXX module.
> > > This will allow you to add a new compiler with only meta-language
> > > flags ( cxx_std_11, cxx_std_14, ... ) and you avoid the complexity of
> > > having to manually build the feature tables.
> > >
> > > On Fri, Apr 26, 2019 at 3:58 AM Zehner Paul <zehner.paul at jaxa.jp>
> wrote:
> > > >
> > > > Kai,
> > > >
> > > >
> > > > Thanks for your answer and for your presentation. So, I will try to
> add support for this Fujitsu compiler. Is there a list of the common
> compile features that I can base me upon? I plan use `GNU-CXX.cmake` as a
> source of inspiration.
> > > >
> > > >
> > > > If I succeed to complete the `Fujitsu-CXX.cmake` file, I will
> propose it as a merge request.
> > > >
> > > >
> > > > --
> > > >
> > > > Paul Zehner, Ph. D.
> > > >
> > > > Invited Researcher
> > > >
> > > > Numerical Simulation Research Unit
> > > >
> > > > Japan Aerospace Exploration Agency
> > > >
> > > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > > >
> > > > 182-8522, Japan
> > > >
> > > > Tel. +81-50-3362-7933
> > > >
> > > > Fax. +81-422-40-3327
> > > >
> > > > zehner.paul at jaxa.jp
> > > >
> > > > www.jaxa.jp<http://www.jaxa.jp>
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: Kai Wolf <kai.wolf at gmail.com>
> > > > Sent: Friday, April 26, 2019 16:22
> > > > To: Zehner Paul
> > > > Cc: cmake at cmake.org
> > > > Subject: Re: [CMake] Support of compile features for Fujitsu C++
> Compiler
> > > >
> > > > If you want to add support to your specific compiler, you could add
> or extend another Fujitsu-DetermineCompiler.cmake
> > > > file and append your CMAKE_MODULE_PATH in order to CMake to find it.
> You probably also need to adjust
> > > > *Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.
> > > >
> > > > I gave a talk a few years ago that shortly explains the whole
> process of CMake initialization and compiler verification which
> > > > you can find here:
> https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
> > > >
> > > >
> > > > Greetings,
> > > >
> > > > Kai
> > > >
> > > > http://kai-wolf.me
> > > > http://effective-cmake.com
> > > >
> > > > Am 26.04.2019 um 07:35 schrieb Zehner Paul <zehner.paul at jaxa.jp>:
> > > >
> > > > Hello Cmake community,
> > > >
> > > > I would like to use Cmake to build research simulation programs in a
> Fujitsu supercomputer environment. Unfortunately, it seems that Cmake
> (version 3.14) does not support any compile feature for the Fujitsu C++
> compiler (FCCpx, version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I
> add I am pretty new to Cmake. Searching for similar issues, I found only
> this [thread](
> https://cmake.org/pipermail/cmake-developers/2014-August/010989.html),
> which talk about basic support of the compiler.
> > > >
> > > > I tested it on a simple project, and the line:
> > > >
> > > > ```cmake
> > > > target_compile_features(test PUBLIC cxx_std_11)
> > > > ```
> > > >
> > > > fails with this message:
> > > >
> > > > ```
> > > > CMake Error at CMakeLists.txt:15 (target_compile_features):
> > > >   target_compile_features no known features for CXX compiler
> > > >
> > > >   "Fujitsu"
> > > >
> > > >   version .
> > > >
> > > > ```
> > > >
> > > > So, it seems that the compiler is detected (without its version),
> but compile features are not known. To be sure, I ran this simple test to
> list any supported features:
> > > >
> > > > ```cmake
> > > > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> > > > project(foobar CXX)
> > > > message("Your C++ compiler supports these C++ features:")
> > > > foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> > > >     message("${i}")
> > > > endforeach()
> > > > ```
> > > >
> > > > and no feature are listed.
> > > >
> > > > So, what should I do from now on? Are there some people here using
> Cmake with Fujitsu who could help me? Should I propose a patch with the
> different compile features of the compiler? Or should I address it to
> Fujitsu?
> > > >
> > > > Thanks for your help,
> > > >
> > > > --
> > > > Paul Zehner, Ph. D.
> > > > Invited Researcher
> > > > Numerical Simulation Research Unit
> > > > Japan Aerospace Exploration Agency
> > > > 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> > > > 182-8522, Japan
> > > > Tel. +81-50-3362-7933
> > > > Fax. +81-422-40-3327
> > > > zehner.paul at jaxa.jp
> > > > www.jaxa.jp<http://www.jaxa.jp>
> > > > --
> > > >
> > > > 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
> > > >
> > > >
> > > > --
> > > >
> > > > 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
> --
>
> 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/20190529/6e13fe02/attachment-0001.html>

From hex7c3 at gmail.com  Wed May 29 06:11:10 2019
From: hex7c3 at gmail.com (hex)
Date: Wed, 29 May 2019 11:11:10 +0100
Subject: [CMake] hiding targets from cmake build?
Message-ID: <d8f7de18-888e-f0fc-6625-cef3ad73fc67@gmail.com>

In cmake mark_as_advanced will not display variables in any of the cmake 
GUIs unless the show advanced option is on.

I wonder if there is an equivalent for build targets?

I have a bunch of custom_targets custom_a, custom_b, custom_c, ... which 
all depend on custom_all

I don't want all targets to be listed in

cmake --build . --target help


It appears there is a solution for Visual Studio [1] by hiding folders. 
I am using SublimeText, though.

Is there a native solution? Otherwise approximately which steps should I 
take to make a script / plug-in.


[1]: https://stackoverflow.com/a/45918184/10530671


From sgiesecke at psi.de  Wed May 29 10:59:04 2019
From: sgiesecke at psi.de (Giesecke, Simon)
Date: Wed, 29 May 2019 14:59:04 +0000
Subject: [CMake] FindBoost / boost-cmake
Message-ID: <1034884301.2127.1559141945859.JavaMail.tbone@infra-bln-mcr1.psi.de>

Hi,

we are using the FindBoost module, and unfortunately it seems to be very slow under Windows. find_package(boost ...) is called at various places in imported projects with different COMPONENTS and each use takes about 30 seconds, causing the total CMake run to take up to 10 minutes.

In the documentation of FindBoost, it is mentioned that it can use a cmake configuration file BoostConfig.cmake if boost was built using boost-cmake, which we do not use at the moment. I can imagine that this would speed the process up, since the required information would not be need to determined during the CMake run. However, it is unclear what boost-cmake this refers to. Can someone provide a hint on where to find information on boost-cmake, and how to use it to build boost?

Best wishes

i.A. Simon Giesecke
Division Integrierte Versorger

PSI Software AG
Gesch?ftsbereich PSI Energie EE
Kurf?rstendamm 33
10719 Berlin
Deutschland/Germany
Telefon : +49 441 3612-4826
Telefax : +49 441 3612-6777
sgiesecke at psi.de
www.psi.de<http://www.psi.de/>
www.psienergy.de<http://www.psienergy.de/>

Sitz der Gesellschaft: Dircksenstra?e 42-44, 10178 Berlin, Deutschland
Mitglieder des Vorstands: Dr. Harald Schrimpf (Vorsitzender), Harald Fuchs
Vorsitzender des Aufsichtsrats: Karsten Trippel
Handelsregister Amtsgericht Berlin-Charlottenburg HRB 51 463

The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sgiesecke at psi.de-certificate-1.pem
Type: application/octet-stream
Size: 2321 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190529/3014a446/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3792 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190529/3014a446/attachment.bin>

From solipsis at pitrou.net  Wed May 29 15:32:32 2019
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 29 May 2019 21:32:32 +0200
Subject: [CMake] When CMake re-runs with Ninja on Windows,
 it switches to Debug build type
Message-ID: <20190529213232.75c2fa63@fsol>


Hello,

I am having a weird issue on Windows when Ninja is used as a generator.

As you can see below:
https://ci.appveyor.com/project/pitrou/arrow/build/job/owq89j34spl9hy4d#L584

the build is first configured in Release mode as requested on the
command-line.

But for some reason CMake decides to re-run itself (it thinks
CMAKE_CXX_COMPILER has changed, even though it hasn't) and switches the
build to Debug mode:
https://ci.appveyor.com/project/pitrou/arrow/build/job/owq89j34spl9hy4d#L839

What could be the reason the build type isn't kept the same?

Regards

Antoine.



From marc.herbert at gmail.com  Thu May 30 03:22:28 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Thu, 30 May 2019 00:22:28 -0700
Subject: [CMake] cmake rewrites part of -S argument depending on the current
 directory!
Message-ID: <CA+rkZbiKShT610dX56pnppODAFUKTF6Xvo=Mfa6p5=5YLRaBSw@mail.gmail.com>

Hi,

I discovered a very unexpected -S behaviour and I'd like to know whether
it's a bug or a feature.

IF the current directory is a parent of the -S argument AND one component
of the current directory is a symbolic link THEN the leading part of the -S
argument is overridden using that symbolic link.

I really didn't expect the current directory to be able to make any
difference to -S, especially not when passing absolute paths to both -B and
-S. I haven't found anything about that in the documentation.

Example:

ls ~/cmake/tu/to/rial
~/cmake/tu/to/rial/CMakeLists.txt
~/cmake/tu/to/rial/tutorial.cxx

ln -s ~/cmake/tu ~/tutosym
cd ~/tutosym

cmake -B ~/build -S ~/cmake/tu/to/rial

grep -r to/rial ~/build/
build/Makefile:CMAKE_SOURCE_DIR = ~/tutosym/to/rial       #  <= made up by
cmake
build/CMakeFiles/Makefile2:CMAKE_SOURCE_DIR = ~/tutosym/to/rial
build/CMakeCache.txt:Tutorial_SOURCE_DIR:STATIC=~/tutosym/to/rial
etc.

Funny enough the converse isn't true: if the current directory is a "real"
parent of the -S argument that has a symbolic link, then the -S argument is
respected. It's like symbolic links have a "higher priority" of some sort.

Example:

cd ~/cmake/
cmake -B ~/build -S ~/tutosym/to/rial

grep -r to/rial ~/build/
<exact same as above>

Is this behaviour intentional?

Reproduced with cmake 3.14.3.
-GNinja makes no difference.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190530/7163f528/attachment.html>

From brad.king at kitware.com  Thu May 30 10:16:11 2019
From: brad.king at kitware.com (Brad King)
Date: Thu, 30 May 2019 10:16:11 -0400
Subject: [CMake] cmake rewrites part of -S argument depending on the
 current directory!
In-Reply-To: <CA+rkZbiKShT610dX56pnppODAFUKTF6Xvo=Mfa6p5=5YLRaBSw@mail.gmail.com>
References: <CA+rkZbiKShT610dX56pnppODAFUKTF6Xvo=Mfa6p5=5YLRaBSw@mail.gmail.com>
Message-ID: <55824794-147d-7d18-2e1c-d6167599aa46@kitware.com>

On 5/30/19 3:22 AM, Marc Herbert wrote:
> IF the current directory is a parent of the -S argument AND
> one component of the current directory is a symbolic link THEN
> the leading part of the -S argument is overridden using that
> symbolic link.

See this issue:

  https://gitlab.kitware.com/cmake/cmake/issues/16228

-Brad

From benshadwick at gmail.com  Thu May 30 11:28:10 2019
From: benshadwick at gmail.com (Benjamin Shadwick)
Date: Thu, 30 May 2019 08:28:10 -0700
Subject: [CMake] CMake install doesn't find binary that CMake built?
Message-ID: <CADZYHDB0Vg57YqLF44K7ChHtFzqQFeVYyisDihUzdDmhw_egDg@mail.gmail.com>

Using CMake 3.12.2.

Consider the following project:

project(myproject)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_INSTALL_PREFIX "${CMAKE_BINARY_DIR}" CACHE PATH "" FORCE)
add_executable(myprog hello.cpp)
install(TARGETS myprog
   ARCHIVE DESTINATION lib
   LIBRARY DESTINATION lib
   RUNTIME DESTINATION bin)

'make install' builds 'myprog', then it disappears, then CMake reports an
error that it cannot find it ("file INSTALL cannot find
"path_to_build_directory/bin/myprog"").

Seems like a bug/oversight. Possibly CMake is trying to move the file to
where it already exists, destroying it in the process.

And since someone will be horrified at what I'm doing with paths, the
reason is that I've got subprojects that generate hundreds of libraries and
multiple executables, and I'd like to avoid both of the following:
- Forcing developers to run 'make install' instead of 'make' before they
can run
- Setting up massive PATH and LD_LIBRARY_PATH variables so that everything
can be found when it's scattered all over the build tree

I suppose my current setup will work fine as long as nobody uses 'make
install', but I was hoping to leverage that to help with release packaging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190530/9b80a08b/attachment.html>

From ggarra13 at gmail.com  Thu May 30 11:51:04 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Thu, 30 May 2019 12:51:04 -0300
Subject: [CMake] Cmake/Cpack creates a corrupt .rpm
Message-ID: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>

I have a CMakeLists.txt (extract) with the following commands:


SET(CPACK_GENERATOR DEB RPM TGZ )

# SET the installation directory.

SET(CPACK_SET_DESTDIR true) # Needed
SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})

SET(CPACK_RPM_PACKAGE_NAME mrViewer)
SET(CPACK_RPM_PACKAGE_RELOCATABLE false)


SET(? CPACK_RPM_POST_INSTALL_SCRIPT_FILE
 ??? ${PROJECT_BINARY_DIR}/etc/Linux/install.sh)
SET( CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
 ??? ${PROJECT_BINARY_DIR}/etc/Linux/uninstall.sh)


 ? SET(CPACK_PACKAGE_VENDOR "Film Aura, LLC")
 ? SET(CPACK_PACKAGE_VERSION_MAJOR ${VersionMajor})
 ? SET(CPACK_PACKAGE_VERSION_MINOR ${VersionMinor})
 ? SET(CPACK_PACKAGE_VERSION_PATCH ${VersionPatch})
 ? SET(CPACK_PACKAGE_VERSION "${SHORTVERSION}" )
 ? SET(CPACK_PACKAGE_FILE_NAME "${mrViewerPackageName}" )
 ? SET(CPACK_PACKAGE_CONTACT "ggarra13 at gmail.com")
 ? SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY
 ??? ? "mrViewer provides professional flipbook, audio and video playback.")


#SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} )
SET(CPACK_RESOURCE_FILE_LICENSE 
${PROJECT_SOURCE_DIR}/../../docs/LICENSE.txt)

SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" )
include(CPack)

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 creates a valid DEB file but an invalid RPM which fails with:

Running transaction
Preparing : 1/1
Running scriptlet: mrViewer-5.0.5.20190517-1.x86_64 1/1
Installing : mrViewer-5.0.5.20190517-1.x86_64 1/1
Error unpacking rpm package mrViewer-5.0.5.20190517-1.x86_64
error: unpacking of archive failed: cpio: read

Verifying : mrViewer-5.0.5.20190517-1.x86_64 1/1

Failed:
mrViewer-5.0.5.20190517-1.x86_64

Error: Transaction failed


You can find the RPM file here:

https://sourceforge.net/projects/mrviewer/files/v5.0.6/mrViewer-v5.0.6-Linux-64.rpm/download

If I use:

rpm -ql mrViewer-v5.0.6-Linux-64.rpm

all files are there.? However, when installing, the installer fails on 
reaching the lib directory of the rpm.

CMake/CPack used to build the rpm just fine some (long) versions ago 
with this same CMakeLists.txt.


-- 
Gonzalo Garramu?o


From ggarra13 at gmail.com  Thu May 30 12:00:26 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Thu, 30 May 2019 13:00:26 -0300
Subject: [CMake] Cmake/Cpack creates a corrupt .rpm
In-Reply-To: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>
References: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>
Message-ID: <1317eefa-4933-3284-2168-3eb9701cd066@gmail.com>


El 30/5/19 a las 12:51, Gonzalo Garramu?o escribi?:
> I have a CMakeLists.txt (extract) with the following commands:
>
>
> SET(CPACK_GENERATOR DEB RPM TGZ )
>
> # SET the installation directory.
>
> SET(CPACK_SET_DESTDIR true) # Needed
> SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})
>
> SET(CPACK_RPM_PACKAGE_NAME mrViewer)
> SET(CPACK_RPM_PACKAGE_RELOCATABLE false)
>
>
> SET(? CPACK_RPM_POST_INSTALL_SCRIPT_FILE
> ??? ${PROJECT_BINARY_DIR}/etc/Linux/install.sh)
> SET( CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
> ??? ${PROJECT_BINARY_DIR}/etc/Linux/uninstall.sh)
>
>
> ? SET(CPACK_PACKAGE_VENDOR "Film Aura, LLC")
> ? SET(CPACK_PACKAGE_VERSION_MAJOR ${VersionMajor})
> ? SET(CPACK_PACKAGE_VERSION_MINOR ${VersionMinor})
> ? SET(CPACK_PACKAGE_VERSION_PATCH ${VersionPatch})
> ? SET(CPACK_PACKAGE_VERSION "${SHORTVERSION}" )
> ? SET(CPACK_PACKAGE_FILE_NAME "${mrViewerPackageName}" )
> ? SET(CPACK_PACKAGE_CONTACT "ggarra13 at gmail.com")
> ? SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY
> ??? ? "mrViewer provides professional flipbook, audio and video 
> playback.")
>
>
> #SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} )
> SET(CPACK_RESOURCE_FILE_LICENSE 
> ${PROJECT_SOURCE_DIR}/../../docs/LICENSE.txt)
>
> SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" )
> include(CPack)
>
> 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 creates a valid DEB file but an invalid RPM which fails with:
>
> Running transaction
> Preparing : 1/1
> Running scriptlet: mrViewer-5.0.5.20190517-1.x86_64 1/1
> Installing : mrViewer-5.0.5.20190517-1.x86_64 1/1
> Error unpacking rpm package mrViewer-5.0.5.20190517-1.x86_64
> error: unpacking of archive failed: cpio: read
>
> Verifying : mrViewer-5.0.5.20190517-1.x86_64 1/1
>
> Failed:
> mrViewer-5.0.5.20190517-1.x86_64
>
> Error: Transaction failed
>
>
> You can find the RPM file here:
>
> https://sourceforge.net/projects/mrviewer/files/v5.0.6/mrViewer-v5.0.6-Linux-64.rpm/download 
>
>
> If I use:
>
> rpm -ql mrViewer-v5.0.6-Linux-64.rpm
>
> all files are there.? However, when installing, the installer fails on 
> reaching the lib directory of the rpm.
>
> CMake/CPack used to build the rpm just fine some (long) versions ago 
> with this same CMakeLists.txt.
>
Forgot to mention, I am using cmake 3.14.1.

-- 
Gonzalo Garramu?o


From marc.herbert at gmail.com  Thu May 30 13:25:21 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Thu, 30 May 2019 10:25:21 -0700
Subject: [CMake] cmake rewrites part of -S argument depending on the
 current directory!
In-Reply-To: <55824794-147d-7d18-2e1c-d6167599aa46@kitware.com>
References: <CA+rkZbiKShT610dX56pnppODAFUKTF6Xvo=Mfa6p5=5YLRaBSw@mail.gmail.com>
 <55824794-147d-7d18-2e1c-d6167599aa46@kitware.com>
Message-ID: <CA+rkZbg4DJ8OOnswxZT8m9N8Wpw2MXOOgEyDMFTeuYVzpy-HbQ@mail.gmail.com>

Thanks Brad for the reference, really appreciated. Some of 16228 seems
relevant. Other parts unfortunately not because 16228:
- tries to deal with all the crazy ways users can use symbolic links,
including relative paths and relative links,
- tries to deal with all the ways users can invoke cmake,
- naturally cares about backward compatibility,
- goes deep into the implementation details,
- refers to other issues with even more implementation details.

So I'm admittedly getting lost in all the details and combinatorial
explosion. Because 16228 looks like a bug I suspect the behaviour I
described is also considered a bug but I'm not even sure?

I believe the example I gave is one of the simplest and safest use cases of
symbolic links that : passing both -B and -S, no relative path, no relative
link. For such a "most explicit" use case, will future cmake versions be
unaffected by the current directory?

-B is a brand new option so there's only so much backward compatibility it
has to care about, right?

Long story short I think this admittedly complex topic could use some high
level documentation or - if the symlink situation is hopelessly complicated
and everything fails - at least a big "AVOID SYMLINKS [FOR NOW]" warning
somewhere in the documentation. Fair enough? Sorry if I missed that.

Thanks!

Marc


Le jeu. 30 mai 2019 ? 07:15, Brad King <brad.king at kitware.com> a ?crit :

> On 5/30/19 3:22 AM, Marc Herbert wrote:
> > IF the current directory is a parent of the -S argument AND
> > one component of the current directory is a symbolic link THEN
> > the leading part of the -S argument is overridden using that
> > symbolic link.
>
> See this issue:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16228
>
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190530/ed2687f6/attachment.html>

From brad.king at kitware.com  Thu May 30 13:37:16 2019
From: brad.king at kitware.com (Brad King)
Date: Thu, 30 May 2019 13:37:16 -0400
Subject: [CMake] cmake rewrites part of -S argument depending on the
 current directory!
In-Reply-To: <CA+rkZbg4DJ8OOnswxZT8m9N8Wpw2MXOOgEyDMFTeuYVzpy-HbQ@mail.gmail.com>
References: <CA+rkZbiKShT610dX56pnppODAFUKTF6Xvo=Mfa6p5=5YLRaBSw@mail.gmail.com>
 <55824794-147d-7d18-2e1c-d6167599aa46@kitware.com>
 <CA+rkZbg4DJ8OOnswxZT8m9N8Wpw2MXOOgEyDMFTeuYVzpy-HbQ@mail.gmail.com>
Message-ID: <f5bfb25b-b3c5-9720-7262-2bddcf44ae57@kitware.com>

On 5/30/19 1:25 PM, Marc Herbert wrote:
> I suspect the behaviour I described is also considered a bug

Yes, it is a bug and is related to 16228.  The problem is that
there is a poor implementation of support for the use case
described in that issue, and the details of that implementation
leak out in other use cases.

Ben (in Cc) has a plan to resolve the problem but hasn't had
time to implement it yet.

-Brad

From ggarra13 at gmail.com  Thu May 30 20:21:59 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Thu, 30 May 2019 21:21:59 -0300
Subject: [CMake] Cmake/Cpack creates a corrupt .rpm
In-Reply-To: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>
References: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>
Message-ID: <635942ee-eff7-9eaa-e107-551dd26bb2a4@gmail.com>


El 30/5/19 a las 12:51, Gonzalo Garramu?o escribi?:
> rpm -ql mrViewer-v5.0.6-Linux-64.rpm

If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm

I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot 
make mknod: the multibyte or extended character is incomplete or 
invalid, and attention: 4390 bytes of garbage skipped and header is 
reversed and type of archive unknown and premature end of the archive.

-- 
Gonzalo Garramu?o


From zlynx at acm.org  Thu May 30 20:36:57 2019
From: zlynx at acm.org (Zan Lynx)
Date: Thu, 30 May 2019 17:36:57 -0700
Subject: [CMake] Cmake/Cpack creates a corrupt .rpm
In-Reply-To: <635942ee-eff7-9eaa-e107-551dd26bb2a4@gmail.com>
References: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>
 <635942ee-eff7-9eaa-e107-551dd26bb2a4@gmail.com>
Message-ID: <1B1ABEB6-6044-4254-A105-2AB2E12BC7D1@acm.org>

On May 30, 2019 5:21:59 PM MST, "Gonzalo Garramu?o" <ggarra13 at gmail.com> wrote:
>
>El 30/5/19 a las 12:51, Gonzalo Garramu?o escribi?:
>> rpm -ql mrViewer-v5.0.6-Linux-64.rpm
>
>If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm
>
>I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot
>
>make mknod: the multibyte or extended character is incomplete or 
>invalid, and attention: 4390 bytes of garbage skipped and header is 
>reversed and type of archive unknown and premature end of the archive.

RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.
-- 
                Knowledge is Power -- Power Corrupts
                        Study Hard -- Be Evil

From ggarra13 at gmail.com  Thu May 30 21:16:14 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Thu, 30 May 2019 22:16:14 -0300
Subject: [CMake] Cmake/Cpack creates a corrupt .rpm
In-Reply-To: <1B1ABEB6-6044-4254-A105-2AB2E12BC7D1@acm.org>
References: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>
 <635942ee-eff7-9eaa-e107-551dd26bb2a4@gmail.com>
 <1B1ABEB6-6044-4254-A105-2AB2E12BC7D1@acm.org>
Message-ID: <c6055515-aa9e-fe9e-8f81-20cca35a0e4a@gmail.com>


El 30/5/19 a las 21:36, Zan Lynx escribi?:
> RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.

Thanks for that.? Using:

rpm2cpio mrViewer-v5.0.7-Linux-64.rpm | cpio -idmv

I can extract all the contents of the archive with no errors.

However, rpm -i bails out with a cpio: read error.? I don't know what to 
try next.? I have to wonder if the pre/post install scripts are the problem.


From mike.jackson at bluequartz.net  Fri May 31 10:14:29 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Fri, 31 May 2019 10:14:29 -0400
Subject: [CMake] CTest not exporting users HOME environment variable?
Message-ID: <F7D9B37C-7B31-4A41-9914-8424D531EBCF@bluequartz.net>

We have a program written in Fortran that asks for the user?s HOME environment variable. If I run the program from my typical terminal then I get what I would expect on macOS: /Users/mjackson, BUT if I run CTest to execute the program I get an empty HOME variable. Is there something special that needs to be done to ensure that CTest exports the HOME variable for the user running the test?

 

--

Michael Jackson | Owner, President

      BlueQuartz Software

[e] mike.jackson at bluequartz.net

[w] www.bluequartz.net

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

From starkd88 at gmail.com  Fri May 31 10:20:42 2019
From: starkd88 at gmail.com (David Starkweather)
Date: Fri, 31 May 2019 10:20:42 -0400
Subject: [CMake] ExternalProject_Add() Trouble Invoking Build Command to run
 the projects makefile
Message-ID: <CAGn2j6KSNxuOpBs0qjZ3q9Jdywa+Hrzdtoad2KePVGR3FT=hnQ@mail.gmail.com>

set(HIREDIS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis)
set(HIREDIS_INCLUDE_DIRS ${HIREDIS_DIR}/include)
ExternalProject_Add(hiredis
  URL https://github.com/redis/hiredis/archive/v0.9.0.tar.gz
  PREFIX ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  DOWNLOAD_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  BUILD_IN_SOURCE 1
  CONFIGURE_COMMAND ""
  BUILD_COMMAND make static
  INSTALL_COMMAND "")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190531/7652174a/attachment.html>

From starkd88 at gmail.com  Fri May 31 10:41:58 2019
From: starkd88 at gmail.com (David Starkweather)
Date: Fri, 31 May 2019 10:41:58 -0400
Subject: [CMake] ExternalProject_Add() setting build command to run external
 project's makefile
Message-ID: <CAGn2j6KLg+JjcgZrg42aXZv2kiVR39G-hPWV6_aHOVMuw=z1hw@mail.gmail.com>

Hello
First off, much thanks to all the contributors of cmake. A truly invaluable
build utility. Your efforts
are greatly appreciated.

I've been successfully using cmake to build an external project (the client
library for redis, hiredis)
that has already been downloaded. I was able to do this with
BUILD_IN_SOURCE set to true, like so:

ExternalProject_Add(hiredis
PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/hiredis
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis
BUILD_IN_SOURCE 1
CONFIGURE_COMMAND echo configure
BUILD_COMMAND make static
INSTALL_COMMAND echo install)

However, now i'd like to automatically download the source from github.
So, I switch to
the following:

set(HIREDIS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis)
set(HIREDIS_INCLUDE_DIRS ${HIREDIS_DIR}/include)
ExternalProject_Add(hiredis
  URL https://github.com/redis/hiredis/archive/v0.9.0.tar.gz
  PREFIX ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  DOWNLOAD_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
  BUILD_IN_SOURCE 1
  CONFIGURE_COMMAND ""
  BUILD_COMMAND make static
  INSTALL_COMMAND "")

*And I get the following error:*

[  3%] Creating directories for 'hiredis'
[  6%] Performing download step (download, verify and extract) for 'hiredis'
-- Downloading...
   dst='/home/david/projects/clipseekr/hiredis/v0.9.0.tar.gz'
   timeout='none'
-- Using src='https://github.com/redis/hiredis/archive/v0.9.0.tar.gz'
-- Downloading... done
-- extracting...
     src='/home/david/projects/clipseekr/hiredis/v0.9.0.tar.gz'
     dst='/home/david/projects/clipseekr/hiredis'
-- extracting... [tar xfz]
-- extracting... [analysis]
-- extracting... [rename]
-- extracting... [clean up]
-- extracting... done
make[2]: *** [CMakeFiles/hiredis.dir/build.make:93:
hiredis/src/hiredis-stamp/hiredis-download] Error 1
make[1]: *** [CMakeFiles/Makefile2:147: CMakeFiles/hiredis.dir/all] Error 2
make: *** [Makefile:163: all] Error 2

It seems cmake is trying to invoke its internal cmake make files, rather
than just run the "make static"
build command.  How do I just run the the "make static" command directly?

Once again, thanks.
starkdg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190531/786dac59/attachment.html>

From workbench at gmx.at  Fri May 31 12:53:18 2019
From: workbench at gmx.at (Steven Truppe)
Date: Fri, 31 May 2019 18:53:18 +0200
Subject: [CMake] Question about IF and STRINGS
Message-ID: <501485aa-ebca-758e-b79c-06115fe198b3@gmx.at>

Hi everyone,

i try to create a build system where you can decide which libraries you
want to use with variables like "WITH_LIB_GLFW" for example. every lib
variable has other variables like WITH_LIB_GLFW_INC_PATH,

WITH_LIB_GLFW_LIB_PATH, etc. so i can decide with cmake what libraries
i'm going to use for the final executable.

Now my problem is that i'm relative new to cmake and i'm learning c++11
in the meantime and are coding on a project so i don't have to much time
for cmake (but it's a realy important part).

Here is the code:

cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
include(CMakePrintHelpers)

set(WITH_LIB_GLAD "Support the GLAD library" 1)
set(WITH_LIB_GLFW "Support for the GLFW library" 1)

 ?macro(bsAddLibrary lib)
	# get all WITH_LIB varables

	get_cmake_property(_variables VARIABLES)
	foreach(_var ${_variables})
		#	cmake_print_variables(${_var})
		if(${_var} MATCHES "^WITH_LIB_[AZaz]+$" _lib)
			cmake_print_variables(${_lib})
		endif()
	endforeach()
endmacro()


bsAddLibrary(WITH_LIB_GLAD) # Adds WITH_LIB_GLAD_INC_PATH and the other variables to a list for the main application that holds all inc path, compiler flags etc.

 ?ERROR:
======

-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- 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
-- 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
CMake Error at CMakeLists.txt:15 (if):
   if given arguments:

     "CMAKE_AR" "MATCHES" "^WITH_LIB_[AZaz]+\$" "_lib"

   Unknown arguments specified
Call Stack (most recent call first):
   CMakeLists.txt:22 (bsAddLibrary)

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

From robert.maynard at kitware.com  Fri May 31 13:02:43 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 31 May 2019 13:02:43 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.14.5 available for download
Message-ID: <CAFzjYVoeZO3aGWEGRXuKEa4DVyhAnScxmgVHH=TAK+oW4amyXA@mail.gmail.com>

We are pleased to announce that CMake 3.14.5 is now available for download.

The Visual Studio 2019 16.1 update introduced a regression in MSBuild's
evaluation of custom command dependencies causing them to re-run on every build.
CMake 3.14.5 includes a workaround, for more details on the issue see:
  https://gitlab.kitware.com/cmake/cmake/issues/19303

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.14.5 since 3.14.4:

Alex Turbov (1):
  FindBoost: Add compiler features for Boost Contract library

Brad King (5):
  libarchive: avoid b64_encode name conflict with Solaris built-in function
  FindThreads: Drop incorrect docs about usage with C++
  Do not exclude include directories made implicit by CPATH
  VS: Isolate custom command input/output generation scopes
  CMake 3.14.5

Frans van Dorsselaer (2):
  VS: Clarify name of custom commands AdditionalInputs variable
  VS: De-duplicate custom command dependencies

From workbench at gmx.at  Fri May 31 13:07:45 2019
From: workbench at gmx.at (Steven Truppe)
Date: Fri, 31 May 2019 19:07:45 +0200
Subject: [CMake] Question about IF and STRINGS
In-Reply-To: <501485aa-ebca-758e-b79c-06115fe198b3@gmx.at>
References: <501485aa-ebca-758e-b79c-06115fe198b3@gmx.at>
Message-ID: <8c50d3a3-fd1c-deaf-39e0-d9ddb73832c2@gmx.at>

The problem is the line:

if(${_var} MATCHES "^WITH_LIB_([AZaz]+)$")
cmake_print_variables(CMAKE_MATCH_0)

doesn't print me any output ...


On 31.05.19 18:53, Steven Truppe wrote:
>
> Hi everyone,
>
> i try to create a build system where you can decide which libraries
> you want to use with variables like "WITH_LIB_GLFW" for example. every
> lib variable has other variables like WITH_LIB_GLFW_INC_PATH,
>
> WITH_LIB_GLFW_LIB_PATH, etc. so i can decide with cmake what libraries
> i'm going to use for the final executable.
>
> Now my problem is that i'm relative new to cmake and i'm learning
> c++11 in the meantime and are coding on a project so i don't have to
> much time for cmake (but it's a realy important part).
>
> Here is the code:
>
> cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
> include(CMakePrintHelpers)
>
> set(WITH_LIB_GLAD "Support the GLAD library" 1)
> set(WITH_LIB_GLFW "Support for the GLFW library" 1)
>
>  ?macro(bsAddLibrary lib)
> 	# get all WITH_LIB varables
>
> 	get_cmake_property(_variables VARIABLES)
> 	foreach(_var ${_variables})
> 		#	cmake_print_variables(${_var})
> 		if(${_var} MATCHES "^WITH_LIB_[AZaz]+$" _lib)
> 			cmake_print_variables(${_lib})
> 		endif()
> 	endforeach()
> endmacro()
>
>
> bsAddLibrary(WITH_LIB_GLAD) # Adds WITH_LIB_GLAD_INC_PATH and the other variables to a list for the main application that holds all inc path, compiler flags etc.
>
>  ?ERROR:
> ======
>
> -- The C compiler identification is GNU 6.3.0
> -- The CXX compiler identification is GNU 6.3.0
> -- 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
> -- 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
> CMake Error at CMakeLists.txt:15 (if):
>    if given arguments:
>
>      "CMAKE_AR" "MATCHES" "^WITH_LIB_[AZaz]+\$" "_lib"
>
>    Unknown arguments specified
> Call Stack (most recent call first):
>    CMakeLists.txt:22 (bsAddLibrary)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190531/e1e79da2/attachment.html>

From kyle.edwards at kitware.com  Fri May 31 13:31:59 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 31 May 2019 13:31:59 -0400
Subject: [CMake] Question about IF and STRINGS
In-Reply-To: <8c50d3a3-fd1c-deaf-39e0-d9ddb73832c2@gmx.at>
References: <501485aa-ebca-758e-b79c-06115fe198b3@gmx.at>
 <8c50d3a3-fd1c-deaf-39e0-d9ddb73832c2@gmx.at>
Message-ID: <1559323919.2964.5.camel@kitware.com>

On Fri, 2019-05-31 at 19:07 +0200, Steven Truppe wrote:
> The problem is the line:
> if(${_var} MATCHES "^WITH_LIB_([AZaz]+)$")
> cmake_print_variables(CMAKE_MATCH_0)
> 
> doesn't print me any output ...

There are two problems with the following line:

if(${_var} MATCHES "^WITH_LIB_([AZaz]+)$")

The first argument should be _var instead of ${_var}. See the if()
documentation for more information:

https://cmake.org/cmake/help/v3.14/command/if.html#variable-expansion

The second problem is your regex. I'm guessing you were trying to do:

^WITH_LIB_([A-Za-z]+)$

Notice the hyphens in the character class brackets. This will get you
every character from A to Z and from a to z. Using just [AZaz] will
only match A, Z, a, and z (none of the letters in between.)

So, if you use the following instead:

if(_var MATCHES "^WITH_LIB_([A-Za-z]+)$")
? cmake_print_variables(CMAKE_MATCH_0)

this should do what you want.

Kyle

From workbench at gmx.at  Fri May 31 13:32:17 2019
From: workbench at gmx.at (Steven Truppe)
Date: Fri, 31 May 2019 19:32:17 +0200
Subject: [CMake] Question about IF and STRINGS
In-Reply-To: <8c50d3a3-fd1c-deaf-39e0-d9ddb73832c2@gmx.at>
References: <501485aa-ebca-758e-b79c-06115fe198b3@gmx.at>
 <8c50d3a3-fd1c-deaf-39e0-d9ddb73832c2@gmx.at>
Message-ID: <4b30fdf9-f973-054e-e26e-9c8123c5bfc4@gmx.at>

Found the problem, my regex was wrong [AZaz] should be [A-Za-z] ...

On 31.05.19 19:07, Steven Truppe wrote:
>
> The problem is the line:
>
> if(${_var} MATCHES "^WITH_LIB_([AZaz]+)$")
> cmake_print_variables(CMAKE_MATCH_0)
>
> doesn't print me any output ...
>
>
> On 31.05.19 18:53, Steven Truppe wrote:
>>
>> Hi everyone,
>>
>> i try to create a build system where you can decide which libraries
>> you want to use with variables like "WITH_LIB_GLFW" for example.
>> every lib variable has other variables like WITH_LIB_GLFW_INC_PATH,
>>
>> WITH_LIB_GLFW_LIB_PATH, etc. so i can decide with cmake what
>> libraries i'm going to use for the final executable.
>>
>> Now my problem is that i'm relative new to cmake and i'm learning
>> c++11 in the meantime and are coding on a project so i don't have to
>> much time for cmake (but it's a realy important part).
>>
>> Here is the code:
>>
>> cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
>> include(CMakePrintHelpers)
>>
>> set(WITH_LIB_GLAD "Support the GLAD library" 1)
>> set(WITH_LIB_GLFW "Support for the GLFW library" 1)
>>
>>  ?macro(bsAddLibrary lib)
>> 	# get all WITH_LIB varables
>>
>> 	get_cmake_property(_variables VARIABLES)
>> 	foreach(_var ${_variables})
>> 		#	cmake_print_variables(${_var})
>> 		if(${_var} MATCHES "^WITH_LIB_[AZaz]+$" _lib)
>> 			cmake_print_variables(${_lib})
>> 		endif()
>> 	endforeach()
>> endmacro()
>>
>>
>> bsAddLibrary(WITH_LIB_GLAD) # Adds WITH_LIB_GLAD_INC_PATH and the other variables to a list for the main application that holds all inc path, compiler flags etc.
>>
>>  ?ERROR:
>> ======
>>
>> -- The C compiler identification is GNU 6.3.0
>> -- The CXX compiler identification is GNU 6.3.0
>> -- 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
>> -- 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
>> CMake Error at CMakeLists.txt:15 (if):
>>    if given arguments:
>>
>>      "CMAKE_AR" "MATCHES" "^WITH_LIB_[AZaz]+\$" "_lib"
>>
>>    Unknown arguments specified
>> Call Stack (most recent call first):
>>    CMakeLists.txt:22 (bsAddLibrary)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190531/79e19da8/attachment-0001.html>

From mellery451 at gmail.com  Fri May 31 13:52:19 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Fri, 31 May 2019 10:52:19 -0700
Subject: [CMake] ExternalProject_Add() setting build command to run
 external project's makefile
In-Reply-To: <CAGn2j6KLg+JjcgZrg42aXZv2kiVR39G-hPWV6_aHOVMuw=z1hw@mail.gmail.com>
References: <CAGn2j6KLg+JjcgZrg42aXZv2kiVR39G-hPWV6_aHOVMuw=z1hw@mail.gmail.com>
Message-ID: <BF0064FB-4068-4B4C-9423-AE4E6F07B49E@gmail.com>

It seems like the error might be related to the download/extract step. I think the fact that you are using the same dir for PREFIX, SOURCE_DIR and DOWNLOAD_DIR might be confusing things. I would try commenting out those three properties and see if it makes any difference, and then you can fine-tune those properties as needed once you get it working (maybe but just setting PREFIX).

-Mike

> On May 31, 2019, at 7:41 AM, David Starkweather <starkd88 at gmail.com> wrote:
> 
> Hello
> First off, much thanks to all the contributors of cmake. A truly invaluable build utility. Your efforts
> are greatly appreciated.
> 
> I've been successfully using cmake to build an external project (the client library for redis, hiredis) 
> that has already been downloaded. I was able to do this with BUILD_IN_SOURCE set to true, like so:
> 
> ExternalProject_Add(hiredis  
> PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/hiredis
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis
> BUILD_IN_SOURCE 1
> CONFIGURE_COMMAND echo configure
> BUILD_COMMAND make static
> INSTALL_COMMAND echo install)
> 
> 
> However, now i'd like to automatically download the source from github.  So, I switch to 
> the following:
> 
> set(HIREDIS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/hiredis)
> set(HIREDIS_INCLUDE_DIRS ${HIREDIS_DIR}/include)
> ExternalProject_Add(hiredis
>   URL https://github.com/redis/hiredis/archive/v0.9.0.tar.gz
>   PREFIX ${CMAKE_CURRENT_BINARY_DIR}/hiredis
>   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
>   DOWNLOAD_DIR ${CMAKE_CURRENT_BINARY_DIR}/hiredis
>   BUILD_IN_SOURCE 1
>   CONFIGURE_COMMAND ""
>   BUILD_COMMAND make static
>   INSTALL_COMMAND "")
> 
> And I get the following error:
> 
> [  3%] Creating directories for 'hiredis'
> [  6%] Performing download step (download, verify and extract) for 'hiredis'
> -- Downloading...
>    dst='/home/david/projects/clipseekr/hiredis/v0.9.0.tar.gz'
>    timeout='none'
> -- Using src='https://github.com/redis/hiredis/archive/v0.9.0.tar.gz'
> -- Downloading... done
> -- extracting...
>      src='/home/david/projects/clipseekr/hiredis/v0.9.0.tar.gz'
>      dst='/home/david/projects/clipseekr/hiredis'
> -- extracting... [tar xfz]
> -- extracting... [analysis]
> -- extracting... [rename]
> -- extracting... [clean up]
> -- extracting... done
> make[2]: *** [CMakeFiles/hiredis.dir/build.make:93: hiredis/src/hiredis-stamp/hiredis-download] Error 1
> make[1]: *** [CMakeFiles/Makefile2:147: CMakeFiles/hiredis.dir/all] Error 2
> make: *** [Makefile:163: all] Error 2
> 
> It seems cmake is trying to invoke its internal cmake make files, rather than just run the "make static"
> build command.  How do I just run the the "make static" command directly? 
> 
> Once again, thanks.
> starkdg
>  
>   
> -- 
> 
> 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  Fri May 31 14:43:46 2019
From: workbench at gmx.at (Steven Truppe)
Date: Fri, 31 May 2019 20:43:46 +0200
Subject: [CMake] Troubles with macros and STREQUAL
Message-ID: <ea332cb4-8b9c-e1d1-a9bc-7fbd5c8262fc@gmx.at>

cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
include(CMakePrintHelpers)



set(BSEDIT_INC_PATH "/usr/local/include")
set(BSEDIT_LIB_PATH "/usr/incude/lib")

set(WITH_LIB_GLAD "Support the GLAD library" 1)
set(LIB_GLAD_INC_PATH "/usr/include/glad")
set(LIB_GLAD_LIB_PATH "/usr/lib/glad")

set(WITH_LIB_GLFW "Support for the GLFW library" 1)


list(APPEND BSEDIT_INC_PATH ${LIB_GLAD_INC_PATH})


macro(bsAddLibrary lib)
 ??? # get all WITH_LIB varables
 ??? ??? message(STATUS "${lib}")

 ??? get_cmake_property(_variables VARIABLES)
 ??? foreach(_var ${_variables})

-->> (${lib} is "WITH_LIB_GLAD" but allways return false =( ?? ???
if(_var STREQUAL ${lib})
 ??? ??? ??? message(STATUS "Found library: ${_var}")
 ??? ??? ??? if(DEFINED ${${CMAKE_MATCH_0}_INC_PATH})
 ??? ??? ??? ??? message(STATUS "FOUND GLAD_INC_PATH")
 ??? ??? ??? endif()
 ??? ??? endif()
 ??? endforeach()
endmacro()


bsAddLibrary(WITH_LIB_GLAD)

message(STATUS "BSEDIT_INC_PATH = ${BSEDIT_INC_PATH}")
message(STATUS "BSEDIT_LIB_PATH = ${BSEDIT_LIB_PATH}")


From kyle.edwards at kitware.com  Fri May 31 14:51:50 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 31 May 2019 14:51:50 -0400
Subject: [CMake] Troubles with macros and STREQUAL
In-Reply-To: <ea332cb4-8b9c-e1d1-a9bc-7fbd5c8262fc@gmx.at>
References: <ea332cb4-8b9c-e1d1-a9bc-7fbd5c8262fc@gmx.at>
Message-ID: <1559328710.2964.6.camel@kitware.com>

On Fri, 2019-05-31 at 20:43 +0200, Steven Truppe wrote:
> macro(bsAddLibrary lib)
> ???? # get all WITH_LIB varables
> ???? ??? message(STATUS "${lib}")
> 
> ???? get_cmake_property(_variables VARIABLES)
> ???? foreach(_var ${_variables})
> 
> -->> (${lib} is "WITH_LIB_GLAD" but allways return false =( ?? ???
> if(_var STREQUAL ${lib})

Should be:

if(_var STREQUAL lib)

due to how if() expands variable references.

https://cmake.org/cmake/help/v3.14/command/if.html#variable-expansion

Kyle

From workbench at gmx.at  Fri May 31 16:11:29 2019
From: workbench at gmx.at (Steven Truppe)
Date: Fri, 31 May 2019 22:11:29 +0200
Subject: [CMake] Question about Variables
Message-ID: <67730461-b5b1-aa5f-be74-4b594e5ea066@gmx.at>

Hi everyone,

i'm relative new to cmake (a few weeks now) and i have the following
problem:


set(WITH_LIB_GLAD 1)

IF(DEFINED ${WITH_LIB_GLAD}_INC_PATH)

I try to check if the variable WITH_LIB_GLAD_INC_PATH can be found.


best regards!




From robert.maynard at kitware.com  Fri May 31 16:41:40 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 31 May 2019 16:41:40 -0400
Subject: [CMake] Question about Variables
In-Reply-To: <67730461-b5b1-aa5f-be74-4b594e5ea066@gmx.at>
References: <67730461-b5b1-aa5f-be74-4b594e5ea066@gmx.at>
Message-ID: <CAFzjYVrh49v6v4yzj8PaP2yNue99AaG+dWDHTUhDf=s4KjaQHw@mail.gmail.com>

The `${ }` syntax deferences the variable, so what you are asking is
if the variable `1_INC_PATH` exists.

What you want is `if(DEFINED WITH_LIB_GLAD_INC_PATH)` to check for the
existence of the variable `WITH_LIB_GLAD_INC_PATH`

On Fri, May 31, 2019 at 4:11 PM Steven Truppe <workbench at gmx.at> wrote:
>
> Hi everyone,
>
> i'm relative new to cmake (a few weeks now) and i have the following
> problem:
>
>
> set(WITH_LIB_GLAD 1)
>
> IF(DEFINED ${WITH_LIB_GLAD}_INC_PATH)
>
> I try to check if the variable WITH_LIB_GLAD_INC_PATH can be found.
>
>
> 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 ggarra13 at gmail.com  Fri May 31 21:56:40 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Fri, 31 May 2019 22:56:40 -0300
Subject: [CMake] Cmake/Cpack creates a corrupt .rpm
In-Reply-To: <c6055515-aa9e-fe9e-8f81-20cca35a0e4a@gmail.com>
References: <8a8d314d-80d7-890a-3c9a-08c1bc31e92f@gmail.com>
 <635942ee-eff7-9eaa-e107-551dd26bb2a4@gmail.com>
 <1B1ABEB6-6044-4254-A105-2AB2E12BC7D1@acm.org>
 <c6055515-aa9e-fe9e-8f81-20cca35a0e4a@gmail.com>
Message-ID: <9ec3bf7e-3121-45da-3602-520eee05d713@gmail.com>


El 30/5/19 a las 22:16, Gonzalo Garramu?o escribi?:
>
> El 30/5/19 a las 21:36, Zan Lynx escribi?:
>> RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.
>
> Thanks for that.? Using:
>
> rpm2cpio mrViewer-v5.0.7-Linux-64.rpm | cpio -idmv
>
> I can extract all the contents of the archive with no errors.
>
> However, rpm -i bails out with a cpio: read error.? I don't know what 
> to try next.? I have to wonder if the pre/post install scripts are the 
> problem.
>
Okay.? I found the root of the problem in the OS I was trying the RPM.? 
Fedora 30 has the problem installing.? CentOS 7, for example, works just 
fine.?? Not sure what has changed in Fedora (or if it ever worked on 
it).? Can someone confirm that their cmake .rpm's work in Fedora 30 
(thus, throwing my assumption out of the water)?

Thanks in advance.

-- 
Gonzalo Garramu?o