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.
Related
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
Suppose that I have multiple libraries that I can build with cmake or with configure scripts, there is a tool that can help me with building this libraries such as I can easily manage the rebuilding of this libraries with few modifications like changing compiler's flags ?
I would like to run a sort of automated process a see the feedback about each build + some freedom about building options.
There is a tool like this one beside a conveniently created bash script ?
Make seems like the best tool to use here, but bash script would also work. You could use a makefile that calls the other makefiles with -f (or switch to the directory with -C ). Also, you could handle the flags and such within a single makefile with judicious use of variables, targets and recipes. Realize you can set make variables (and therefore flags) from the command line. That's about the most I can help without knowing more specifics of your situation. Good luck!
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 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.