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
> 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk