I'm using Teamcity to build a CMake project. I'd like to leave Clean all files in the checkout directory before the build off, so that it doesn't have to keep re-fetching all the source for minor changes. Is there a way I can specify the CMake working directory to be in some temporary directory that Teamcity will create for me, and then delete when the build is done?
I thought %system.teamcity.build.tempDir% might do it but there doesn't seem to be any documentation for it, and I think that might just be the directory where all builds go.
%system.teamcity.build.tempDir% is fine. And so is %TEMP% actually (on Windows, or %env.TEMP% in TeamCity-speak): the agent overrides the env var and uses a clean temp directory for every run.
Related
I am building my project with cmake. I am able to generate the Makefiles on linux platform and hence able to build the project as well.
However, When I want to clean the all generated files, I am not able to do so.
I am not able to remove the foo.c.gcno and foo.c.d kind of files, using make clean command.
Is there any specific command in cmake to remove these intermediate files ?
Note: I have different directories for Cmake-source and build. I am concerned about the generated files(*.c.gcno and *.d) in the build directory. Rest all other files like *.o and *.so are cleaned up by make clean command.
In CMake, you cannot generate a Makefile and delete the rest. All the generated files, and an installed CMake, is still needed to build the project.
You should have run cmake <source directory> in a different directory in the first place. Let's call it build directory.
Then, build directory can be completely removed without changing the source code.
After installing cmake-3.8.1-win64-x64 I got thisenter image description here
So what can I do with this? Thanks.
cmake-gui does not help you create cmake configuration files, it parses these files to generate and configure projects.
In your source code directory, you should have a CMakeLists.txt file which defines the rules for CMAKE to configure your problem. That directory should be entered into the first box.
Next, you get to decide where to build the binaries. We could do it in the source directory, but the generated artifacts could pollute what is already there. "Cleaning" the build by deleting all of those artifacts while keeping the original sources is tedious at best, so it's a good idea to make an empty directory and use that as your binaries path.
Once you have those fields entered, you should be able to "Generate" or "Configure" your project. If you need help creating a CMakeLists.txt file (that's really the complicated part), then check out their tutorial.
We have a huge set of modules in our project and therefore we use mvn install to save time on builds. But, it doesn't seem to handle file deletes very well. It doesn't delete the deleted files from the target during compilation.
Is there a way for maven to perform a "clean install" when there are deletes or even changes to the module. And perform "install" if there are no changes.
Or, is there an option in install to detect file deletions and update the target accordingly?
Thank you.
I have a project organized as follows:
include/
src/
share/myprogram/
where share/myprogram/ contains resources.
My program is accessing these resources using relative paths. The executable expects to find them in ../share/myprogram/.
I would like when I run:
mkdir build
cd build
cmake ..
make
to have the following to happen:
make a bin directory
compile and put the executable in bin/
copy the share directory in the build directory
I am looking for a clean way of doing this. Ideally, I would like CMake to be aware of the resources as resources.
I know that I could use a copy custom command. Is this the only way to achieve this?
Bonus
If the resources could appear under Resources in Xcode when using the Xcode generator, and the copy be a clean copy phase under the mybin target, that would be awesome (and that's what I mean by CMake being aware of the resources as resources.)
Update:
What I have thus far:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)
add_executable(mybin ${Headers} ${Sources})
add_custom_target(
Resources ALL
${CMAKE_COMMAND} -E copy_directory ${PROJECT_SOURCE_DIR}/share ${PROJECT_BINARY_DIR}/share
SOURCES ${Resources}
)
You may use Configure_file for copying files from source dir to binary dir. it has parameter Copyonly.
I am doing a unix command line tool, I am not doing a Mac OS X bundle and Xcode's resource folder is only for bundle resources so forget the bonus.
I realized that I wasn't doing things correctly.
Using a relative path to access a resource is not reliable since the program can be executed from anywhere.
What I did is to look for resources in a hierarchy of folder, starting from user specified, to environment variable, to relative directories and finally to standard unix directories.
So actually, the copy phase during the build is not necessary anymore. Only the installation matters and that is fairly easy:
install(DIRECTORY share/ DESTINATION share)
FYI, I kept my custom_target as is since I like having resources visible in Xcode, and calling it Resources makes it pretty :)
I'm consolidating my Xcode/TextMate setup and is interested in where you put your build dir.
Some years ago I started out having the build dir in the same dir as my xcodeproj file.
However it became a mess when my project became a multi project with a applications and frameworks and tests, so I started using ../build as the build dir, so that all the sub projects used the same dir. However Spotlight is indexing this build dir and TextMate's global find is unusable when there is a build dir in the project.
I'm thinking either using ~/.build or /build as Xcode's build dir.
What build dir do you use and why?
If you let Xcode create the build directory then it shouldn't get indexed by Spotlight (Xcode sets an extended attribute on the directory specifically to make this happen). If it's a build directory from an old project that been upgraded, or a build directory that you created manually, then this won't be the case and it will get indexed. You can either add this attribute manually if it's missing, or perhaps delete the build directory and let Xcode re-create it. Once you have this sorted out you should be good to go with your common build folder scheme.
The extended attribute is com.apple.XcodeGenerated.