Re: [Boost-build] The future of B2?

Subject: Re: [Boost-build] The future of B2?
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-13 14:38:35

Well... It's certainly something to discuss further :-)
>
> 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.
>
Thanks for the feedback, would be awesome if you do that. It will be a 
long discussion until we have somethin.
>
>     (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>.
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:

exe foo : bar.cpp : <coverage>on ;
run foo_run : foo ;  # yeah different rule

The secundary target `foo_run::coverage` (or with any other syntax) is 
already declared (as .gcna) and does not depend on a feature. That is:

exe foo : bar.cpp ;
run foo_run : foo  ;

would not give a valid target `foo_run::coverage`, while 
foo_run/<coverage> probable would.

>     (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.
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.
>
>     (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.
Yeah, that wouldn't be easy, but if combined with (3) we could just make 
the "by-product" mutable during build.
>
>     (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.
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:

print-json /project-root ;
build-server-info /project-root ;
>
>
>     (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.
>
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.
Also: I'd break the syntax completely, since it will work differently, 
people will have to redo their build-files. If you have a different 
sytnax, the users will assume different beheviour, while that won't be 
the case with similar syntax.