Re: [cdt-dev] Managed Build rebuilding whole folder when options of one

[Christian Walther <walther@xxxxxxxx>]

Thanks Torbjörn for your thoughts.

> As far as I can remember, we had issues where changing the flags on project level did not actually rebuild the object files without the dependency on subdir.mk.

OK. I can’t reproduce that in the simple Linux Hello World example, but it may well occur in more complex projects (and I’m trying this in our own product that has more CDT patches, not in an otherwise unmodified CDT). I also don’t recall having seen that problem myself in real-world projects when we were on older CDT versions, but that may not mean much.

> I can see the problem when changing optimization on a certain file would cause all files in that directory to be rebuilt, but on the other hand, there is no real way for make to know what was touch only affects that particular object file. Sure, there can be logic in the java code that would remove the file etc, but how would you handle the link step in that case?

I’m not sure what you mean. Why should the link step be different? When an option affecting the link step changes, the Java rebuildState logic removes the ELF executable file (the output of the link step). As far as I can see, it does do that properly in the Hello World example.

> Lets say that you have some flags on the toolchain level that have an impact on all the compiler invocations and the link step. Without the dependency on the subdir.mk, then it will be hard for make to know that all compile units needs to be rebuilt to get the correct result.
> Maybe this is a corner case, maybe it's not, but if feels right to have a dependency on the set of flags in some way for the object file. If you have any other idea on how to solve this with make, then let me know.

Yes, it is hard for make to know, which is why CDT was apparently designed to not have make know it, but to have the Java code know it and convey the information to make by deleting output files. I totally agree it feels right to have make do it with the dependency, it’s certainly simpler and clearer than all that complicated magic Java code. I actually liked the change when I first integrated it, it’s only now that I see that it causes a regression in one particular case.

But no, I haven’t come up with a good way of solving my problem of too many rebuilt files, given that we want the dependency. A possibility might be to split subdir.mk up into several files, one for every make rule (i.e. one each for every source file with specific settings plus one with the wildcard rule for all other files in the folder). But that may get unwieldy and I hesitate to stir up the complicated Managed Build system that much for what is arguably a corner case.

> I also have some vague memory that had something to do with changing the toolchain version should trigger everything to be rebuilt and not just re-linked, but I could be wrong on this point.

OK. That wouldn’t affect us, as we are using a single CDT-level toolchain that never changes and delegate to different actual toolchains in a separate custom layer (whether that was a good idea is debatable, we are hitting some limitations of that approach in the meantime, but for now it is what it is).

I’ll think about what to do in our product, but unless other CDT integrators or users think the regression I observed is a real problem, there is probably no need to change anything in CDT itself.

 -Christian


-- 
Indel AG
Christian Walther - Software
Tuefiwis 26
CH-8332 Russikon
Switzerland

Tel.: +41 44 956 20 00
www.indel.ch
------------------------------------------------------------------------------------------
New product GIN-MAX4x4: The compact 4-axis motion board now also available as PRO version!
https://www.indel.ch/en/products/drives/compact-motion-drives