I require the syntax of a CMAKE macro that generates .cc and .h files from a tool like lex/yacc.
Could someone please show me the syntax for the following contrived example:
say I have a file y.cc that depends on x.cc and x.h, the two files mentioned are generated by tool z_tool from file x.z. What would the syntax for this be ?
For this example assume that y.cc will be turned into a static library, and as I am quite new to CMAKE the full CMakellist.txt for this contrived example would be very helpful.I'm looking for a portable solution as the tools I am using are available on windows as well as UNIX variants.
Rather than give you the answer to a contrived example, here is the way you would generate an executable using flex and bison
find_package(BISON)
find_package(FLEX)
BISON_TARGET(MyParser parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.cc)
FLEX_TARGET(MyScanner lexer.l ${CMAKE_CURRENT_BINARY_DIR}/lexer.cc)
ADD_FLEX_BISON_DEPENDENCY(MyScanner MyParser)
include_directories(${CMAKE_CURRENT_BINARY_DIR})
add_executable(Foo
Foo.cc
${BISON_MyParser_OUTPUTS}
${FLEX_MyScanner_OUTPUTS})
target_link_libraries(Foo ${FLEX_LIBRARIES} ${BISON_LIBRARIES})
The CMake find packages for bison/flex are included in the default installation, so this is cross platform.
In general to create an output that will later be used as an input you can use the add_custom_command function. If you use an output from the custom command as an input to a library or executable, then CMake knows to run your custom command before compiling the sources for the library/executable target.
The following line has Typo
FLEX_TARGET(MyScanner lexer.l ${CMAKE_CURRENT_BIANRY_DIR}/lexer.cc)
BIANRY should be spelled as BINARY.
Note: CMake Documentation has this typo there as well. ( in 2.8.0, this is fixed in 2.8.10 documentation)..
/* To make it work on my Mac with Lion. I changed the files names to y.tab.c and lex.yy.c, which are the output files if you run lex lex.l and yacc -D yacc.y from command line. See below.
*/
cmake_minimum_required(VERSION 2.8)
project (LexYacc)
find_package(BISON)
find_package(FLEX)
BISON_TARGET(MyParser yacc.y ${CMAKE_CURRENT_BINARY_DIR}/y.tab.c)
FLEX_TARGET(MyScanner lex.l ${CMAKE_CURRENT_BINARY_DIR}/lex.yy.c)
ADD_FLEX_BISON_DEPENDENCY(MyScanner MyParser)
include_directories(${CMAKE_CURRENT_BINARY_DIR})
add_executable(LexYacc
${BISON_MyParser_OUTPUTS}
${FLEX_MyScanner_OUTPUTS})
target_link_libraries(LexYacc ${FLEX_LIBRARIES} ${BISON_LIBRARIES})
Related
I am trying to generate documentation for my code using QDoc. qtdoc command is already in my environment variable path. But when I try to run the command in the root directory of the project (qdocconf file also resides in project root),
qdoc projectname.qdocconf
I get the following error
qt.qdoc: "qdoc can't run; no project set in qdocconf file"
Here is my projectname.qdocconf file.
headers.fileextensions = "*.h *.hpp"
sources.fileextensions = "*.cpp *.qml *.qdoc"
outputdir = Documentation/Code
headerdirs += Code
sourcedirs += . \
Code
exampledirs = .
imagedirs += ./Images/icons \
./Images/logos
I have commented on my class functions as described in the documentation using the format
/*!
* \fn void inlineFunction()
*
* Some info here...
*/
Can you point me what am I doing wrong?
Also, can I create the documentation using QtCreator instead of running the command in terminal?
Well somehow I figured out that you need to add the following line in your .qdocconf file
project = YourProjectName
which is not present in the minimum qdocconf file presented in https://doc.qt.io/qt-5/qdoc-minimum-qdocconf.html. Even though the above issue was resolved, a lot of other issues were encountered such as:
While compiling, qt.qdoc: No include paths passed to qdoc; guessing reasonable include paths. For this you have to manually include all the source paths. Read: https://bugreports.qt.io/browse/QTBUG-67289
Some comment tags, e.g. \return, \param, present in QtCreator are not recognized by QDoc
Option 2
Alternatively, look for Doxygen which is much easier to use and generate documents with a simple to use GUI. It also recognizes all the comment tags in QtCreator.
Update:
Doxygen plugins for Qt Creator doesn't work anymore as the support has expired. Use Doxygen GUI directly.
For running GNAT metric (for Windows, GPL 2017 or CE 2018) I'd like to include the RTL sources as well. There is a "-a" switch but it seems to be ineffective. When I'm forcing visibility of RTL sources, only ada.ads and system.ads are processed. Guessing it is a "crunched name" issue (RTL file names forced to 8 character names) I've tried other tricks without success.
My question is: is there a way to get the RTL source metrics (of the source files actually used) with GNAT Metric?
I'm using the command
gnatmetric -a -xs -nt -j0 -Pmyproj.gpr -U somemain.adb
TIA
In the meantime I've found a workaround by using the gnathtml.pl script.
I've customized the script a bit by removing the H1 headers.
The result is a few hundreds of HTML files with the sources of units actually used: the script does find all dependencies, recursively, through the .ali files - including the RTL.
Then I group the HTML files together, convert them back to text files, pass them through Adalog's Normalize tool for removing comments and empty lines, count lines with the wc command, and the job is done.
We need to (re)generated third party packages on EL7 but we don't want to change SPEC file as suggested (%define debug_package %{nil} https://www.redhat.com/archives/shrike-list/2003-April/msg00069.html) and neither changing the ~/.rpmmacros file as it is on a shared box for RPM build.
Is there any way to solve this via command line (additional parameter) with rpmbuild?
After many tests I found the solution. In fact, it is possible to define debug_package outside of the SPEC file, using --define. Which gives:
rpmbuild --define "debug_package %{nil}" -ba SPECS/original.spec
Result is: I don't modify the third party SPEC file and no RPM -debuginfo is generated.
rpmbuild --rebuild --nodebuginfo file.src.rpm -- this still generates debuginfo rpms
Another solution:
cat /etc/rpm/macros
%debug_package %{nil}
I'm (once again) struggling with the creation of precompiled headers in conjunction with gcc and Qt on the Apple platform.
When now creating my precompiled header I use a code section (based on good old "PCHSupport_26.cmake") to extract the compile flags as follows:
STRING(TOUPPER "CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}" _flags_var_name)
SET(_args ${CMAKE_CXX_FLAGS} ${${_flags_var_name}})
GET_DIRECTORY_PROPERTY(DIRINC INCLUDE_DIRECTORIES )
FOREACH(_item ${DIRINC})
LIST(APPEND _args "-I${_item}")
ENDFOREACH(_item)
GET_DIRECTORY_PROPERTY(_defines_global COMPILE_DEFINITIONS)
LIST(APPEND defines ${_defines_global})
STRING(TOUPPER "COMPILE_DEFINITIONS_${CMAKE_BUILD_TYPE}" _defines_for_build_name) GET_DIRECTORY_PROPERTY(defines_build ${_defines_for_build_name})
LIST(APPEND _defines ${_defines_build})
FOREACH(_item ${_defines})
LIST(APPEND _args "-D${_item}")
ENDFOREACH(_item ${_defines})
LIST(APPEND _args -c ${CMAKE_CURRENT_SOURCE_DIR}/${PRECOMPILED_HEADER} -o ${_gch_filename})
SEPARATE_ARGUMENTS(_args)
Unfortunately the above compiler flags miss two important parameter that CMake does generate when using the build-in compiler rules:
-DQT_DEBUG
and when compiling with the generated precompiled header, I get errors as follows:
file.h: not used because QT_DEBUG is defined.
I would need your help with the following:
Is the above way to retrieve the compiler flags correct ?
Is there a better, easier, simpler way to do this ?
Why does -DQT_DEBUG not show up in COMPILE_DEFINITIONS or COMPILE_DEFINITIONS_${CMAKE_BUILD_TYPE}
If you are using XCode simply:
SET_TARGET_PROPERTIES(${target} PROPERTIES XCODE_ATTRIBUTE_GCC_PRECOMPILE_PREFIX_HEADER YES)
SET_TARGET_PROPERTIES(${target} PROPERTIES XCODE_ATTRIBUTE_GCC_PREFIX_HEADER "${target}/std.h")
I'm trying myself to use precompiled headers with raw gcc on linux through CMake but I haven't still figured it out. It look like it's working but I don't see any speed improvements.
Edit:
I managed to use pch in gcc finally with the macro you can find here: http://www.mail-archive.com/cmake#cmake.org/msg04394.html
I'm busy porting my build process from msbuild to cmake, to better be able to deal with the gcc toolchain (which generates much faster code for some of the numeric stuff I'm doing).
Now, I'd like cmake to generate several versions of the output, stuff like one version with sse2, another with x64, and so on. However, cmake seems to work most naturally if you simply have a bunch of flags (say, "sse2_enable", and "platform") and then generate one output based on those platforms.
What's the best way to work with multiple output configurations like this? Intuitively, I'd like to iterate over a large number of flag combinations and rerun the same CMakeLists.txt files for each combination - but of course, you can't express that within the CMakeLists.txt files (AFAIK).
The recommended way to do this is to simply have multiple build directories. From each one you simply call cmake with the required settings.
For example you could do, starting in the base source directory (using Linux shell syntax but the idea is the same):
mkdir build-sse2 && cd build-sse2
cmake .. -DENABLE_SSE2 # or whatever to enable it in your CMakeLists.txt
make
cd ..
mkdir build-x64 && cd build-x64
cmake .. -DENABLE_X64 # or whatever again...
make
This way, each build directory is completely separated from each other.
This allows you to have one directory for Debug, another for Release and another for cross-compiling.
There hasn't been much activity here, so I've come up with a workable solution myself. It's probably not ideal, so if you have a better idea, please do add it!
Now, it's hard to iterate over build configs in cmake because cmake's crucial variables don't live in function scope - so, for instance, that means if you do include_directories(X) the X directory will remain in the include list even after the function exits.
Directories do have scope - and while normally each input directory corresponds to one output directory, you can have multiple output directories.
So, my solution looks like this:
project(FooAllConfigs)
set(FooVar 2)
set(FooAnotherVar b)
add_subdirectory("project_dir" "out-2b")
set(FooVar 5)
set(FooAnotherVar c)
add_subdirectory("project_dir" "out-5c")
set(FooVar 3)
set(FooAnotherVar b)
add_subdirectory("project_dir" "out-3b")
set(FooVar 3)
set(FooAnotherVar c)
add_subdirectory("project_dir" "out-3c")
The normal project dir then contains a CMakeLists.txt file with code to set up the appropriate includes and compiler options given the global variables set in the FooAllConfigs project, and it also determines a build suffix that's appended to all build outputs - any even indirectly included output (e.g. as generated by add_executable) must have a unique name.
This works fine for me.