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.
Related
i'm new year and I need some answer. I searched on the web to some answer but i didn't found anything usefull. What am i searching is for a shell programms that when you execute it, create a Makefile with the binary name in arguments like :
./automakefile.sh hello .
Will build you a Makefile with a binary name called hello.
I hope you guys will help me, i'm counting on you <3
There is, unfortunately, no such magic command. If there was, we wouldn't need Makefiles to start with because the magic would most likely have been incorporated in the compiler.
There are several reasons why there isn't a command like that.
Given a random binary file, you can't generally say what programming language it was written in.
You also can't tell what source file were used to compile the binary file from, or where in the file hierarchy they are located (not just where they were located when the binary file was compiled last time, maybe on another system).
You don't know the dependencies between the source code files. Makefiles are primarily useful for keeping track of these (and compiler flags etc.), so that changing one single source file in a big project does not trigger a recompilation of everything.
You don't know what compiler to use, or what flags to pass to it. This is another thing a Makefile contains.
There are build tools available for making the creation of Makefiles easier, and for making them portable between systems on different architectures (the Makefiles that is, not necessarily the programs, that's down to the programmer). One such set of tool is GNU's autotools, another is CMake, and I'm sure there are others as well, but those are the ones I use.
Now you're facing another but similar problem, and that is that you still need to learn the syntax of, and writ,e your Makefile.am and configure.ac files (for the GNU tools), or your CMakeLists.txt files (for CMake).
We're using a modified compiler from under xcode. Mostly this works. However, as part of the modification, the generated .o files are not ones that the standard apple tools recognise, and in particular libtool does not like them. The effect of this is that we can't seemingly support static libraries (ie. .a files).
Does anybody know how to override the libtool we use? Worse case then is that I could write a script that did the right thing. As it is, I can only see how to replace the compiler.
FTR The only way I've managed to do so for now is to override the libtool under:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
copying the original to libtool.real and having a shell script that looks at the .o files past and works out what to do. The one extra issue I've noticed (affecting how you write the shell script) is that the "ranlib" operation recursively calls the same script, so you need to be careful and only do the modified operation when the parameters precicely match the basic case (I check for there being more than one .o file either directly or via a filelist).
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'm looking for the best practice for including GNU Bash in the cross-compilation of NetBSD using the build.sh script. Right now, my plan is to include it in usr/src/gnu/dist and then create the relevant Makefiles in usr/src/gnu/usr.bin but I was wondering if there was an easier/better way to do this?
The new way is to place files under src/external//. For bash, it's src/external/gpl3/bash. (This directory is called ${EXTTOPDIR.bash} hereafter.)
The original source is expanded into ${EXTTOPDIR}/dist as is. Other files and directories are made at ${EXTTOPDIR}. Start with copying src/external/gpl2/xcvs for example. (BSD) makefiles that are placed (out of the original source) are called "reach-over"; meaning that build procedures are kept without disturbing the original source. This helps to ease maintaining of the original source. (And no, all of these are not documented at all, unfortunately.)
If you need to hook the build as "tools", you'll need something more to care. The procedure is also not documented. Just learn from the source.
If you work on the official NetBSD tree, you have something more to learn about CVS; use vendor branch, etc.
HTH,
Masao