[CMake] How to specify gfortran in an MSVC project
I would like to try to use 64-bit gfortran to compile a project in which the
rest of the code is compiled with Visual C++ 2017. I've read the netlib article
(http://www.netlib.org/lapack/lawnspdf/lawn270.pdf) but it doesn't address my
problem, which is how to help CMake select the right Fortran compiler. The
CMakeLists.txt file is launched from within Qt Creator.
My CMakeLists.txt file (which I've tested thoroughly using gfortran in Linux
and MinGW gfortran on Windows) begins:
cmake_minimum_required(VERSION 3.12)
project(myProj LANGUAGES Fortran)
...and if I set Qt Creator to parse it with the MSVC compiler option selected,
the output is:
Starting to parse CMake project, using:
"-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe",
"-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe",
"-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64",
"-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe".
The Fortran compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_Fortran_COMPILER could be found.
Tell CMake where to find the compiler by setting either the environment
variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
path to the compiler, or to the compiler name if it is in the PATH.
Fair enough; here's my second attempt:
cmake_minimum_required(VERSION 3.12)
set(CMAKE_Fortran_COMPILER "C:/Qt/Tools/mingw730_64/bin/gfortran.exe")
project(myProj LANGUAGES Fortran)
...and this gives me:
Starting to parse CMake project, using:
"-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe",
"-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe",
"-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64",
"-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe".
The Fortran compiler identification is unknown
Check for working Fortran compiler: C:/Qt/Tools/mingw730_64/bin/gfortran.exe
CMake Error: Error required internal CMake variable not set, cmake may not
be built correctly.
Missing variable is:
CMAKE_Fortran_PREPROCESS_SOURCE
CMake Error at C:/Program
Files/CMake/share/cmake-3.12/Modules/CMakeTestFortranCompiler.cmake:30
(try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
In place of the "set(CMAKE_Fortran_COMPILER..." line I've also tried
set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin/gfortran.exe")
...which gave me the error message
Could not find compiler set in environment variable FC:
CMAKE_Fortran_COMPILER-NOTFOUND
..and
set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin")
... which gave me exactly the same error as I got in the first case.
So what am I doing wrong here?
--
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] How to specify gfortran in an MSVC project
Thank you KT; let's see what they say. Like in your case, I have a project structure where my Fortran library depends on various C libraries, and my C++ application depends on those same C libraries both indirectly (through the Fortran library) and directly. I'd like to be able to use the MSVC versions of those C libraries (and as the interfaces are C, not C++, this ought to be straightforward). Currently, however, the only way I can get my Fortran code to compile is if I call it from the command line with the "MinGW Makefiles" generator, in which case it uses MinGW versions for all the other libraries as well. Warm regards, Stephen. From: Thompson, KT Sent: 14 January 2019 04:06 To: Stephen Morris ; cmake@cmake.org Subject: Re: How to specify gfortran in an MSVC project Hi Stephen, I am also interested in Kitware's response to your question. I don't use Qt Creator, but I help maintain several projects that use Visual Studio and MinGW gfortran via the CMakeAddFortranSubdirectory feature. This feature is somewhat limited and not really maintained (in my experience). Background: In my case, I use a heavily modified version of CMakeAddFortranSubdirectory that supports Xcode builds in addition to MSVC. I also have dependencies of the form mycpp.exe -> myf90.lib -> mycpp.lib -> msmpi.lib that standard CMakeAddFortranSubdirectory doesn't know how to deal with. When I run the 'build' target via Visual Studio, the Fortran compiler is discovered by CMakeAddFortranSubdirectory only if gfortran.exe is in %PATH% (via find_program -- I believe that the default code only supports the name 'gfortran.exe'.) You might need to add C:/Qt/Tools/mingw730_64/bin/ to your local path before running cmake for the project. I have found that CMakeAddFortranSubdirectory isn't flexible. You may need modify it for your own needs. -kt From: CMake mailto:cmake-boun...@cmake.org>> on behalf of Stephen Morris mailto:s-mor...@n-eos.com>> Sent: Sunday, January 13, 2019 6:14:33 PM To: cmake@cmake.org<mailto:cmake@cmake.org> Subject: [CMake] How to specify gfortran in an MSVC project I would like to try to use 64-bit gfortran to compile a project in which the rest of the code is compiled with Visual C++ 2017. I've read the netlib article (http://www.netlib.org/lapack/lawnspdf/lawn270.pdf) but it doesn't address my problem, which is how to help CMake select the right Fortran compiler. The CMakeLists.txt file is launched from within Qt Creator. My CMakeLists.txt file (which I've tested thoroughly using gfortran in Linux and MinGW gfortran on Windows) begins: cmake_minimum_required(VERSION 3.12) project(myProj LANGUAGES Fortran) ...and if I set Qt Creator to parse it with the MSVC compiler option selected, the output is: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown CMake Error at CMakeLists.txt:2 (project): No CMAKE_Fortran_COMPILER could be found. Tell CMake where to find the compiler by setting either the environment variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Fair enough; here's my second attempt: cmake_minimum_required(VERSION 3.12) set(CMAKE_Fortran_COMPILER "C:/Qt/Tools/mingw730_64/bin/gfortran.exe") project(myProj LANGUAGES Fortran) ...and this gives me: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown Check for working Fortran compiler: C:/Qt/Tools/mingw730_64/bin/gfortran.exe CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCE CMake Error at C:/Program Files/CMake/share/cmake-3.12/Modules/CMakeTestFortranCompiler.cmake:30 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): CMakeL
[CMake] Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc.
I’m trying to use the new VS_DEBUGGER_WORKING_DIRECTORY and VS_DEBUGGER_COMMAND properties to facilitate debugging in a CMake-generated Visual Studio project file (in my case Visual Studio 2013). Everything else in my configuration works except this… I’ve noted from ‘regular’ Visual Studio project files (i.e. ones not generated from CMake that, in the “Configuration Properties/Debugging” dialog, the ‘Command’ and ‘Working Directory’ fields are populated by default with $(TargetPath) and $(TargetDir) respectively. So in my CMakeLists.txt file, I have: set_target_properties(myApplication PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY "$(TargetDir)" VS_DEBUGGER_COMMAND"$(TargetPath)" VS_DEBUGGER_ENVIRONMENT "%PATH%;C:\\Qt\\5.9.7\\msvc2013_64\\bin") [In fact I've tried this with and without the quotes around $(TargetDir) and $(TargetPath) and the result is the same each time; they're absolutely necessary around the path.] What happens is that I then build the application, go to the “Configuration Properties/Debugging” dialog and verify that it looks exactly the same as a normal project file, with $(TargetDir) and $(TargetPath) appearing exactly where they should do. It doesn't work though; when I try to debug I get a message saying "Unable to start debugging. Check your debugger settings..." So I delete the text $(TargetDir) and $(TargetPath) from the dialog, then type them in again exactly as before: and then it works perfectly. What am I doing wrong? -- 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] Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc.
It turns out that the solution is to replace "$(TargetPath)" and "$(TargetDir)"
with the CMake generator expressions "`$`" and
"`$`", respectively, viz:
set_target_properties(myApplication PROPERTIES
VS_DEBUGGER_WORKING_DIRECTORY "$"
VS_DEBUGGER_COMMAND
"$"
VS_DEBUGGER_ENVIRONMENT
"PATH=%PATH%;${CMAKE_PREFIX_PATH}/bin")
From: Stephen Morris
Sent: 16 April 2019 17:36
To: cmake@cmake.org
Subject: Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc.
I’m trying to use the new VS_DEBUGGER_WORKING_DIRECTORY and VS_DEBUGGER_COMMAND
properties to facilitate debugging in a CMake-generated Visual Studio project
file (in my case Visual Studio 2013).
Everything else in my configuration works except this…
I’ve noted from ‘regular’ Visual Studio project files (i.e. ones not generated
from CMake that, in the “Configuration Properties/Debugging” dialog, the
‘Command’ and ‘Working Directory’ fields are populated by default with
$(TargetPath) and $(TargetDir) respectively. So in my CMakeLists.txt file, I
have:
set_target_properties(myApplication PROPERTIES
VS_DEBUGGER_WORKING_DIRECTORY "$(TargetDir)"
VS_DEBUGGER_COMMAND"$(TargetPath)"
VS_DEBUGGER_ENVIRONMENT
"%PATH%;C:\\Qt\\5.9.7\\msvc2013_64\\bin")
[In fact I've tried this with and without the quotes around $(TargetDir) and
$(TargetPath) and the result is the same each time; they're absolutely
necessary around the path.]
What happens is that I then build the application, go to the “Configuration
Properties/Debugging” dialog and verify that it looks exactly the same as a
normal project file, with $(TargetDir) and $(TargetPath) appearing exactly
where they should do. It doesn't work though; when I try to debug I get a
message saying "Unable to start debugging. Check your debugger settings..."
So I delete the text $(TargetDir) and $(TargetPath) from the dialog, then type
them in again exactly as before: and then it works perfectly.
What am I doing wrong?
--
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] Preventing multiple definitions of metaObject methods
Suppose I have a class that derives from QObject, and contains the Q_OBJECT macro in its header file. When I compile it using AUTOMOC enabled, a "moc_myClass.cpp" file is created; if I manually include that file at the end of my 'myClass.cpp" file, then the moc file will be compiled there, otherwise CMake will take matters into its own hands and compile it anyway. Now suppose make my class into a static library. The static library now contains the object code generated when moc_myClass.cpp was compiled. I now include my static library from an application. Unless I enable AUTOMOC again, then I get a compilation error when Q_OBJECT is encountered. If I do enable it, then CMake generates a new moc_myClass.cpp file and, since it can't see the place where it was included in myClass.cpp, it goes ahead and recompiles it, placing the object code alongside the application's other object code. Now, when the application links in the static library, it finds two definitions of moc_myClass.cpp's object code, and gives a multiple definition error. All the ways I've come up with so far to work around this are so hacky that I'm embarrassed to mention them. There must be a proper way to handle this situation. Please can someone advise me what it is? (N.B. I've been doing this for years with dynamic libraries are never encountered a problem, presumably because there the application doesn't get to see the inner workings of the library's object code. This issue does seem to be specific to static libraries, of which I have little prior experience). -- 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] Preventing multiple definitions of metaObject methods
-Original Message- From: Kyle Edwards Sent: 13 September 2019 16:54 To: Stephen Morris ; cmake@cmake.org Subject: Re: [CMake] Preventing multiple definitions of metaObject methods >Stephen, >Could you post a minimally reproducible example with CMakeLists.txt and >accompanying source code? I am currently working on a Qt-based >project with >static libraries and have not encountered this issue. >Kyle Thank you Kyle. I created a basic example as you suggested - a simple application linking a simple static library, both incorporating a header containing Q_OBJECT - and to my great chagrin it worked perfectly, without any compilation errors. So it seems that I've been wrong to suspect this as the cause of the multiple-definition errors in my main project. Clearly I must dig deeper, and if I find that the final explanation is of general interest then I shall report back. Stephen. -- 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] Preventing multiple definitions of metaObject methods
-Original Message-
From: Kyle Edwards
Sent: 13 September 2019 16:54
To: Stephen Morris ; cmake@cmake.org
Subject: Re: [CMake] Preventing multiple definitions of metaObject methods
>Stephen,
>Could you post a minimally reproducible example with CMakeLists.txt and
>accompanying source code? I am currently working on a Qt-based >project with
>static libraries and have not encountered this issue.
>Kyle
It appears that the problem was due to a misunderstanding about how the PRIVATE
keyword works in tergat_sources. I'd assumed that it should be used to identify
the 'public headers' of a library (i.e. headers that should be included by the
consumers of that library. It seems that this isn't the case, and even 'public'
headers should be defined with the PRIVATE keyword.
Here are the simple demonstration files I wrote, four in all:
myTest.h
#ifndef MYTEST_HDR
#define MYTEST_HDR
class myTestWindow : public QMainWindow
{
Q_OBJECT
public:
myTestWindow()
virtual ~myTestWindow();
signals:
void readyToDisplay();
private slots:
void showTitle();
};
#endif
myTest.cpp
#include
#include
#include "myTest.h"
myTestWindow::myTestWindow() : QMainWindow(nullptr)
{
// Send the signal when ready to display
(QTimer::singleShot(0, this, ::showTitle));
}
myTestWindow::~myTestWindow()
{}
void myTestWindow::showTitle()
{
setWindowTitle(tr("This is a test window"));
}
#include "moc_myTest.cpp"
main.cpp
#include
#include
#include "myTest.h"
int main(int argc, char *argv[])
{
QApplication * app = new QApplication (argc, argv);
myTestWindow * win = new myTestWindow();
win->show();
app->exec();
return 0;
}
CMakeLists.txt
cmake_minimum_required (VERSION 3.14)
project(myTest LANGUAGES CXX)
find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED PATHS
"C:\\Qt\\5.12.3\\msvc2017_64\\lib\\cmake\\Qt5" NO_DEFAULT_PATH)
set (CMAKE_AUTOMOC ON)
set (CMAKE_AUTORCC ON)
set (CMAKE_AUTOUIC ON)
add_library(myTest_Lib STATIC)
target_sources(myTest_Lib PRIVATE myTest.cpp)
target_sources(myTest_Lib PUBLIC myTest.h)
target_link_libraries(myTest_Lib PUBLIC Qt5::Core Qt5::Widgets)
set_target_properties(myTest_Lib PROPERTIES OUTPUT_NAME myTest)
add_executable(myTest_Exe main.cpp)
target_include_directories(myTest_Exe PRIVATE ${CMAKE_LIST_DIR})
target_link_libraries(myTest_Exe PRIVATE myTest_Lib)
set_target_properties(myTest_Exe PROPERTIES OUTPUT_NAME myTest
VS_DEBUGGER_ENVIRONMENT "PATH=C:\\Qt\\5.12.3\\msvc2017_64\\bin;%PATH%")
Compiling and running them as given here, with the line
"target_sources(myTest_Lib PUBLIC myTest.h)" in the MakeLists.txt file, my
library compiles cleanly but I get an error saying "'QMainWindow': base class
undefined" when trying to compile the executable application. This is because
the compiler encounters the Q_OBJECT macro in myTest.h, generates a new
moc_myTest.cpp, then because it can't see that the original moc_myTest.cpp was
compiled within the library it includes it in its own mocs_compilation.cpp
file. The error occurs when trying to compile this file, since moc_myTest.cpp
does not include anywhere.
If I try to fix this by adding the line "#include " just
above the class declaration in myTest.h, then the error changes to a bunch of
'multiple definition' errors, as I reported in my original question on Friday.
However, if I just change "target_sources(myTest_Lib PUBLIC myTest.h)" to
"target_sources(myTest_Lib PRIVATE myTest.h)", then all the problems go away;
it doesn't even matter whether I leave the redundant '#include' in myTest.h,
everything compiles cleanly either way.
It seems that the matter of static vs. shared libraries in my initial question
was a red herring - in my previous work with shared libraries I haven't used
either the PUBLIC or PRIVATE keywords, but merely supplied add_library with a
list of undifferentiated source files. This problem turns out to have been
entirely a matter of the use of the PUBLIC keyword. I have obviously been using
it incorrectly, though this leads me to wonder what its purpose is, if not for
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] Stray backslash appearing when CMAKE_CXX_FLAGS_RELEASE used in custom command
On 4 November at 08:43, Eric Doenges wrote:
> Welcome to the wonderful world of lists and their interaction with quoting in
> CMake ! Since space is used
> as a list item separator outside of double quoted strings, CMake is escaping
> the space within CXX_FLAGS
> to keep it as a single element within the list of arguments passed to
> add_custom_command. To avoid this,
> you need to turn CXX_FLAGS into a list prior to using it in
> add_custom_command:
>
>string(REGEX REPLACE " " ";" CXX_FLAGS "${CXX_FLAGS}")
>
>Of course, this will not work if you want to pass a double quoted string as an
>actual command line argument ...
Thank you! I'd never have worked this out for myself, though it makes perfect
sense now you've explained it.
Thank you for answering my other question about -fPIC -std=gnu++17 as well.
--
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] Accessing -fPIC and -std settings within CMake definitions
I'm setting up a custom build step to build a precompiled header in gcc (yes I
know that native support is coming with CMake 3.16, but I need to get something
working on an older version).
My approach is basically to set up a custom command thus:
set_target_properties(mytarget PRIVATE CXX_STANDARD 17)
set_target_properties(mytarget PRIVATE POSITION_INDEPENDENT CODE_1)
set(CMAKE_VERBOSE_MAKEFILE TRUE)
...
...
set(CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG}) .. or whatever,
depending on the current configuration..
get_target_property(compile_options, mytarget, COMPILE_OPTIONS)
add_custom_command(OUTPUT myheader.h.gch
COMMAND ${CMAKE_CXX_COMPILER}
${CXX_FLAGS} ${compile_options} -fPIC -std=gnu++17 -c myheader.h -o
myheader.h.gch
DEPENDS myheader.h)
add_custom_target(BuildMyPCH
DEPENDS myheader.h.gch)
add_dependencies(mytarget, BuildMyPCH)
You'll note that in my custom command I've had to specify -fPIC and
-std-gnu++17 explicitly, because they aren't included among either CXX_FLAGS or
COMPILE_OPTIONS. I've looked for them among the COMPILE_DEFINITIONS,
COMPILE_FEATURES and COMPILE_FLAGS properties of my target as well, but there's
no sign of them. And yet if I look at the verbose output when gcc builds other
files using the CMake-generated makefile, I see that they are being included
automatically.
So, my question: where is CMake storing these settings, and how can I apply
them in my custom command without having to do so manually?
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] Stray backslash appearing when CMAKE_CXX_FLAGS_RELEASE used in custom command
On 1 November at 10:02, Stephen Morris wrote:
> My approach is basically to set up a custom command thus:
> set(CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG}) .. or whatever,
> depending on the current configuration..
> get_target_property(compile_options, mytarget, COMPILE_OPTIONS)
> add_custom_command(OUTPUT myheader.h.gch
> COMMAND ${CMAKE_CXX_COMPILER}
> ${CXX_FLAGS} ${compile_options} -fPIC -std=gnu++17 -c myheader.h -o
> myheader.h.gch
> DEPENDS myheader.h)
> add_custom_target(BuildMyPCH
> DEPENDS myheader.h.gch)
> add_dependencies(mytarget, BuildMyPCH)
My earlier question still stands, but at the time I wrote it I had only tested
it for Debug builds where ${CMAKE_CXX_FLAGS_DEBUG} consisted of a single item,
'-g'.
I've since tried doing the same thing for a Release build, and this failed
because ${CMAKE_CXX_FLAGS_RELEASE} has two items, '-O3 -DNDEBUG'. When the
custom command is executed, this somehow becomes "-O3\ -DNDEBUG" on the command
line, and the presence of the stray backslash causes the compilation to fail
with the message,
"cc1plus: error: argument to '-O' should be a non-negative integer. 'g', 's' or
'fast'"
So why isn't the cmake variable placed properly onto the command line, and what
can I do to prevent this behaviour?
--
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] find_package to find Cygwin versions of Flex and Bison in Windows
To compile my application I need to use the Flex and Bison applications. To compile under Linux, all I need to do in my CMakeLists.txt file to find them is find_package(FLEX REQUIRED) find_package(BISON REQUIRED) ...and everything works as expected. In Windows, however, I'm using the Cygwin versions of Flex and Bison which are installed in C:\cygwin64\bin. This doesn't seem to be on the path that find_package searches in Module Mode, so the search returns unsuccessfully. However, if I try to tell find_package where to look, viz. find_package(FLEX REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH) find_package(BISON REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH) ...then by adding the PATHS keyword I've invoked Config mode and I get an error message saying: Could not find a package configuration file provided by "FLEX" with any of the following names FLEXConfig.cmake flex-config.cmake ...because sure enough Cygwin does not provide these files. So what can I do? Ideally I'd like to use Module Mode but provide a path hint; but there seems no way to do that. At the moment I can only think of: (a) Hard-coding add_custom_target commands to invoke flex and bison entirely manually when they're needed, or (b) Writing my own FLEXConfig.cmake and BISONConfig.cmake files for use in Config Mode. Both of these seem disproportionately difficult for what seems to me like it ought to be a common and simple problem. So is there a better solution that I'm missing? -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] find_package to find Cygwin versions of Flex and Bison
Thank you; prepending C:/cygwin64/bin To CMAKE_PROGRAM_PATH was all I needed to do to fix the problem. -Original Message- Date: Thu, 5 Mar 2020 14:28:27 +0100 From: Eric Doenges You can prepend C:\cygwin64\bin to the CMAKE_PROGRAM_PATH variable so that it looks there first.? While the find_package documentation does not mention CMAKE_PROGRAM_PATH, I know this works for bison and flex because that is what we do in our project (presumably, find_program is used internally within the find_package, explaining why CMAKE_PROGRAM_PATH is considered). You could also try setting the FLEX_ROOT and BISON_ROOT variables to C:\cygwin64\bin or perhaps C:\cygwin64. According to the find_package documentation, this should allow you to set the search location on a per-package basis. However, I have not had this work for me, so your mileage may vary. Am 05.03.20 um 12:12 schrieb Stephen Morris: > To compile my application I need to use the Flex and Bison > applications. To compile under Linux, all I need to do in my > CMakeLists.txt file to find them is > > find_package(FLEX REQUIRED) > find_package(BISON REQUIRED) > > ...and everything works as expected. > > In Windows, however, I'm using the Cygwin versions of Flex and Bison which > are installed in C:\cygwin64\bin. This doesn't seem to be on the path that > find_package searches in Module Mode, so the search returns unsuccessfully. > > However, if I try to tell find_package where to look, viz. > > find_package(FLEX REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH) > find_package(BISON REQUIRED PATHS C:/cygwin64/bin > NO_DEFAULT_PATH) > > ...then by adding the PATHS keyword I've invoked Config mode and I get an > error message saying: > > Could not find a package configuration file provided by "FLEX" with any > of > the following names > > FLEXConfig.cmake > flex-config.cmake > > ...because sure enough Cygwin does not provide these files. > > So what can I do? Ideally I'd like to use Module Mode but provide a path > hint; but there seems no way to do that. > > At the moment I can only think of: > (a) Hard-coding add_custom_target commands to invoke flex and bison > entirely manually when they're needed, or > (b) Writing my own FLEXConfig.cmake and BISONConfig.cmake files for use in > Config Mode. > > Both of these seem disproportionately difficult for what seems to me like it > ought to be a common and simple problem. So is there a better solution that > I'm missing? > *Dr. Eric D?nges* Senior Software Engineer MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doen...@mvtec.com <mailto:doen...@mvtec.com> | Tel: +49 89 457 695-0 | www.mvtec.com <http://www.mvtec.com> Find our privacy policy here <https://www.mvtec.com/imprint>. Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter! -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
