Re: [Boost-build] [future] Implementation language(s)..

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: aaron_at_[hidden]
Date: 2016-10-26 10:42:52

> I don't see any reason to actively prevent code-logic at any point. 
> Unless there's some systemic flaw to such a consideration I have 
> yet to understand.
>
> If the user doesn't need any logic in their declaration, they don't
> need to use any.
 
At our company, we have somewhere over 400 developers. There are quite
a few that are fresh college grads and only know how to write C code, but
know nothing about how to build it. It's not uncommon to get questions about
compiler or linker errors as if it's the build system's fault: "why is Boost failing?"
 
Before we switched our products over to Boost.Build, there was
an in-house build system written in Perl. It worked just fine when the projects
were small, but as they grew, new "features" needed to be added to
the build system in order to support the product. Whenever the build system
wasn't working for some particular situation (e.g. some file is not being updated
properly), *the developer would hack up the build system to force their situation to work*.
One file was not being updated properly, so they would forcefully "touch" one of its
dependencies during setup so that the target would be rebuilt, completely
circumventing the build system.
 
It's been my experience that there is a huge difference between a developer
and a build system expert. Most developers (here, at least) know nothing 
about build systems, nor do they care to learn. So, it's not that they don't
*need* logic in their declarations, it's that they *don't know they don't need* logic
in their declarations.
 
While it provides much more power to the build expert to allow for logic to be
with the declarations, it makes it much easier for everyone else to shoot themselves
in the foot.
 
Having said that, I'd vote for making target declarations, by default,
more declarative (without logic) while still providing the build experts their
power by providing an underlying target creation API. This is similar to what
I have experimented in the b2 Python port with when using the
YAML/JSON/XML files to declare targets. The target declaration file, while
not as powerful, can cover about 90% of target creation. When that extra
power is needed, the declaration file can reference a Python script that can
make use of the already-existing target declaration API.