Community
Participate
Working Groups
Build ID: 3.3.0 Steps To Reproduce: 1. Change a file using a separate editor. 2. Press Build: if internal buiold, it will not rebuild. 3. Whether internal or external, changes from referenced projects does not cause rebuild. More information: This used to work until I updated to 4.0.1. For internal build, it does not seem to follow dependencies (the makefiles from external builds have the %.o: ../%.cpp. But, there is no dependencies on libraries I am building from other projects! So, a referenced project builds its lib, but then the main project (which referenced it) says nothing to do. I looked at its makefile, and there is no dependency at all. That is, USER_OBJS is empty. I am not sure what mechanism was used before, so this may not be significant, but regardless of the cause, it is not rebuilding. This is quite serious.
I cannot believe I am the only one seeing this reference problem. When the makefiles do not use the libs for dependency checks, then it makes it almost unusable as a tool. This means I have to do a clean before builds to make sure it builds the executable when the libs change. Can someone explain what is going on? If this is not affecting everyone, then what can I do to make mine work properly again (as they did with Callisto)??? Is this a converter problem? Do you want to see an example of the makefiles or projects?
Are you sure it's not just a matter of your workspace not having refreshed? If you don't have automatic refresh turned on, then the build system won't know that your file changed externally. If it thinks that no files have changed then it won't invoke the builder.
(In reply to comment #2) > Are you sure it's not just a matter of your workspace not having refreshed? If > you don't have automatic refresh turned on, then the build system won't know > that your file changed externally. If it thinks that no files have changed > then it won't invoke the builder. OK, I think you are referring to one half of my bug report. I have auto-refresh on. It means that about 1/2 the time it notices and 1/2 the time it does not. But, that is not the worst problem. To understand the problem is simple: 1. Create a new C++ project "tlib", which makes a library for MinGW. Populate it with one new source file, tlib.cpp, which has a function: int foo() {return(1);} 2. Create a new C++ project "texe", which makes an executable for MinGW. Populate it with one new source file, texe.cpp, which has main: extern int foo(); int main(){return(foo());} 3. Go to properties for texe and to C++ settings and then to "libraries". Add tlib and the path to tlib as workspace:tlib 4. Go to properties for texe and project references and select tlib. 5. Build texe. 6. Go to tlib.cpp and change something (e.g. change the 1 to a 2). Click build on the texe project. It will build tlib but then say nothing to do for texe!!!! This is just wrong. It should know that libs are dependencies and so should rebuild texe. I do not know how anyone is using this for more than a single project.
Hmm.. I suppose that the dependent project should build once the referenced project changes. I'll take a look..
(In reply to comment #4) > Hmm.. I suppose that the dependent project should build once the referenced > project changes. I'll take a look.. Yes, it is crucial. Even if using DLLs, this is important, since any added or changed interface can impact the binding to the DLL. Only runtime loaded DLLs would not need this (ones where you call LoadLibrary/dlopen).
Did you try to add tlib as reference in texe -> C/C++ Project Properties -> Paths and Symbols -> Project References ?
(In reply to comment #6) > Did you try to add tlib as reference in > texe -> C/C++ Project Properties -> Paths and Symbols -> Project References ? No. Are you suggesting this as a workaround??? Or, are you suggesting that the IDE is not able to handle multiple projects in a normal way anymore? Note that this is pretty basic. The normal model is simply to add as a dependent to the makefile or makefile equivalent (for internal), and it just works. But, I will try this as a workaround, since this makes Eclipse very painful to use now (I have to do clean and build to get it to work).
Yes, if I manually add/check this build side reference to the directory where the lib builds into, it does then properly build the .exe file when the lib changes. Note that the normal project reference (at the top level of properties for the project) is also checked of course. Adding this reference adds a -dependent line to the makefile with the selected target directory (vs. the target lib or object or whatever). So, the simplest solution would be to auto-set this inner one when the outer is also set. Even if the depended-on project only build a runtime DLL or exe, it would still be reasonable if unnecessary.
(in reply to comment #7) > Are you suggesting this as a workaround??? Or, are you suggesting that the > IDE is not able to handle multiple projects in a normal way anymore? This is not a workaround. This was also necessary in CDT3. The Project References you are talking about are Eclipse Platform references. If you have selected a referenced project there it will be build before the actual project. Nothing more. Only if you activate the references in the C/C++ projects tab CDT will do a real C like rebuild i.e. it will check if any source file was modified and a rebuild of the executable (the referencee project) is needed. In CDT3 you had to set the referenced projects in both places manually. In CDT4 it is sufficient to set the references in the C/C++ properties page (Paths and Symbols -> Project References) and the Platform references are set automagically (the inner one sets the outer one if refering to your comment #8). FYI, I am not a Eclipse developer but I am using the CDT for almost 2 years. So I learned (or better had to learn :) ) a lot about how Eclipse is working. In my opinion the usage of referenced projects is not clearly stated in the CDT help files. It took me some time to figure it out.
(In reply to comment #9) > (in reply to comment #7) > > Are you suggesting this as a workaround??? Or, are you suggesting that the > > IDE is not able to handle multiple projects in a normal way anymore? > This is not a workaround. This was also necessary in CDT3. The Project This is different from the one that was with Callisto. I still have that version installed and it works fine with no such extra work. In fact, I built the same simple test (testexe and testlib) and it does the right thing automatically. Losing the dependencies (decoupling the project build rules from the makefile dependencies) very much happened with the 1st CDT version coupled to Europa, at least for those of us who take it when released. I note that this need to manually add dependencies is *not* something that is desirable or common to any other IDE I am aware of. It is a major weakness and certainly not justifiable for any normal C/C++ development. If CDT simply used the "Eclipse project references" as the default "C/C++ project references", it would work for anyone. For those people where the dependency is not real, they could clear the C/C++ project dependency to avoid the re-link/re-ar; but the relink would not hurt them.
I've investigated the problem of project not being rebuilt in case of a reference project change. The problem seems to be Internal Builder-related. This is not a regression, i.e. the problem exists in both 3.x, 4.0 and 4.0.1 To split two problems reported here, I've raised a separate Bug 210248 to handle the "dependencies" issue. I'm not sure if there's something we could do about the remaining part of the bug ("No build if file changed outside Eclipse").
I'm not sure there is anything we can do either. For files to get picked up in the Eclipse resource delta, they need to be IResources. I'm not sure if linked resources work correctly in this situation either.
Since this is back on the inbox, it's clear this won't get finished for 4.0.2.
This is a productivity setback in CMake-generated Makefile projects. I'm not sure why, but I find myself pretending to edit a source file by inserting a random space and saving in order to enable the build (via Build Project) about 25% of the time. (CDT 8.8)
