I am working with Eclipse Luna with CDT plug-in.
Whenever I build the project it keeps rebuilding all files, even if I just modify specific .cpp file.
I use project -> build project for the build.
I also removed build automatically option (and re-opened eclipse), but it did not solve the problem.
I've searched a lot for similar questions, but found none.
Are you using a manually-managed Makefile project, i.e. one that is not automatically-managed by the CDT plugin? If so, perhaps you could post your Makefile contents here, because there may be issues with the target dependencies in it.
The File | New | C++ Project | Executable option creates a project in which CDT automatically creates and updates the Makefiles itself - in this setup, the dependencies (while not perfect, because there are a few bugs in CDT in this respect) should be managed well enough so that it won't rebuild the entire project just because one file changed.
On the other hand, if you imported an existing project via the menu File | New | Makefile Project with Existing Code (which I didn't previously mention), then you would have had to copy the Makefile from the existing project manually, as CDT doesn't copy it for you, or you would have had to manually create a Makefile.
As I mentioned previously, if you posted your Makefile (feel free to 'sanitise' it by removing any personal information), we might be able to determine why it's rebuilding all files when you've only updated one of them.
I would have posted this as a comment reply to your last comment, #davidgrandson, but apparently there's a fairly short limit on the length of these.
Related
I've been redesigning my custom VC++ build to be compatible with the new TFS 2015 Build solution.
The issue is running msbuild. I can post perhaps a simplified version, but my solution contains two items:
1 Makefile Project designed to build all of the libraries required, and
1 .exe project.
I have a reference in the .exe project to the makefile project, so that the build of the .exe forces the build of the library if needed.
The issue we are seeing is that when we do a rebuild with msbuild of the solution, it first rebuilds the library, and then when it gets to the .exe, it cleans the library project, causing some of the rebuilt files to be deleted and then preventing the link of the .exe file because the .lib file was deleted.
Why is it cleaning the makefile project again? It seems like when it gets to the .exe project, it re-resolves the dependency, and does not know that the library project was already rebuilt.
Thanks in advance. Larry
If multiple projects are in the same folder, Visual Studio attempts to erase output folder (typically Debug or Release) when the next project will be compiled. The best solution is to put each project in the separate folder.
I didn't go through all details but the reason this happens is that when building on the command-line, rebuilding the exe project results in Clean + Build of the exe project, and the Clean target for the exe project eventually calls the CleanReferencedProjects Target which results in Clean being called on your Makefile project (and later on, Build as well).
This CleanReferencedProjects is conditional on the properties BuildingInsideVisualStudio and BuildProjectReferences, so building inside VS skips this step anyway because BuildingInsideVisualStudio is true, and it's even documented:
When building the project directly from the command-line, clean those referenced projects
that exist on disk. For IDE builds and command-line .SLN builds, the solution build manager
takes care of this.
The BuildProjectReferences property is documented as follows:
By default we will build (and if applicable, clean) all project references. But this can be used to disable that
So one possible solution is calling msbuild some.sln /t:Rebuild /p:BuildProjectReferences=False. In the case with only 2 projects this will work properly, but I cannot guarantee this will always work in more complicated situations with more inter-project dependencies.
Now one thing got me wondering: how come I've never seen this behaviour myself? The answer lies in that I don't use makefile projects often, and the C++ projects which I do use are slightly different: there, the Rebuid target is defined in terms of Clean+Build (while for a Makefile project it is a standalone, separate target). As such when the exe project calls BuildProjectReferences, it will call Clean in the C++ project, but that results in
Target "Clean" skipped. Previously built successfully.
because when the C++ project's Rebuild was called it called Clean and Build already.
So another possible solution is doing the same for the Makefile project. You say that your Rebuild has additional requirements; I don't know what they are nor why they are needed (and arguably it is wrong that Rebuild does not have the same effect as Clean + Build) but this might work anyway, for example with this in the makefile project (all the way at the end of the file):
<Target Name="Rebuild" DependsOnTargets="Clean;Build">
<!--additional requirements here perhaps?-->
</Target>
everything beaves properly and Clean/Build is called once only.
If none of these solutions apply I don't immediately see another way than removing the makefile project from the solution, and manually building it before the solution both locally and in TFS.
Background
I was working on a C++ project on a Windows machine, building using a makefile, and editing with Notepad++. I then decided to switch to a modern IDE, partly so that I wouldn't have to keep editing the makefile, so I installed Netbeans (first time I have used this IDE). When I created the project, I specified my existing makefile. All is well, and I can edit and build my project.
There were a couple of source files in the directory which were not mentioned in the makefile. However, they do show up in the file list in grey:
Problem
I can't for the life of me figure out how to add those grey files to the build. Do I still have to edit the makefile? Isn't the IDE supposed to manage this kind of thing?
No, Netbeans won't change your custom Makefile. If I were in your shoes, I'd start a new project and add the source files manually, and after that write any custom build steps you might require.
I'm using eclipse for the first time. I'm a seasoned VisualStudio user, so I'm trying to find similar functionality in eclipse. I have two projects, A and B. Project A spits out libA.a when it's done compiling. Project B links against libA.a. Here is my problem.
I compile project A then project B, everything is fine.
I make a code change to project A that requires a build of project A.
I try to build project B, but it states that no changes have been detected.
How do I make project B aware of the output of project A?? Currently I'm having to do a clean build of project B for it to re-link against libA.a.
Thanks.
EDIT: In my ProjectB->Path and Symbols->References tab, I have project A checked. This doesn't relink after project A is rebuilt.
Try the below settings:
Go to properties of Main Project → C/C++ General → Paths and Symbols → References
Tick all the dependencies.
You go into Project Properties of Project B, select Project References and make it reference (depend) on Project A.
Edit, appears to be a known bug
One can work around this problem by using the touch command.
In Eclipse, as part of C/C++ Build/Settings is the tab 'Build Steps'. In the pre-build steps command line, enter touch filename.
filename is any file in your application. This could be the file with main(). This could be a special file just for this workaround, touchdummy.c, which can be a tiny file, which compiles quickly.
When the application builds, even if you didn't change any sources, the touch command causes make to rebuild the application. If the library was rebuilt, then the application gets rebuilt with the new library.
One can read about how touch affects the date/time of the file here.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html
Edit: The exact command in Eclipse would be touch ${ProjDirPath}/src/main.c
Edit: This command should work, but it appears that if the 'main' project did not change, the pre-build step is not executed. Also the touch command causes eclipse to prompt to reload the file it touched. A large annoyance.
Eclipse projects depend on each other by virtue of the checkbox in the project's properties (dependent projects?) which is how Eclipse decides which to build. You can set this yourself, but it's usually set when you change your Java build path.
By default at least with QNX C++ projects, it WILL NOT check for changes in other projects.
Right click on the project, and expand "check dependencies on/off"->"check user headers only"
It seems to work, roughly...
It appears to do a makedepends on the code, and adds *.d files to the output folder which are simply depends file that list the header files.
Note: these do not appear to get regenerated, and get out of date - I do not know how to regenerate them.
For Project A (library):
Properties>C/C++ Build>Settings>Build Steps>Post-build steps> touch -m ${ProjDirPath}/source/build/build_updated.cpp
You should create folder "source/build" firstly and don't add in that folder any other files.
For Project B:
Properties>Project References> check Project A
Properties>С/С++ General>Paths and Symbols>Source Location>Link Folder>Link to folder in the file system> find and pick "source/build" folder which you created for project A before.
I'm making changes to a form in Creator but when I build the changes are not being "refreshed".
I've gone so far as to remove every element from the form and get rid of every stylesheet but when I build the project I get the same result; as if I had never made a change at all.
What gives? Am I missing something obvious? (obvious to everyone but me.. obviously)
I guess you're using QtCreator 2.0? I found the same strange issue. You have two options:
Remove the ui_{the_name_of_design}.h from the project's build dir. Then run qmake again.
make clean or Build → Rebuild All
But the second option even doesn't help with me. By the way that's why is good to use a different build dir than that where the sources are. If some changes don't appear to be applied, just delete the content of build dir, and everything goes fine as well.
Cheers
Most likely cause if that your make procedure is not noticing the changes in the .ui file, and so it is not calling the uic tool. Try to do a make clean to see if it helps, and check your build log to see if uic is being called.
For me, the solution was to change the BuildDirectory to the same directory where the code is, instead of the **-build-desktop directory.
I stumbled upon this issue as well and one thing I noticed was that my program was still running in the background without me knowing. Ending the task through task manager fixes it and you can make changes again.
A few suggestions:
Perform a make distclean.
Use a shadow build directory. Building “inside” the source code is not advised.
Check your computer’s clock and the date and time of your files.
This thread is a little dated but since I got caught up in the same problem I thought I would share how I resolved this.
I've been incrementally building up a ui with designer under QtCreator 2.4.1/Qt 4.8.1 using a poor man's source control approach: snapshots. At one point I inadvertently created a non-shadowed build project. In a subsequent snapshot I reverted the project back to shadow build and at that point new widgets added in the ui form were no longer being recognized in the build.
Solution:
Delete stale ui_.h files from the source directory.
Delete make and ui_.h files from your shadaow build directory.
Rebuild
Latest generated ui_.h files will reappear in the shadow build directory.
No copies of ui_.h files appear in the source directory indicating that the stale files were taking precedence in the build order. Not obvious.
I have this problem and i solve it by changing the project path. I had stored the project in my flash memory when i had this problem, then i copy the project folder and it's build folder also in the Desktop and open it with QtCreator and the problem was solved.
Problem is indeed stale generated files in project source directory. This can happen both with genrated ui_*.h files, as well as with moc_*.* files. Below is not covered by existing answers, so here we go:
To remove generated files from the project source directory, without affecting Qt Creator settings or current shadow build directories, there are two principal ways, which can also be combined for extra coverage.
Go to Qt command prompt, go to project source directory and run these commands:
qmake -r
make clean
make distclean
1st one will recursively create makefiles. 2nd one will remove all files produced by building the project. 3rd one will remove the makefiles again. Then continue using shadow build from Qt Creator as before.
The problem with this is, it will leave files which are not part of the project. So if some files have been removed from project, related generated files may remain, and cause trouble if files with same name are added back. So even after this it is good idea to verify no ui_* or moc_* files remain, if you know you have removed files from project.
Use your version control software to first commit or stash/shelve all uncommitted changes, and then remove all unversioned (also otherwise ignored) files. For some version control software this may not be easy as git clean -dxf (beware, that will also lose uncommited changes and Qt Creator's custom project settings), and in that case it may be easier to just remove project source directory and get a clean checkout.
The problem with this is, if some generated files have accidentally been added to project, they will not be cleaned up with this. So it may still be a good idea to do the step 1 above too.
Above steps should be in sync so that after step 1, any files in source directory (except Qt Creators's projectname.pro.user and possible *~ backup files) should be under in version control.
I have a large existing c++ codebase. Typically the users of the codebase edit the source with gvim, but we'd like to start using the nifty IDE features in Eclipse. The codebase has an extensive directory hierarchy, but the source files use include directives without paths due to some voodoo we use in our build process. When I link the source to my project in Eclipse, the indexer complains that it can't find any header files (because we don't specify paths in our includes.) If I manually add the directories from the workspace to the include path then everything works wonderfully, but obviously adding hundreds of directories manually isn't feasible. Would there be a simple method to tell Eclipse to look anywhere in the project for the include files without having to add them one by one? If not, then can anyone suggest a good starting place, like what classes to extend, for writing a plugin to just scan the project at creation/modification and programatically add all directories to the include path?
The way that CDT manages build paths is by looking at the .cdtbuild xml file in the base of your projects directory (it might be a different name on windows... not sure)
In this you should see something like
<option id="gnu.c.compiler.option.include.paths....>
<listoptionValue builtIn="false" value=""${workspace_loc:/some/path}$quot;" />
<listOptionValue ... />
...
</option>
this is where all the build paths that you configure in the gui are placed. It should be pretty easy to add all the directories to this using a simple perl script to walk the project and generate all the listOptionValue entries.
This is obviously not the ideal method. But im curious, what build system are you migrating from, if it is make based you should be able to get eclipse to use your make files.
This feature has already been implemented in the current CDT development stream and will be available in CDT 6.0, which will be released along with Eclipse 3.5 in June 2009.
Basically if you have an #include and the header file exists somewhere in your project then CDT will be able to find it without the need to manually set up include paths.
If you need the feature now you can download and install the latest CDT development build.
Eclipse Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=213562
Latest CDT 6.0 Builds: http://download.eclipse.org/tools/cdt/builds/6.0.0/index.html
From reading the this Eclipse CDT FAQ entry, it sounds like Eclipse can automatically generate a list of include directories if you start your build from within Eclipse and if your build outputs the gcc / g++ commands before actually starting gcc / g++. You can change how Eclipse starts a build by going under Project Properties then selecting the C/C++ Build category and looking for the Build Command option on the right side of the dialog.
Depending on the amount of voodoo you are doing in your build process, then Eclipse may not be able to correctly parse your source files, especially if you have similarly named headers for different source files. If you really want to take full advantage of Eclipse you're going to need to make sure that with whatever setup you have you aren't going to be confusing the parser. Personally I would recommend having a simple layout and build process.
As for the question at hand, adding the directories one by one is pretty much your best bet.