I've got two projects using waf, where one is dependent upon the other (for ease, I'll call them common and advanced.) The advanced project references libraries from common during build, listing the common libraries in the 'lib' argument. It looks something along these lines:
common - libs - libfoo.a libbar.a libbaz.so
advanced - app - exampleApp (the build command would be something like "bld.program(src='example.cpp', lib=['foo', 'bar', 'baz'])")
exampleApp builds fine the first time around. However, if a change is made to common, advanced won't relink exampleApp against the new version of the library. I know we could write out the check() calls in advanced's configure step to store the libraries as dependencies for the 'use' line, which I believe would fix this issue. I'm wondering if it's possible to export or directly use information generated by common's waf scripts to pull this information in directly, without having to write out every library we want to use. We've got a fairly large number of libraries in common, which would make this difficult. Any ideas?
On Fri, Oct 26, 2012 at 5:50 PM, jasedit wrote:
> I've got two projects using waf, where one is dependent upon the other (for
> ease, I'll call them common and advanced.) The advanced project references
> libraries from common during build, listing the common libraries in the
> 'lib' argument. It looks something along these lines:
> advanced -
> app -
> exampleApp (the build command would be something like
> "bld.program(src='example.cpp', lib=['foo', 'bar', 'baz'])")
> exampleApp builds fine the first time around. However, if a change is made
> to common, advanced won't relink exampleApp against the new version of the
> library. I know we could write out the check() calls in advanced's configure
> step to store the libraries as dependencies for the 'use' line, which I
> believe would fix this issue. I'm wondering if it's possible to export or
> directly use information generated by common's waf scripts to pull this
> information in directly, without having to write out every library we want
> to use. We've got a fairly large number of libraries in common, which would
> make this difficult. Any ideas?
How about building the whole project at once and filtering the targets
to build with --target=libname? More complex solutions involving
pkg-config scripts (with defines for API numbers) or using
bld.read_shlib/bld.read_stlib to read the libraries are also possible.
The common project needs to be able to be built without the advanced tree - the advanced tree is limited distribution, while the common tree is shared with other projects. Is there a way to have the common tree have a standalone waf setup, but subsume it's waf build system if advanced invokes its build system? Would that be reasonable?
On Friday, October 26, 2012 5:17:40 PM UTC-4, Thomas Nagy wrote:
> How about building the whole project at once and filtering the targets > to build with --target=libname? More complex solutions involving > pkg-config scripts (with defines for API numbers) or using > bld.read_shlib/bld.read_stlib to read the libraries are also possible.
What I'm seeing is that not all targets in common are being built. The targets which are explicitly used by advanced are built, but shared objects which are not linked against (e.g. plugins) are left unbuilt. Oddly, if I run "waf list" I see those plugins listed, and if I run "waf build --target=*" those targets are built. Is there some subtle issue I'm missing with this setup? Or can you not recurse into an arbitrary directory?
On Friday, October 26, 2012 5:17:40 PM UTC-4, Thomas Nagy wrote:
> On Fri, Oct 26, 2012 at 5:50 PM, jasedit wrote: > > I've got two projects using waf, where one is dependent upon the other > (for > > ease, I'll call them common and advanced.) The advanced project > references > > libraries from common during build, listing the common libraries in the > > 'lib' argument. It looks something along these lines:
> > advanced - > > app - > > exampleApp (the build command would be something like > > "bld.program(src='example.cpp', lib=['foo', 'bar', 'baz'])")
> > exampleApp builds fine the first time around. However, if a change is > made > > to common, advanced won't relink exampleApp against the new version of > the > > library. I know we could write out the check() calls in advanced's > configure > > step to store the libraries as dependencies for the 'use' line, which I > > believe would fix this issue. I'm wondering if it's possible to export > or > > directly use information generated by common's waf scripts to pull this > > information in directly, without having to write out every library we > want > > to use. We've got a fairly large number of libraries in common, which > would > > make this difficult. Any ideas?
> How about building the whole project at once and filtering the targets > to build with --target=libname? More complex solutions involving > pkg-config scripts (with defines for API numbers) or using > bld.read_shlib/bld.read_stlib to read the libraries are also possible.
On Fri, Nov 9, 2012 at 4:42 PM, jasedit wrote:
> I'm trying to glue the two trees together, and running into some odd issues.
> I modified the advanced script to look something like this:
> What I'm seeing is that not all targets in common are being built. The
> targets which are explicitly used by advanced are built, but shared objects
> which are not linked against (e.g. plugins) are left unbuilt. Oddly, if I
> run "waf list" I see those plugins listed, and if I run "waf build
> --target=*" those targets are built. Is there some subtle issue I'm missing
> with this setup? Or can you not recurse into an arbitrary directory?
The default is to build the targets under the current working
directory. When using top='..', make sure to set bld.target='*' to
force all targets.
On Friday, November 9, 2012 11:13:39 AM UTC-5, Thomas Nagy wrote:
> On Fri, Nov 9, 2012 at 4:42 PM, jasedit wrote: > > I'm trying to glue the two trees together, and running into some odd > issues. > > I modified the advanced script to look something like this:
> > What I'm seeing is that not all targets in common are being built. The > > targets which are explicitly used by advanced are built, but shared > objects > > which are not linked against (e.g. plugins) are left unbuilt. Oddly, if > I > > run "waf list" I see those plugins listed, and if I run "waf build > > --target=*" those targets are built. Is there some subtle issue I'm > missing > > with this setup? Or can you not recurse into an arbitrary directory?
> The default is to build the targets under the current working > directory. When using top='..', make sure to set bld.target='*' to > force all targets.
On Fri, Nov 9, 2012 at 7:54 PM, jasedit wrote:
> Is this something that can be done inside the wscript itself? I tried adding
> bld.target='*' to the script, but it just threw an error.
On Friday, November 9, 2012 2:01:07 PM UTC-5, Thomas Nagy wrote:
> On Fri, Nov 9, 2012 at 7:54 PM, jasedit wrote: > > Is this something that can be done inside the wscript itself? I tried > adding > > bld.target='*' to the script, but it just threw an error.
