Thanks for the feedback, would be awesome if you do that. It will be a long discussion until we have somethin.
I'll see if I can quickly comment on some of this.. But, one, we should start a new thread for some of this. And two, I'm putting together some common design notes and such that I'll post a bit later.
Uhm, well, I've been using b2 for a long time and didn't know that was possible. But I guess that would be different in that you wouldn't have feature, but a by-product. I.e. you if you run a test with coverage:(3) Better handling of by-products, compounds & sources
Let's say I build a binary with the coverage information with gcc:
exe foo : bar.cpp : <cxxflags>--coverage <linkflags>--coverage ;
and now I want to access the gcda file. I should be able to do just reference the target like this ('::' because unlike '.' it's invalid in a filename):
alias cov-data : foo::coverage ;
The same would be true I declared a library without defining whether it's static of shared, by writing this:
lib foo : bar.cpp ;
alias shared_foo : foo::shared_lib ;
As for sources, if I could obtain them from the file would be awesome, i.e. the direct targets:
alias objects : foo::sources ; #gives me all the .o files.
Interesting.. How is that different than the target requirements? I.e. foo/<feature>x. Or, for your examples foo/<coverage>, foo/<link>shared (an already existing option), or foo/<sources>.
Well in this particular example no: I have the date of version.cpp from the file signature, and I have the date of the git-hash from the commit-date. So by overloading the condition ("needs-update" in b2) I can use virtual targets etc. I tried that in b2 and it was either impossible or I was to stupid.(4) More generic targets
What I had to do is put the current git-hash into my software, so I ran a script. I built a script for that, but I would like to be able to add something like that to the build system.
We can certainly try and have more basic "building block" types of targets. But the current "make" does do a fair job of capturing most uses of generic targets.
So the thing I'd do (if I had a git-module) is to create a string-target (i.e. the hash) which has the date of the last commit (instead of the date of the last file change):
git-hash my_hash ;
my-generator-script version.cpp : my_hash ;
Not sure what you mean by "string-target". Especially since it sounds like something ephemeral, i.e. only temporary to the current b2 execution. And if you want something persistent then we are talking about a file with whatever content you want in it, i.e. the hash.
Yeah, that wouldn't be easy, but if combined with (3) we could just make the "by-product" mutable during build.
(5) Post-build scanners
Afaik boost.build provides scanners for things like include files etc. to generate dependencies. I'd like to have post-build scanners, which could be used to check additional generated files. E.g. when building java you have additional .class files for each nested class. It would be nice if they could be also collected, so I'd have them not only as dependency but as part of the target, e.g. when I'd want to build a jar.
This would also require to declare "incomplete targets", i.e. a target where I don't know exactly what is the result.
I understand.. But this is not an easy feature to implement. As it essentially means a mutating build graph while one is building. But it could be done with some restrictions.
Well after we had some discussion, I think the smartest thing would be to create a meta-target for the build-tree which may be used in a rule. That could actually work and you would have a sink, where you can use it for any format you like. E.g. "project-root" or something like that:
(7) Target output
That could probably be the easiest concept: the build-system should be able to output all targets with their config to the console, for example as json. This would allow an IDE to see all targets and provide the corresponding settings.
It's not actually "easy" :-) It's easy to describe but not to implement in a usable manner. This is because of the dynamic nature of b2 target descriptions. For integration into IDEs I would lean more towards a library approach. Where the IDE and b2 can be implemented in terms of that library. Not it could be a regular link library, but it could also be a server like API. And depending on the IDE, like VS, I think I like the idea of be reading the IDE project as the basis of the build.
Maybe, though I actally don't have the goal to make it a natural language, I just want to avoid errors because ": : : " was one ":" to few. That why I would add a mark-up for the parameters, sort of like with the project rule. Just shorter.
(3) Declaration Syntax
I would propose a clearer syntax:
lib foo : bar.cpp : <requirement>42 : <default>stauff : <usage>thingy ;
lib foo : bar.cpp : require requirement=42 with-default default=stuff for usage=thingy with other-thingy=other-stuff ;
By with = definition, require = requirement, for = usage-requirement, with-default = default
This feature syntax would be rather clear, and would also allow things like `define+=OTHER_DEFINE` or boolean values to just be passed.
I think we are going to disagree a lot on this area.. As I'm not one for trying to make things structure like natural languages (I particularly detest SQL for example). This will certainly need an expanded discussion. But for now all I'd say is that.. We should avoid departing too far from current syntax as it will cause undue friction to existing users in transitioning to a new version.