C::B calling gcc on a "custom Makefile" project when workspace building?

[filofel]

Hi All,

I'm running into a strange problem using C::B on a workspace that contains 5 "regular" projects (that use C::B built in make) and one "Custom Makefile" project. I have set up the "This is a custom Makefile", and properly config'd my ""Make" commands". Just in case, I defined the "Selected build target options" for that Makefile target with "Platforms" as "Unix" only and type as "Commands only" (but other options don't seem to work better).

When I build or rebuild each project separately, everything works great for each and every one of the all 6 projects.  When building or rebuilding the "custom Makefile" project, it is compiled using its Makefile just like it should: Rebuild calls the Makefile with a clean, then a second time with with no parm, and a valid target is built. So far, so good.

Now when I "workspace rebuild" (or "workspace build"), the 5 regular projects build fine, but C::B erroneously tries to compile the "custom Makefile" project by invoking gcc all by itself - instead of invoking the Makefile. That of course is doomed, and ends up with lotsa red lines in the log.

Even stranger:
When I workspace rebuild, the "make clean" part is done properly like it should (i.e. C::B starts the workspace rebuild by calling the Makefile of the "custom Makefile" with the "clean" option). But later, at the end of the build phase, it still tries to compile the "custom Makefile" project by itself instead of calling the Makefile a second time with no option like its Make command line says.

I'm currently using C::B nightbuild 4977.
Did anyone see this behavior already, and should I report this as a possible bug, or is there something that I could have config'd wrong that could trigger this?
Conversely, did anyone successfully tried to use a similar workspace of "mixed type" projects?

TIA,

Phil.

[filofel]

Still trying to solve that same problem:
Is there a way that I missed to completely disable the compiler selection? 
I see that the cbp file contains "Compiler" and "CompilerVar" definitions, which makes little sense and have no use in a custom Makefile. Disabling all platforms ain't it, since then, no build at all ever occurs (no platform for this target).
It doesn't make sense to have any compiler set here, as compilation / linking is handled inside the Makefile. And since this specific project in the workspace is compiling a kernel module, there's no way I can turn this into a "native" built-in C::B make:  I have little choice but letting the Kbuild system do the job.

OTOH, the problem I see seems more like a bug in the rebuild when called from the workspace rebuild, since the *project* rebuild does not exhibit this erroneous behavior and only invokes the Makefile like it should...

[filofel]

Wrap up on this one, that now definitely appears as a bug:

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" project works fine.

"rebuild workspace" always works flawlessly on all native projects, and always fails on the custome Makefile project.
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.

A similar problem has already been reported 2008-Feb-03 on 18:56, as
[ Bug #13070 ] With Custom makefiles, "Build workspace" option throws error

I have added the above text as a followup / comment to the existing bug report.