Improve expand rule

[jimon]

Now if you write something like build objects(build/*): auto src1/*.c src2/temp.c you will get ValueError: cannot expand rule cc because of different amount of explicit generated targets and explicit inputs ... which is just bad UX. We really need to improve it!

[Mucka]

I have simple question. In given example build objects(build/*): auto src1/*.c src2/temp.c, how to properly achieve this ? I mean, I want to add a single file from src2 to every file from src1 and compile it together. It this possible to write such generic statement in current version ?

[jimon]

@Mucka at the moment what we are doing is something like this :

build objects(build/src1/*): auto src1/*.c
build objects(build/src2/temp): auto src2/temp.c
build application(build/app): auto objects(build/**/*)

where build/srcX/ is needed so if we two files with the same name temp.c in src1 and src2 - object files to not collide.

This should be fixed later on. Currently we are testing build system extensively in our hobbie projects to see what we like and what we want to change.

[Mucka]

Thank for your answer! I have system with lots of unit tests. And every module have multiple files with tests grouped like: test/unit/<module>/test_<name>.c and each of such file need to be linked with src/<module>.c. So I thought if I can write build application(build/test/unit/**/bin/*): auto objects(build/test/unit/**/obj/*) objects(build/obj/*) or something similar to achieve such behaviour (with expand turned on in custom rule or something). Something like this works with implicit inputs, so I understand I need some mix of explicit and implicit input functionality. I even tried solution where I write one line in script per module like build application(build/test/unit/example/bin/*): auto objects(build/test/unit/example/obj/*) objects(build/obj/example.c) but it still do not works, so I will now try to somehow adapt your answer to my needs.

[jimon]

@Mucka Can't all of them just be linked together? Or you get linker conflicts? Usually unit tests are just separate object files that all end up in one application.

[Mucka]

@jimon For now, every each test have separate main function and eventually ends as separate application. This is embedded application, test were designed to be as small as possible, to be able to run them on hardware eventually, for now the unit test platform is qemu so this is not necessity. The unit test platform is custom stuff based on ThrowTheSwitch/Unity.

[jimon]

Ah ok, indeed this use case is not really trivial for our build system :\ Maybe it's feasible to put every object + test case for it in separate folder? So you can build them folder by folder case. And then build a final application by getting all object files recursively and ignoring specific prefix (test_) in the path. You can ignore by doing something like build ... : auto "path/!(test)_*.c"