Giter Club home page Giter Club logo

Comments (19)

pdimov avatar pdimov commented on June 30, 2024

One easy way to fix that would be to add

<architecture>arm,<target-os>darwin,<toolset>clang:<build>no

to the boost_stacktrace_from_exception requirements.

That's not quite right because we'd ideally want to be able to override this via boost.stacktrace.from_exception=on, but this isn't possible currently because on is the default value of this feature, so we can't know whether it was explicitly given.

If we really care about that, we can change this to

feature.feature boost.stacktrace.from_exception : default on off : optional propagated ;

and then add <boost.stacktrace.from_exception>default to the conditions above.

I'd like to have this fixed because it breaks the boostorg/boost CI at the moment, so comments are appreciated.

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

Or perhaps, given that according to #163 the feature never works on non-x86 by default, the right incantation would be

<build>no
<boost.stacktrace.from_exception>on:<build>yes
<architecture>x86:<build>yes

?

Not sure. @grisumbras any comments?

from stacktrace.

grisumbras avatar grisumbras commented on June 30, 2024

Optional features aren't added to the property set by default, so if there is <boost.stacktrace.from_exception>on in the property set, then it was explicitly added.

And wouldn't your suggestion add both <build>no and <build>yes to the property set? It should probably use a conditional property with a rule

rule build_from_exception( props * )
{
  local result = [ property.select <build> : $(props) ] ;
  if $(result) { return $(result) ; }
   
  local enabled = [ property.select <boost.stacktrace.from_exception> ] ;
  switch $(enabled:G)
  {
    case on:   return ;
    case off:  return <build>no;
  }

  if [ property.select <architecture> ] != x86
  {
    return <build>no ;
  }
}

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

And wouldn't your suggestion add both <build>no and <build>yes to the property set?

I thought b2 was smart enough to figure out that the more specific one of these takes precedence.

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

Yes, I just tried

    <build>no
    <architecture>x86:<build>yes
    <boost.stacktrace.from_exception>on:<build>yes

and it works as I expected.

This is not quite correct though because it doesn't handle <boost.stacktrace.from_exception>off correctly, it should be

    <build>no
    <architecture>x86:<build>yes
    <boost.stacktrace.from_exception>on:<build>yes
    <architecture>x86,<boost.stacktrace.from_exception>off:<build>no

I think.

from stacktrace.

grisumbras avatar grisumbras commented on June 30, 2024

To be honest, this looks too cryptic, so I'd still choose the rule.

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

Eh, with the additon, no dice

C:/boost-git/develop/tools/build/src/build\targets.jam:1133: in evaluate-requirements from module targets
error: Can not evaluate conditional properties <architecture>x86,<boost.stacktrace.from_exception>off:<build>no <architecture>x86:<build>yes <boost.stacktrace.from_exception>on:<build>yes <conditional>@Jamfile<C:\boost-git\develop>%Jamfile<C:\boost-git\develop>.clang-darwin-cxxstd-11 <conditional>@Jamfile<C:\boost-git\develop>%Jamfile<C:\boost-git\develop>.handle-static-runtime <conditional>@Jamfile<C:\boost-git\develop>%boostcpp.deduce-address-model <conditional>@Jamfile<C:\boost-git\develop>%boostcpp.deduce-architecture <conditional>@Jamfile<C:\boost-git\develop>%threadapi-feature.detect <conditional>@object(check-target-builds-worker)@10081%check <python>2.7,<target-os>windows:<python.interpreter>C:/Python27\python <python>3.9,<target-os>windows:<python.interpreter>C:/Python39\python <target-os>linux:<library>/C:/boost-git/develop/libs/stacktrace/build//dl <toolset>como-linux:<define>_GNU_SOURCE=1 <toolset>como:<link>static <toolset>msvc,<runtime-link>shared:<threading>multi

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

The rule is way more cryptic to me, but I don't care one way or the other, as long as it works.

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

Have I mentioned that each time I encounter an optional property, it doesn't quite work?

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

Your rule, after I fix the seven or so syntax errors, doesn't seem to work.

from stacktrace.

grisumbras avatar grisumbras commented on June 30, 2024

Fixed version:

import property ;
rule build-from-exception ( props * )
{
    local result = [ property.select <build> : $(props) ] ;
    if $(result) { return $(result) ; }

    local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
    switch $(enabled:G=)
    {
        case "on" :  return ;
        case off  :  return <build>no ;
    }

    local arch = [ property.select <architecture> : $(props) ] ;
    if $(arch) && ( $(arch) = x86 )
    {
        return <build>no ;
    }
}

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

