Bug (usability) with custom makefiles and clickable errors

[cellulose]

I started to write this as a post to "Using Code::Blocks":

Hey all.  I'm using a SCONS script to autodetect my source files and build my code on all my platforms.  Previously I was using Code::Blocks for Windows, make for Linux and Xcode for mac, which was getting to be a hassle.

Anywho.  Everything is lovely and the integration works quite well but for one thing.  Errors from the compiler are caught and inexplicably have a period inserted at the beginning of the filename string.  So if the compiler whines,

Code

src\uber_world.cpp: In member function 'void uberleben::World::worldUpdate()':
src\uber_world.cpp:76: error: 'BOOGERS' was not declared in this scope

Code::Blocks reports:

Code

.src\uber_world.cpp|76|error: 'BOOGERS' was not declared in this scope

Note the folder name ".src" (whereas my sources are in src/)


Various suspicions I've more or less disproved were that it stemmed from my compiler's UTF-8 output (which, happily, I fixed while investigating) and that it had to do with SCONS converting the paths from foreslashes to backslashes and in some cases resolving them to absolutes -- the console output clearly shows the relative path, though.

Anyway.  Here's hoping this is something silly.

And, wouldn't you know it.  Had a eureka just after typing that, and changed the makefile "execution directory" from "." to "./".  It's probably worth addressing that gotcha in future versions.  I tried the "browse" feature, keeping the pathname relative and got "../dev" as the entry.  When compiling, the errors showed up as located at "../devsrc/uber_world.cpp".  The error list seems to be the only thing affected.

[oBFusCATed]

Can you provide a simple project or the exact steps to reproduce the problem?

[cellulose]

I think so.

