I have an Xcode project with in it one 'core' target (a static lib) and 130+ small 'extended' targets (all executables). These extended targets all have a dependency on the core target.
I also have a single .xml file that needs to be processed into a C++ .h file, and this generated .h file is needed by cpp files in all targets (core and extended). I also need this generated file to be located next to the .xml file itself for inclusion in Git.
I added a custom build rule to the core target to process the .xml file. As it's custom script I invoke a custom binary that does the conversion, and in the output files section I list the resulting .h file's path. When I then change the .xml file, Xcode calls the build rule before compiling the cpp files in the core target. So far so good.
But (presumably due to Xcode's 'new build system'), Xcode compiles all cpp files in the extended targets in parallel with the core target (sometimes even before them). This should normally work fine because the extended targets normally only need the resulting .o file from the core target, so if they only wait for core's linking phase to complete before they start linking themselves that should work. But in my case, all cpp files in the extended targets that get compiled before the core target has had a chance to convert the .xml file will see an outdated generated .h file. A second compile then fixes all errors resulting from this.
How can I tell Xcode that the generated .h file in the core target's build script is also relevant to the extended targets?
I duplicated the same build rule to all extended targets (which I really hate because it introduces a lot of clutter to my project file), but that weirdly didn't change Xcode's behavior at all.
An other alternative would be to uncheck 'Paralellize Build' from the scheme so that Xcode is forced to first fully compile and link core, but I definitely do not want to give up on building all extended targets themselves in parallel.
What other options do I have?
Related
I'm trying to extend an open source project with my own source files, so that the executable being produced includes my code as well. Probably it's very easy, but somehow I'm overlooking it.
The build process is using cmake and the open source project contains a well written CMakeLists.txt. Instead of adding my source files in the directories of the open source project (and possibly changing CMakeLists.txt of the open source project), I prefer to separate my code in its own directory as follows:
src/opensourceproject/src/...
src/opensourceproject/include/...
...
src/myaddition/include/...
src/myaddition/src/...
Is there a way to wrap the build process and create a CMakeLists.txt that builds opensourceproject with my sources added to the opensource build? The reason why I want it, is that I'm more or less writing a plugin and I want my code to be present in the produced executable.
I have a custom build rule on a data file which generates a header file. The custom build rule works fine (runs when the data is changed and does not run when it is not, as I would expect it to).
However, this generated header file is included by a .cpp file which is compiled using the default C++ compiler. When the header is generated and there are no changes in the .cpp itself, the build system will not compile it. I have to build twice, once to generate the header file and then once more for the build system to notice and rebuild the .cpp as well (the generated header has the current date/time so there are no problems there, it just seems that Visual Studio makes all the checks before starting the build).
Not a major issue but it gets annoying after a while. It is also error-prone. Is there a way to either expedite the custom build rule so that it would run before Visual Studio checks the dependences of the .cpp files or maybe to run the build twice? There may be several files using this custom build rule so using a pre-build step to build them all would get messy.
I'm using VS 2008 if that makes any difference. The custom build rule has the "Outputs" field correctly filled in so it has the information about the files the custom build generates.
I am converting a C++ project created using Visual Studio 2005 to CMake and have stumbled upon a bit of a problem with resource files that are included in the project.
The project includes a .rc file, a bunch of .ico files and a .rc2 file.
The regular .rc file works fine in the generated project and uses the resource compiler. The .ico and .rc2 files however are causing problems when they are just being included, because in the generated project Visual Studio attempts to compile them using the C/C++ compiler.
I assume that these files are included by the .rc file, so it would probably work to just not include them in the CMakeLists.txt file, but since it is obviously possible to list them in the project (they are visible in the original project) I would like to do so, so that the user of the generated project can see that these files are being used.
What is the correct way to handle these extra VS resource files in CMake?
Try to set_source_files_properties(your.ico your.rc2 PROPERTIES LANGUAGE RC).
By default it shouldn't do anything with those files. The source file property LANGUAGE should be empty and thus the action for the file should be checked by the file type. Which shouldn't be anything since it's not something it should compile.
Check your CMakeLists.txt that is doesn't contain a set_source_files_properties command that would mess with that property.
If you want to do something with the files, here are two ways to do things:
With add_custom_target you can add them and run custom commands for them when you build the project. Granted that the files have changed.
With configure_file you can easily copy them to a build directory if needed. With the COPYONLY flag.
I'm experimenting with OpenDDS (and ACE/TAO), which uses MPC (Make Project Creator) to generate the actual make files, and it's doing a couple really annoying things.
First, it generates a lot of intermediate sources files (some IDL, and c++ headers/implementation), and it places them in the same directory with manually created IDL and C++ files. I'd like to have the manually created files and the generated files be in separate directories, because all the generated files are distracting. Is there any way to do this?
Second, make I run "make clean" it cleans up the generated object files, but it does not clean up generated source files. Is there a way to make it clean all the generated files?
To delete all the generated files (when using make files), simple do a 'make realclean'. 'make clean' simply cleans up the C++ compilation products (object files, library, & executables) while 'make realclean' removes all generated files.
Changing the output directory for the generated files is probably not something you really want to do. Yes, the large amount of generated IDL and C++ does sometimes get in the way, but after a while you learn to look past them. If you are dead set on this, one indirect way is to use the clone_build_tree.pl script that comes with MPC. This script creates a new directory (under build/xxx) which contains symbolic links to all the source files. You then do your build there, leaving the original source directories pristine. Here is a simplified example (assumes ACE, TAO, and MPC are already setup):
cd DDS
$MPC_ROOT/clone_build_tree.pl test
cd build/test
export DDS_ROOT=`pwd`
build using normal Open DDS instructions...
I know this can be done using a makefile, alas I am not using a makefile, but rather Eclipse's "managed" C++ project. :( In any case, this is what I'm trying to accomplish:
I have a C++ project in Eclipse. I have a number of XML files in this project that specify information about source files that are auto-generated. When the XML files change, I would like a custom tool executed to convert them. The challenges are:
These resources need to be built prior to compiling the project since they specify source and header files used in the compilation.
They should be built only when the XML file is modified (header files are generated, so this is to avoid needless recompilation because a file timestamp changed).
I'd like it included as part of the build process of this project, not a separate project.
I see moving to CMake in the future, but for the time being I am trying to make do.
You can add a pre-build command in Project Properties -> C/C++ Build -> Settings -> Build Steps. This command will be executed before each build.
I'm not aware of a built-in way to get the command to run only when the XML file is modified. If you want that, then instead of making the pre-build command the XML-converting command itself, you can make it a "make" command with a makefile with a single rule whose prerequisite is the XML file and which calls the XML-converting command.