I don't think this works either; we want <build>no when the architecture isn't x86, not when it is.

And separately, when I tried a fixed version of your previous suggestion, b2 build boost.stacktrace.from_exception=on didn't build the library for some reason.

from stacktrace.

grisumbras avatar grisumbras commented on June 30, 2024

The reason my original rule didn't work is exactly because it returned <build>no when <architecture> was not in the property set. It went like this:

  1. My rule is evaluated, it returns <build>no because no <architecture>.
  2. boostcpp.deduce-architecture is evaluated, it returns <architecture>x86.
  3. My rule is evaluated again with the updated property set. The property set has <build>no from step 1, so that's what it is returning.

The fixed rule in step 1 doesn't return <build>no if no <architecture>, so on step 3 it can see that the architecure is in fact x86.

Since all targets in Boost tree have <conditional>@boostcpp.deduce-architecture, this will work for all deducible architectures. For non-deducible architectures I don't have a solution, I'm afraid.

Well, I do: make a config check:

import property ;
import configure ;
import boostcpp ;
rule build-from-exception ( props * )
{
    local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
    switch $(enabled:G=)
    {
        case "on" :  return ;
        case off  :  return <build>no ;
    }

    local arch = [ property.select <architecture> : $(props) ] ;
    if $(arch) && ( $(arch) = x86 )
    {
        return ;
    }

    local filtered = [ boostcpp.toolset-properties $(props) ] ;
    local deduced = [ configure.find-builds "default architecture" : $(filtered)
        : /boost/architecture//x86 ] ;
    if $(deduced)
    {
        return ;
    }

    return <build>no ;
}

Do we want to go there?

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

Why didn't you post a working version of the previous rule? Is it

rule build-from-exception ( props * )
{
    local result = [ property.select <build> : $(props) ] ;
    if $(result) { return $(result) ; }

    local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
    switch $(enabled:G=)
    {
        case "on" :  return ;
        case off  :  return <build>no ;
    }

    local arch = [ property.select <architecture> : $(props) ] ;
    if $(arch) && ( $(arch) = x86 )
    {
        return ;
    }

    return <build>no ;
}

?

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

No, that doesn't work either :-)

from stacktrace.

grisumbras avatar grisumbras commented on June 30, 2024

Why didn't you post a working version of the previous rule?

#165 (comment) worked for me. Note, that I edited it after posting (it had a typo).

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

I don't see how

    local arch = [ property.select <architecture> : $(props) ] ;
    if $(arch) && ( $(arch) = x86 )
    {
        return <build>no ;
    }

can possibly work, since it checks the wrong condition (= instead of !=).

We want to build when the architecture is x86, not when it isn't.

It "worked" because = x86 is never true because of the missing :G=.

This one seems to work for me, although I'm not sure how to test it for non-x86:

rule build-stacktrace-from-exception ( props * )
{
    local build = [ property.select <build> : $(props) ] ;
    local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
    local arch = [ property.select <architecture> : $(props) ] ;

    if $(build)
    {
        return $(build) ;
    }

    switch $(enabled:G=)
    {
        case  "on" :  return ;
        case "off" :  return <build>no ;
    }

    if $(arch) && ( $(arch:G=) != x86 )
    {
        return <build>no ;
    }
}

from stacktrace.

grisumbras avatar grisumbras commented on June 30, 2024

Sorry for the garbage I posted before. This one I tested with
b2 libs/stacktrace/build (builds), b2 libs/stacktrace/build boost.stacktrace.from_exception=on (builds), b2 libs/stacktrace/build boost.stacktrace.from_exception=off (doesn't build), b2 libs/stacktrace/build architecture=arm (doesn't build), b2 libs/stacktrace/build architecture=arm boost.stacktrace.from_exception=off (doesn't build), and b2 libs/stacktrace/build architecture=arm boost.stacktrace.from_exception=on (tries to build, but fails as expected).

import property ;
rule build-from-exception ( props * )
{
    local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
    switch $(enabled:G=)
    {
        case "on" :  return ;
        case off  :  return <build>no ;
    }

    local arch = [ property.select <architecture> : $(props) ] ;
    if $(arch) && ( $(arch:G=) != x86 )
    {
        return <build>no ;
    }
}

It's basically what you posted, but I removed checking for <build>, as it is unnecessary.

from stacktrace.

pdimov avatar pdimov commented on June 30, 2024

PR created: #166.

from stacktrace.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.