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

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-26 12:57:27

On 26.10.2016 10:42, aaron_at_[hidden] wrote:
>
> 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.

It would really be great to have a place to collect such features
(actually "requirements" would be more appropriate in this discussion, I
suppose), so any new effort has some metric to measure its success against.

> 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.

I understand what you are saying, as I have had similar experience in
the past.

>  
> 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.

I think we are all pretty much in agreement: Make the default language
declarative, but support ways to extend that. I'm not entirely sure how
much effort we should put into making it difficult to extend with
non-declarative code. I'd rather opt for making the declarative parts as
intuitive and feature complete so (most) users don't have to use
extensions. I know, that sounds easier than it is...

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...