1.  Start a new project and create a makefile in the same folder.  (I'm using the stable 10.05 release)
2.  Configure the project to use a makefile, selecting the execution directory (the project directory) via the "browse" command and choosing to keep the path as relative.
3.  Write a simple piece of code with an error introduced.
4.  Configure the makefile (which should be in the project directory) to build that code.  Use relative paths in the makefile such as "src/broken.cpp".  (I use one with a dot, but scons removes it)
5.  Observe the results in the error pane. (the execution directory "." being prepended to the makefile's location for the file, "src/broken.cpp" for a result ".src/broken.cpp" which breaks error shortcuts.)

Adding a trailing slash to the makefile execution directory fixes this, however it's far from obvious or the fault of the user.

[Jenna]

Confirmed and (hopefully) fixed in trunk, svn r7367.

[oBFusCATed]

Are you 100% sure that project->GetExecutionDir() is always non-empty?
If it can be empty, your fix is wrong...

[Jenna]

Are you 100% sure that project->GetExecutionDir() is always non-empty?
If it can be empty, your fix is wrong...

project->GetExecutionDir() returns either the projects base-path, or the makefiles execution-dir.
If the base-path is empty, the project is in the root-folder and the fix is correct, if the makefiles execution-dir is empty, it defaults to the projects base-path.

[cellulose]

Thanks for the fix!

[Calmarius]

I think I'm affected by this bug too. I cannot open source files from the message windows because the file path is wrong. The only workaround is putting symlinks everywhere. The another would be hacking into the makefile but I don't want to do that.

The path CB shows is something like:

<relative path to the makefile>/<relative path to the makefile again><file path which gcc shows>

Was this the bug you fixed? I'm using the CB 10.05 for Linux.

When will the next stable release is planned to come out?

[Jenna]

I think I'm affected by this bug too. I cannot open source files from the message windows because the file path is wrong. The only workaround is putting symlinks everywhere. The another would be hacking into the makefile but I don't want to do that.

The path CB shows is something like:

<relative path to the makefile>/<relative path to the makefile again><file path which gcc shows>

Was this the bug you fixed? I'm using the CB 10.05 for Linux.

Most likely, but without a project where it fails for you, I can not test.

When will the next stable release is planned to come out?

As soon as possible  .

Depending on the platform you use, there might be nightly (or weekly or whatever) builds, that are normally stable enough for productive work.
I provide packages for debian (that should work on most ubuntu systems) and for Fedora 15-17 and RedHat/CentOS 5 and 6 (sse my sig).


For ubuntu, you can also use pasgui's ppa : https://launchpad.net/~pasgui/+archive/ppa/ .
If you use this, there should not be any compatibility issues, because of differences between debian and ubuntu distros.

[Calmarius]

Most likely, but without a project where it fails for you, I can not test.

Reproduction is easy though:

- Download something from a source control which uses a makefile.
- Create an empty project somewhere else. Not under the source control root directory, becuase you do not want to confuse it (frequent use case in practice!)
- In the project properties window, select you want to use a custom makefile.
- Set execution directory respectively.
- Make it and see the warnings.

The makefile does not necessarily invoke CC from the directory you called the makefile (aka makefile may call cd):

Example:

I have a makefile at <vcs root>/build_scripts and I set the working dir path for it.

So CC may say warnings about the blahblah/foo.c which is at <vcs root>/sources/blahblah/foo.c and the makefile is at <vcs root>/build_scripts/makefile.
So the makefile does a cd to the <vcs root>/sources/ directory and start compilation from there.

The problem is, that C::B tries to find out where are the source files, and wants to be clever by thinking it's at <vcs root>/build_scripts/blahblah/foo.c which is incorrect.

So I would like to see and option where I can set explicitly <vcs root>/sources as a search path for the IDE. So when blahblah/foo.c warning comes up the IDE can search it at <vcs root>/sources/blahblah/foo.c. The option should be able to list multiple search directories (for more exotic makefiles...)

[Jenna]

I use Makefile based projects regulary, if I develop for wxWidgets.
I have several flavours of wxwidgets (gtk2, gtk3, dynamic aui-branch for gtk2 and gtk3) and develop in it.
I use a sepearate build-folder (my_build_gtk2, my_build_gtk3) from where I run the configure script and where thge makefiles are generated.
This is a necessary step to create the intermediate files there, of course.

If I get errors or warnings, there aren't any issues jumping to the correct sources.

My projects base-path is the root-path of the sources and the Makefiles execution-dir is my seperate build-folder.

I just tested the same with the C::B automake-stuff and it also works flawlessly.

[Calmarius]

And how does CB locate the files? Does it parse and understand the makefile? Searches the filesystem?

[MortenMacFly]

And how does CB locate the files? Does it parse and understand the makefile? Searches the filesystem?

It runs make on your Makefile(s). As simple as that. A Makefile should declare all needed files 7 path's / libs / flags and alike. That's what a Makefile is for. If you Makefile is incomplete, the build will be incomplete. That applied to all other Makefile based projects in the world, with or without IDE.

[Calmarius]

There is no problem with the makefile.

The problem is that the makefile changes the working directory during the build. If there is an error or warning, CB stupidly assumes the problematic file is at <makefile_path>/<path_the_gcc_reports> if the working directory changes during the build the path will be incorrect, and I cannot open the file by clicking the error or warning message. The same applies when I try to debug, the IDE cannot open file.

Changing the makefile to make CB happy is not an option.

[Jenna]

There is no problem with the makefile.

The problem is that the makefile changes the working directory during the build. If there is an error or warning, CB stupidly assumes the problematic file is at <makefile_path>/<path_the_gcc_reports> if the working directory changes during the build the path will be incorrect, and I cannot open the file by clicking the error or warning message. The same applies when I try to debug, the IDE cannot open file.

Changing the makefile to make CB happy is not an option.

If you have a proper makefile-based build-system (with incremental makefiles) it works correctly.
Just tried it with C::B's makefile stuff on linux.

If the makefile internally changes the directory, there is no way for C::B to know that (except parsing the makefile's output, but this is obviously not an option).