Boost logo

Boost :

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-22 04:18:04

On 6/21/17 2:57 PM, Steven Watanabe via Boost wrote:
> AmDG
> On 06/21/2017 09:23 AM, Robert Ramey via Boost wrote:
>> All these are fruit of the idea that - we, the developers of bjam can
>> figure out what you need so the build will be really simple. To fix
>> bjam this idea has to be set aside. All of the linkages to other stuff
>> in the file system should be replaced by either data in the jamfile or
>> if not in the jamfile better yet runtime switches so the command syntax
>> would look like
>> b3 toolset="asfasfa" variant="12321" etc.
>> Which would respond with:
>> build failed, errors found:
>> toolset "asdfasdf" not found
> ERROR: rule "asdfasdf.init" unknown in module "toolset".
> (Okay, I admit that's quite cryptic)

>> variant must be either "debug" or "release"
> error: "12321" is not a known value of feature <variant>
> error: legal values: "debug" "release" "profile" "debug-python"

>> no jamroot specified in either jamfile or command line
>> ...

> error: no Jamfile in current directory found, and no target references
> specified.
> -------
> error: Could not find parent for project at '.'

that's pretty cryptic

> error: Did not find Jamfile.jam or Jamroot.jam in any parent directory.

> Also: 'b3' is not recognized as an internal or external command,
> operable program or batch file.
Of course, I was refering to the next bjam version

Note that my post made the complaint that if you leave the options
unspecified, the system just fills them from .... = who knows were.

It would be better to not do this and just print the error message:

need to specify root with -?
need to specify toolset
need to specify variant
need to specify linkage

Of course if the user then specifies the optiones erroneously as I did
above, the error messages are sort of OK and he knows what to look into.

The current sitation is that he gets some sort of message and WTF?
Worse, he changes the environment slightly - such as user login which
points to a differnt user-config.jam or some environmental variable he
doesn't remember, or removes some file he doesn't remember he gets
different behavior and has no clue why. These are effectively hidden
global variables affecting the build system. It can take days to track
down the source of errors like this.

Maybe as an experiment one might consider adding yet another switch -
-no_defaults and see how that works out.

Robert Ramey

> In Christ,
> Steven Watanabe
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at