Re: [boost] [cmake] Minimum viable cmakeification for 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)

LOL
> 
>> 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"

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

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: http://lists.boost.org/mailman/listinfo.cgi/boost
>