> Aaron, could you send us a sample of your YAML/JSON target declarations?

> Does it support defining the rules that are referenced by <conditional>s?

 

Just a reminder that this was just an experiment on a small project, so I never got to supporting

larger features like <conditional> properties, however, it shouldn't be hard to update <conditional>

to point to some qualified Python module name (which will *not* be defined in an YAML/XML/JSON project file).

Having said that, the rough format looked something like this:

 

# project declaration
project:
    name: dev
    requirements:
        - <define>FOO

# "target-name" is the name of the target
# and contains a mapping for each of the possible
# metatarget attributes.

targets:
    - target-name:
        type: LIB
        sources:
            - hello.c
            - /libs//foo
        requirements:
            - <link>static
            - <toolset>arm:<define>ARM_SOMETHING
        usage-requirements:
            - <use>/libs//bar

Similarly, an example of the XML format

<project name="dev">
    <requirements>
        <define>FOO</define>
    </requirements>
    <targets>
        <target name="target-name" type="LIB">
            <source name="hello.c"/>
            <source name="/libs//foo" />
            <source name="special">
                <requirements>
                    <define>BAR</define>
                </requirements>
            </source>
            <requirements>
                <link>static</link>
                <condition>
                    <when>
                        <toolset>arm</toolset>
                    </when>
                    <value>
                        <define>ARM_SOMETHING</define>
                    </value>
               </condition>
           </requirements>
           <usage-requirements>
               <use>/libs//bar</use>
           </usage-requirements>
        </target>
    </targets>
</project>

I have barely spent any time on this as I was only curious if it were a possibility, so I'm not sold on the structure of the above

(it's ugly, I'll admit).

Most of the developers I work with have an allergy to Jam and I was looking for an alternative for target loading since the Build

System is the best I've ever used and I'm trying to explore ways to help pacify those developers so that we can keep using

this build system. Note, however, that data formats as these can't take advantage of helper rules like "glob" (yet).

 

> I'm concerned that we are discussing the implementation language without firming up the requirements of the downstream

> components, e.g. IDE integration.

 

Unless I'm missing something (feel free to tell me), the target declarations are just declaring the metatargets and thus

setting up the initial dependency tree. As far as I know, this should just be data irrespective of what is done with it

(like working with an IDE).

 

> Does a VS solution or project file act as an alternative to Jam/YAML/JSON?

No, mostly because the project files don't support all of the functionality that b2 supports. Although,

if you're only interested in building for MSVC, it shouldn't be too hard to take an existing vcxproj

file and use it within b2 to setup targets. It's an XML file (easy to parse with Python) and the functionality

that it supports is a subset of b2's features. This could be a custom loader (see below).

 

> If not, then the user still has to write Jam/YAML/JSON by hand, right?

Yes.

 

Again, I just wanted to share some other possibility for reading in targets and I haven't come up with some concrete format.

Because of that, we're still using Jam. However, I do want to mention that this is where I really like the idea of extensions.

I'm imagining that during the project loading a user can specify a custom Loader() to use. Jam could be default and other

custom Loaders could be provided (pip install-able packages) in order to load YAML/JSON/XML/INI/CUSTOM files.