[Boost-build] A question on propagating "features"

Subject: [Boost-build] A question on propagating "features"
From: Thomas Brown (tabsoftwareconsulting_at_[hidden])
Date: 2019-04-27 00:53:02

Hi all,

I'm not sure if this is the right terminology for this, so bear with
me.  I've asked a few questions around this earlier as I've been
trying to get this finished.  I am just about through it but I have a
few problems.

I have published it on GitHub here:
https://github.com/tee3/boost-build-xilinx  Unfortunately, it requires
that the Xilinx SDK is installed to try it out, so while there are
example projects that do build, there's a high bar for testing it
yourself.  If someone is interested, I'd be happy to help get them set
up.

The main component is an xsdkws (the workspace), which contains the
hardware description (headers, sources and tools), a board-support
package (headers and libraries for hardware-specific features and
target operating systems and properties), and application templates
(linker scripts).

I have several issues (that I know of) remaining before I can really
use this in production.  I can almost build arbitrary applications
with it.

A.  Even when an exe has a workspace as source, Boost.Build will
attempt to compile and link before the building the workspace has
completed.

xsdkws ws : hw.hdf ;
exe example : main.cpp ws ;

As I write this, it makes sense because main.cpp does not actually
depend on ws except for the includes.  How can I achieve this?  I feel
like I should have used <implicit-dependency> somewhere or maybe a
scanner?

B. I don't understand how I can propagate this information to other
components.  For example, if I want to link to another library defined
in a separate Boost.Build project, I'd like that library to be built
for the workspace's properties without having to go edit the library
build definition in the other project.  I've tried to request build
properties using the `/` syntax (eg, something like using
`<library>project//liba/<use>ws` as a source where `ws` is a workspace
as a requirement of an exe), but it didn't work.  I've used that
before so maybe I just had the wrong syntax.  Can this be done?  What
is the correct approach for this?

C. The Xilinx SDK provides compilers for the processors it supports
and I would like to configure these toolsets for the user.  As it is,
I require the user to configure the toolsets (given the root from the
configured xsdk) and conditionally require that toolset for the
correct instruction-set.  It's a bit of configuration that I would
like to provide.  Unfortunately, I've had several problems trying to
achieve this.  First, I could not use a `using gcc;` within xsdk.jam.
Second. I could not change the toolset using usage requirements. I can
actually change the toolset in the workspace generator and it will
appear in the directory, but the original toolset configured will be
the toolset used.  Is it possible to do any of this?  I'm guessing not
since toolset can not be used as a usage-requirement

D. On a separate note, not every <architecture> or <instruction-set>
that I need is defined and some that are defined are not implemented
in a toolset.  Is there a way to extend a toolset to support an
<instruction-set> not implemented without modifying the toolset file
(eg, gcc.jam)?  I have extended the instruction-set feature for
additional processors, but of course existing toolsets do not know
about them.  I tried to add to a toolset from the xsdk.jam file, but
this is not valid.  As I currently understand it, I would have to
propose the change to Boost.Build and depend on the absolute newest
Boost.Build to add an instruction-set. For something non-standard,
such as a floating-point unit, I would have to add a feature to
Boost.Build and support in all relevant toolsets, correct?  Should I
just go for that approach?

Thanks for reading through this if you do, it was pretty long.

Best,
Tom