I have written a makefile. This makefile is to be checked into SVN. I used environment variables for my project directory path so that different computers can run the makefile without having to make changes to it.
for example: PRJ_ROOT_DIR := $(REF_DIR)/projectName/trunk/Temp
where environment variable REF_DIR is C:/Users/myName/Desktop.
However, by just building the project, makefile automatically changed to:
PRJ_ROOT_DIR := C:/Users/myName/Desktop/projectName/trunk/Temp
This shows up in SVN that makefile has been modified.
How do I do it so that makefile remains as
PRJ_ROOT_DIR := $(REF_DIR)/projectName/trunk/Temp? Where changes is done in the background and not showed up on the built makefile so that SVN will not detect the change?
I found the answer; the makefile is auto-generated. Hence, modifying the generated makefile does not help.
I tagged eclipse because compilation is done in eclipse environment. I thought that there may be some settings that I may need to change when in that environment.
Related
Can I configure a CLion project to use a Makefile that is not named literally: Makefile?
I have an older project I'd like to build, but the makefile is called Makfile.osx_sdl2.
I'd like to somehow tell CLion to use that name. Note that, the project also has a Makefile which is somehow used by Makfile.osx_sdl2, so renaming or symlinking won't work.
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.
I have a project which uses Makefiles. On a branch, I have CMake based build system. Now some team-members wants the OLD make-files based system intact, when cmake is added. But this is not possible after cmake . command overwrites the old Makefile.
Now I can easily avoid it if I can tell CMake to generate makefiles with some non-standard names e.g. makefile.cmake etc. Is it possible?
I am open to consider other options as well. In any case, old Makefiles must not be touched.
Cmake creates a build system in the working directory. So create any empty directory, and run cmake <path-to-source> from there.
Unfortunately, the name "Makefile" in hard-coded several times, in the sources of CMake. You cannot change it. As Peter has pointed out in the other answer, that change is not necessary, because CMake support out-of-source builds.
In some of my projects I use some pre-build step(s) configured in the .pro file. So qmake will execute this step whenever it is activated.
Now in QtCreator, when I build (also when completely rebuilding the whole project), it doesn't always run qmake, since it tries to be clever and optimize this. It only runs it when the .pro file has been changed, causing several issues.
Also a common issue is, when you make a class inheriting from QObject after running qmake on that file, it will not notice it and hence not run moc on it. Such issues are solved by simply manually running qmake via the "Build" menu in QtCreator. But if I forget this I am sometimes confused by the compile errors I get because of this and this is really annoying.
(How) can I force QtCreator to do this step always when building a project?
I thought about adding qmake as a build step in the project configuration, but this seems to be a dirty hack to solve this problem.
Another dirty hack but a little more flexible: On Linux/Mac add "touch yourprojectfile.pro" as a build step or assign an external tool call to sth. like touch "*.pro" run in your current projects working directory. When the pro file is altered (which is mimicked by touch) qmake is executed. Not much cleaner but the external tool plus hotkey solution is more flexible than adding qmake into the buildsteps of each an every project.
Update:
I finally found a completely satisfactory solution for this.
In the pro file add:
qmakeforce.target = dummy
qmakeforce.commands = rm -f Makefile ##to force rerun of qmake
qmakeforce.depends = FORCE
PRE_TARGETDEPS += $$qmakeforce.target
QMAKE_EXTRA_TARGETS += qmakeforce
This deletes the generated Makefile an thus forces qmake to rerun for every build.
I think your best option is customize your QtCreator .This can be done by write a plugin for QtCreator ,or you can change the souce code of a plugin named Qt4ProjectManager ,then build it for yourself . This might be complex ,however, can be a solution.
What I've done is created a makefile that explicitly calls qmake. Of course, that means I have two makefiles, but in my project file, I have
MAKEFILE = makefile_qt
which means that the generated makefile will have that name.
So, for the makefile I manually created, I have:
default:
qmake;
${MAKE} -f makefile_qt;
Then, from QtCreator, I just call the regular make, which will default to makefile. Or you can leave the Qt-generated makefile as is, and just call make -f makefile to call your manually created one. I forget which has precedence, makefile or Makefile, and I'm not sure if it is always the same.
I'm using the following codes in my .pro file.
QMAKE_CLEAN += ./Makefile
This makes run qmake whenever executing clean.
I develop C/C++ using the Eclipse IDE. Eclipse also generates a makefile which I don't want to edit as it will simply be overwritten.
I want to use that makefile for nightly build within Hudson.
How do I pass #defines which are made in the project file of the IDE to the makefile ? (and why doesn't Eclipse already include them in the generated makefile?)
I actually had this figured out once, then accidentally overwrote it :-( But at least I know that it can be done...
If you are running make from the command line, use
make CPPFLAGS=-DFOO
which will add -DFOO to all compilations. See also CFLAGS, CXXFLAGS, LDFLAGS in the make manual.
You could write a small program to include the headers and write a makefile fragment which you include in the main makefile (requires GNU make).
This is a fairly ugly solution that requires a fair amount of hand hackery. More elegant would be to parse the project file and write the makefile fragment.
For GCC use -D define.
OP commented below that he wants to pass the define into make and have it pass it on to GCC.
Make does not allow this. Typically you just add another make rule to add defines. For instance 'make release' vs 'make debug'. As the makefile creator you make the two rules and have the defines right in the make file. Now if Eclipse is not putting the defines into the makefile for you, I would say Eclipse is broken.
If you're using autotools another options is to have 2 directories 'bin/debug' and 'bin/release'.
# Simple bootstrap script.
# Remove previously generated filed and call autoreconf.
# At the end configure 2 separate builds.
echo "Setting up Debug configuration: bin/debug"
../../configure CXXFLAGS="-g3 -O0 -DDEBUG=1"
echo "Setting up Release configuration: bin/release"
cd bin/release/
../../configure CXXFLAGS="-O2"
Setup Eclipse. Open the project's properties (Project->Properties->C/C++ Build->Builder Settings) and set the Build Location->Build Directory to
${workspace_loc:/helloworld/bin/debug}
Replacing 'helloworld' with your project's directory relative to the workspace (or you can supply an absolute path ${/abs/path/debug}). Do the same thing with the Release config, replacing "/debug" with "release" at the end of the path.
This method seems like a waste of disk space, but a valid alternative to achieve completely separate builds.