Bug #13070 2008-02-03 17:56
prashanth
With Custom makefiles, "Build workspace" option throws error
Platform: Linux (Debian) Build: SVN 4853 (debian package from http://jens.lody.name/debian/) Steps to reproduce: 1) Create a new project in the workspace 2) Create a makefile to compile the project 3) Configure the project to use custom makefiles a) Select "Project --> Properties", check "This is a custom Makefile" 4) In the "Manager" side bar, project tab, right click on the project created in step 1 and select "Build". This compiles fine without any issue. Do a clean after this.... 5) Select "Build --> Build workspace", this action first uses the custom makefile and compiles the project, then again it tries to compile the project files using the compile commands.... Refer to topic in discussion forum: http://forums.codeblocks.org/index.php/topic,7736.0.html I tried looking @ the code couldn't get much in a short span of time..... Do mail me @ prashanth.gopinath@yahoo.com for any further info... Sample log: Example log from "Build Log window" =================================================================================== make[1]: Entering directory `/tmp/alps/src/abstractionLayer/linux64' alpsDateTime.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsDateTime.o alpsDateTime.cpp alpsRandom.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsRandom.o alpsRandom.cpp alpsThreadCond.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsThreadCond.o alpsThreadCond.cpp alpsThreadMutex.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsThreadMutex.o alpsThreadMutex.cpp alpsOsThread.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsOsThread.o alpsOsThread.cpp alpsFile.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsFile.o alpsFile.cpp alpsDir.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsDir.o alpsDir.cpp alpsTransport.cpp g++ -fPIC -Wall -pthread -g -I/home/prashanth/new/src/ -I/home/prashanth/new/src/abstractionLayer/linux64 -I/home/prashanth/new/3rdParty//include -c -o /home/prashanth/new/build/objs/alpsTransport.o alpsTransport.cpp ++++Creating /home/prashanth/new/build/libs/libplatform.so g++ -o /home/prashanth/new/build/libs/libplatform.so /home/prashanth/new/build/objs/alpsDateTime.o /home/prashanth/new/build/objs/alpsRandom.o /home/prashanth/new/build/objs/alpsThreadCond.o /home/prashanth/new/build/objs/alpsThreadMutex.o /home/prashanth/new/build/objs/alpsOsThread.o /home/prashanth/new/build/objs/alpsFile.o /home/prashanth/new/build/objs/alpsDir.o /home/prashanth/new/build/objs/alpsTransport.o -L/home/prashanth/new/build/libs/ -L/home/prashanth/new/3rdParty//libs -shared -Wl,-soname,libplatform.so make[1]: Leaving directory `/tmp/alps/src/abstractionLayer/linux64' -------------- Build: all in al --------------- g++ -c /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp -o obj/Debug/linux64/alpsDateTime.o /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp:7:43: error: abstractionLayer/alpsDateTime.h: No such file or directory /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp:11: error: ALPS_UINT64 does not name a type /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp:16: error: ALPS_UINT64 does not name a type /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp:30: error: ALPS_UINT64 does not name a type /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp:51: error: variable or field alpsIntervalTimer declared void /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp:51: error: ALPS_UINT32 was not declared in this scope /tmp/alps/src/abstractionLayer/linux64/alpsDateTime.cpp:52: error: expected , or ; before { token Process terminated with status 1 (0 minutes, 1 seconds) 7 errors, 0 warnings ===================================================================================
- Category
- Compiler
- Group
- Status
- Closed
- Close date
- 2009-01-29 23:40
- Assigned to
- jenslody
History
I have a close variant of the above one, using the latest / greatest SVN 4977 nightly build.
The workspace contains 5 "native" C::B projects and one "Custom Makefile" project.
As above, when cleaned, built and rebuilt all by itself, the "custom Makefile" projects works fine.
"rebuild workspace" always works flawlessly on all native projects, and always fails on the custome Makefile projects.
In addition, I noticed that the C::B behavior is different according to the project that is active at the moment of the workspace rebuild. In my case, the native projects are the first 5 ones and the custom makefile project is the last one.
When using a workspace rebuild and the active project is the native one at the top, the Makefile is called with "clean" to start with, then the native projects are rebuilt, then C::B invokes gcc (instead of calling the Makefile) and tries to execute a built-in compiler invocation instead of using the Makefile.
When the "Makefile" project (last in list) is the active one, the "Makefile clean" occurs properly, then make is invoked (presumably from the wrong directory) resulting in a "Makefile: No such file or directory" message.
BTW, this bug looks suspiciously like one that was reported before:
[ Bug #11624 ] (re)Build workspace and custom Makefile
This bug is now fixed in HEAD.
Thank you for reporting it.