I need to dynamically generate some macros into a .h configuration file that C programs can include in order to check which options are enabled, in a fashion similar to what is possible with CMake's CONFIGURE_FILE macro. But after looking in the doc and the web, I could not find something useful. Is it possible to generate such a file from bjam and have the dependencies handled correctly? If so, how would you do it?
Yes it's possible.. The way to do it boils down to defining a make target for the header and using the #() file output action support in bjam. You would set up a set of configuration variables on the header target and the action would use them to generated the file. That is what I do in one of the library extensions I wrote (see GIF lib extension). I also wrote some basic support for automating some of the tasks, but it still ends up being functionally the same, to create text files in the ext.jam utility. To allow easier definition of header configuration files that change based on Boost Build features (see Irrlicht 3D lib extension). Basically you can do just about anything you can think of with the make target since it's implementation is entirely up to you.
Related
ALL,
I want to try and add an option to my configure script in my project.
For an example I'm looking at the library I'm using for development - wxWidgets.
wxWidgets have their options set and parsed inside configure.in file.
My project doesn't have this file instead it has configure.ac file which AFAIU, I should modify.
And then it just a matter of using proper syntax for parsing the arguments, which I can pick up from the sample.
Is this correct?
My project generates configure and Makefile by Anjuta.
TIA!!
configure.in is an old name for the primary input file to Autoconf. The preferred name for the same file is now configure.ac. You do not need or want both. Whichever you have, yes, is the one you would want to modify to add arguments to the generated configure script.
The Autoconf macros you would want to use are AC_ARG_WITH for a --with-foo argument or AC_ARG_ENABLE for an --enable-foo argument.
Of course, adding the argument is the easy part. For it to be useful, you will need also to write the code that gives the option its desired effect. Perhaps the example code you are looking at will be a sufficient resource for that, but I am skeptical. At least, this is probably not a cut & paste kind of situation.
need some help with using a 3rd party makefile when building my own project.
There isn't a way to what you want directly. CMake doesn't provide a facility to include files into its generated files. (ie: include a "3rdparty.mk" into a CMake generated Makefile.) Nor can you directly include a "generated-file-type" (ie: a Makefile) into a CMakeLists.txt. CMake's ExternalProject won't let you do that either.
What you need to do is somehow "parse" the makefile that has the information that you desire. There are a myriad of ways that you can do this. For example, you could write a shell-script wrapper that would grep your makefile for what you need then construct a CMake command line with the variables you want defined, and output it or call cmake for you. Depending on how comfortable you are with shell (or perl, python, etc.) you might feel this is the best option.
If you know these values will never (or very rarely change), you can hard code them in to your CMakeLists.txt (not recommended) or into a file you can include() (better).
You could also stay in CMake-land and use CMake's ExternalProject to help you. Using ExternalProject, you can:
Fetch your 3rd party libraries (download, copy, unzip, etc)
Patch the Makefiles of these libraries
Run make on those patched makefiles
Now, this patch that I mentioned is something that you'd have to write yourself, and keep with the source of your primary project. The content of this patch would be a new target for make that would write a file that you could include in your CMakeLists.txt via include(). You could start simply, and have this new make target (eg: make output_variables) write a list of set() commands to lib_A.cmake. After comfortable with that, you could move on to more complicated output; like writing a lib_A-config.cmake file that CMake's find_package() would understand.
Granted, the last option is probably the most complicated but it might make maintenance of your primary project easier, reducing pain in the future. You'll also gain a deeper understanding of CMake.
I'm currently trying to make splint available as an external tool in Visual Studio 2010.
It has problems with finding all includes for the file, since it seems that the INCLUDE variable is only set at build time and I haven't found any other possibility to extract the include files in any way.
My question: Would there be any way to extract the IncludeDir field from the current file's project's Properties page, ideally with the VC++'s AdditionalIncludeDirectories?
Note also that AdditionalIncludeDirectories is per file, as it can be changed for individual source files as well as on the project level, and if it contains macros it can evaluate differently for each source file too!
I'm not familiar with driving the MSBuild objects via the API, but that's used by the IDE. Whether that way or by simply running MSBuild.exe, you need to get it to figure out all the properties, conditions, etc. and then tell you the result. If everything is well behaved, you could create a target that also uses the ClCompile item array and emits the %(AdditionalIncludeDirectories) metadata somehow such as writing it to a file or passing it to your other tool somehow. That's what's used to generate the /I parameters to CL, and you can get the same values.
If things are not well behaved in that necessary values are changed during the detailed build process, you would need to get the same prelims done just like the ClCompile target normally does, too. Or just override ClCompile with your own (last definition of a target is used) so it certainly is in the same context.
Either way, there are places where build script files can be automatically included into all projects, so you can add your stuff there or use a command argument (I think) to MSBuild to add another Include.
—John
After reading:
A Gentle Introduction to CEDET
A Functional Introduction to CEDET-EDE
I learn that when creating a project folder with an existing make file and source code, I can have semantic index the files by either:
defining a simple EDE project with:
(ede-cpp-root-project ... :system-include-path '( "~/exp/include/boost_1_37" )
or by specifying the include paths to semantic directly with
(semantic-add-system-include "~/exp/include/boost_1_37" 'c++-mode)
But this still requires me to type the paths manually. Is there any way to automatically extract the include paths for semantic from an existing make file?
Background:
Some IDEs have a function to autodiscover gcc -I paths from an existing make file. For example, in Eclipse, you can create a project on a path with an existing make file and source code, and Eclipse would infer the include paths for its "intellisense" when building the project (I presume Eclipse parses the output of GNU make to do this). I would like to do the same in Emacs.
The answer is "yes": There's a way to discover this include path. AFAIK the code for it hasn't been written yet (tho I may be mistaken on this one). All you need to do is to run make -n and look for the "-I" in the output. Of course, the devil is in the details, but it should be possible to write a proof-of-concept fairly easily.
I'm developing a large project using Qt 4.6, CMake 2.8 and Visual Studio 2008 for the Windows platform.
As far the build system goes, it's all standard stuff: I'm using CMake's QT4_WRAP_CPP macro to generate moc files from header files, which are then linked into the final executable in the add_executable command. Everything is working as expected.
The only restriction with this setup is that I can't define widgets or helper using Q_OBJECT in .cpp files. This would be very convenient for small, context-specific helpers classes that should appear right next to where they're used.
I tried to pass the whole list of source files (both .h and .cpp) to QT4_WRAP_CPP, instead of just the header files, but that doesn't work (linking fails because some moc-related symbols are undefined).
I think the problem is that, for a given pair of files foo.h and foo.cpp, the QT4_WRAP_CPP macro will generate the same moc file (moc_foo.cxx) in the same directory, and obviously that means the first file will be overwritten by the second one, and as a result symbols will be missing at link-time.
Is there a way to fix or work around that problem? For instance, I tried to add a specific rule for foo.cpp of the form
QT4_GENERATE_MOC(directory/foo.cpp directory/foo.moc)
and then add
#include "foo.moc"
at the end of foo.cpp. I think this ought to work, but alas Visual Studio only allows one build rule per file, and .cpp files already have a build rule (compilation to object file), so this approach doesn't work, at least with Visual Studio.
Another idea that I had was to create a new macro, say QT4_WRAP_CPP_WITH_PREFIX, based on QT4_WRAP_CPP (which is defined in share/cmake-2.8/Modules/Qt4Macros.cmake), that would take an additional prefix argument and would add this prefix to the generated moc files. That way, I would call QT4_WRAP_CPP_WITH_PREFIX twice, once for .h files and once for .cpp files, with different prefixes. What I just dislike about this approach is that I'd be messing with the internals of CMake's Qt support, instead of using the public API.
Any better idea?
Recent versions of CMake have "automoc" which worked like a charm for me:
http://blogs.kde.org/2011/11/01/cool-new-stuff-cmake-286-automoc
Simply add in the CMakeLists.txt:
set(CMAKE_AUTOMOC TRUE)
and then in the cpp (e.g. example.cpp) file:
#include "example.moc"
(the *.moc must match the cpp file's name).
Referring to the documentation "Using the MOC" (http://doc.qt.nokia.com/4.1/moc.html), you'd only need to import "foo.moc" at the end of your implementation file. As you can not tweak the build rules correspondingly, try to export a .pro file and apply the build rule as suggested by the nokia document.