On 07/24/2014 11:47 AM, Steven Watanabe wrote:

On 07/24/2014 09:35 AM, Axel Ismirlian wrote:

...

I have been working on boost for about a month now, but I still don't fully understand boost's build configuration very well.

<snip>

I've worked with it for 10 years, and I don't understand it very well.

Each target has three sets of properties: requirements, default-build, and usage-requirements. <snip more good stuff from Steven>

Thanks, Steven! This is good stuff. Are these three sets of properties per target mere convention, or is this something we can count on? And is this written up anywhere? It goes a long way to de-mystifying b2 for me. \e

If I wanted to add a missing property for a particular platform where would I go about doing that? Are the properties initially taken from the OS specifications that boost reads from the machine somewhere or how does that work? Should I make a user-config.jam to add it? I have looked into property-set.jam, property.jam, and feature.jam, but where does their data come from? Sincerely, -Axel From: Steven Watanabe To: boost@lists.boost.org Date: 07/24/2014 01:47 PM Subject: Re: [boost] Understanding Jam Files Sent by: "Boost" AMDG On 07/24/2014 09:35 AM, Axel Ismirlian wrote:

I have been working on boost for about a month now, but I still don't

understand boost's build configuration very well. More specifically, I do not understand where the properties array gets filled in and where that data comes from. I saw the property.jam file which seems to refine the

of properties and take away unmet conditions, and bind dependencies. I also saw the property-set.jam file which creates property lists from raw properties, but where do the raw properties come from exactly? Does every property-set created come through this file?

It would be very helpful if someone could point me in the right

fully list direction.

Each target has three sets of properties: requirements, default-build, and usage-requirements. When you build a target, you pass it a property-set. The properties in this property-set are overridden by the requirements, and the default-build is used to fill in missing properties. For example: exe test : test.cpp : <link>static : <threading>multi ; If you build test with <link>shared, <threading>single, then the requirement of <link>static overrides <link>shared, but the default-build of <threading>multi is ignored, because <theading>single is already present. In addition most features have a default value and properties can be specified on the command line. When building dependent targets, all features with the propagated attribute will be passed on to the dependencies. For example, given: obj test.o : test.cpp ; exe test : test.o : <link>static <define>BOOST_ALL_NO_LIB ; test.o will be built with <link>static, but not -DBOOST_ALL_NO_LIB. property-set.jam, property.jam, and feature.jam contain the various functions for the low-level manipulation of properties. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

So if I wanted to write a user-config.jam, will just simply placing it in the same place as where the project-config.jam cause boost to detect the user-config.jam? Basically, the property that my platform is missing is the <addressing model>. In other platforms I have seen this property as <address model>32 and <address model>64, but on aix the tag doesn't even show up. It just doesn't exist for whatever reason. Do you think writing a user-config file where I add it manually is worthwhile? Because with the user-config file I could also just simply write the flags I'm passing in as part of my build right? That in my opinion would make the most sense. Sincerely, -Axel From: Steven Watanabe To: boost@lists.boost.org Date: 07/25/2014 04:42 PM Subject: Re: [boost] Understanding Jam Files Sent by: "Boost" AMDG On 07/25/2014 02:59 PM, Axel Ismirlian wrote:

If I wanted to add a missing property for a particular platform where

I go about doing that? Are the properties initially taken from the OS specifications that boost reads from the machine somewhere or how does

would that

work?

A feature can have a default value which is determined when the property is defined (see builtin.jam). If a feature has no value when building a target, then it must have been declared as optional. Properties can be specified on a target, for a project (including user-config.jam), or on the command line.

Should I make a user-config.jam to add it?

It depends on what you're trying to achieve.

I have looked into property-set.jam, property.jam, and feature.jam, but where does their data come from?

In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 1/08/2014 12:31 PM, Steven Watanabe wrote:

<address-model> is left blank unless it's explicitly specified by the user. I believe the way it's handled is - if address-model is specified, then pass whatever flags you need to the compiler - otherwise, use the compiler's default.

If you always want this flag or you always want it for a specific toolset,

That's me. I always want it for msvc on my own machine.

then I suppose it makes sense to set in in user-config.jam.

How do I do that? I tried: using msvc : : : <address-model>64 ; to no effect. [Off topic rant: over the last couple of days I have suffered the cruel and unusual punishments that microsoft has devised for people who build for 32-bits and run on 64-bits. The code runs okay for a while, and then fails as soon as it gets a chance to present as a really "interesting" bug involving virtual inheritance. Then you try your chances in the Visual Studio debugger, which says that no RTTI data is present, when it really means that it doesn't allow watches that depend on RTTI, but you take it at its word as you run around in circles saying "Who turned off RTTI support?".] --- Michael