[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-build
Subject:    Re: [Boost-build] <build>no propagation
From:       "J. van der Wulp" <jwulp () win ! tue ! nl>
Date:       2006-11-26 19:51:01
Message-ID: 4569F025.9070104 () win ! tue ! nl
[Download RAW message or body]

> 
> In this case, the <install> target will get <build>no -- since usage 
> requirements are propagated all the way up. Do you suggest that 'install' is 
> specially coded to still install the other targets?

Yes. To me it seems seems a natural choice. We maintain a toolset with 
lots of tools. It can be that some tools cannot be built because library 
X or Y is not installed. But the user accepts this and wants to install 
the rest of the tools that can be build. I don't know how difficult this 
would be to realise at this moment, but to me using the build property 
looked like the perfect solution.

> 
> What precisely are you trying to achieve with <build>no in properties? Do you 
> want to avoid compiling lots of source files that depend on missing libraries 
> and won't likely compile anyway?

Yes this is exactly the intention. I want to use the build property as a 
  filter method. The problem we face at the moment is that some 
libraries and binaries are being build that should not build because for 
instance libXML is not available. To do this the site-config contains an 
alias target with the same name as the normal library target, with 
<build>no in requirements and usage-requirements. Is there a better way 
to solve this same problem?

Jeroen

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic