date:20190524

Re: [CMake] Manually-specified variables were not used by the project

2019-05-24 Thread Alan W. Irwin


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@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@merlin> cmake -P /tmp/CMakeLists.txt 
-- MY_VAR is not DEFINED
irwin@merlin> cmake -DMY_VAR=OFF -P /tmp/CMakeLists.txt 
-- MY_VAR is DEFINED
irwin@merlin> cmake -DMY_VAR=ON -P /tmp/CMakeLists.txt 
-- MY_VAR is DEFINED


So just like the documentation says at 

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
__
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Dependency cycle - why?

2019-05-24 Thread Robert Maynard via CMake

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  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-

Re: [CMake] Dependency cycle - why?

2019-05-24 Thread Bill Somerville

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

[CMake] Manually-specified variables were not used by the project

2019-05-24 Thread Haio Maio

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 ?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Support of compile features for Fujitsu C++ Compiler

2019-05-24 Thread Patrick Griffiths

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  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.p...@jaxa.jp
>
> www.jaxa.jp
> --
> *From:* CMake  on behalf of Zehner Paul <
> zehner.p...@jaxa.jp>
> *Sent:* Tuesday, May 14, 2019 11:58
> *To:* Robert Maynard
> *Cc:* cmake@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.p...@jaxa.jp
>
> www.jaxa.jp
>
> 
> From: Robert Maynard 
> Sent: Thursday, May 9, 2019 23:29
> To: Zehner Paul
> Cc: Kai Wolf; cmake@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__COMPILER_FLAGS
>
> On Wed, May 8, 2019 at 10:15 PM Zehner Paul  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.p...@jaxa.jp
> >
> > www.jaxa.jp
> >
> > 
> > From: Robert Maynard 
> > Sent: Thursday, May 9, 2019 3:12
> > To: Zehner Paul
> > Cc: Kai Wolf; cmake@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  wrote:
> > >
> > > Robert,
> > >
> > > Thank you for the advice.
> > >
> > > As I want to take account of compiler version, I overrided the
> `

Re: [CMake] Support of compile features for Fujitsu C++ Compiler

2019-05-24 Thread Zehner　Paul

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.p...@jaxa.jp

www.jaxa.jp

From: CMake  on behalf of Zehner　Paul 

Sent: Tuesday, May 14, 2019 11:58
To: Robert Maynard
Cc: cmake@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.p...@jaxa.jp

www.jaxa.jp

From: Robert Maynard 
Sent: Thursday, May 9, 2019 23:29
To: Zehner　Paul
Cc: Kai Wolf; cmake@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__COMPILER_FLAGS

On Wed, May 8, 2019 at 10:15 PM Zehner　Paul  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.p...@jaxa.jp
>
> www.jaxa.jp
>
> 
> From: Robert Maynard 
> Sent: Thursday, May 9, 2019 3:12
> To: Zehner　Paul
> Cc: Kai Wolf; cmake@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  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 Jinda

Re: [CMake] Manually-specified variables were not used by the project

Re: [CMake] Dependency cycle - why?

Re: [CMake] Dependency cycle - why?

[CMake] Manually-specified variables were not used by the project

Re: [CMake] Support of compile features for Fujitsu C++ Compiler

Re: [CMake] Support of compile features for Fujitsu C++ Compiler

6 matches

Site Navigation

Mail list logo

Footer information