Re: [Boost-build] rule execution order

Subject: Re: [Boost-build] rule execution order
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-18 00:29:58

On 18.10.2016 00:17, Rene Rivera wrote:
> Not sure what your intent is so I may get this wrong. But from reading
> your Jamfile and the Makefile. Here's what I think you should do..
>
> path-constant here : . ;
> if [ os.name <http://os.name> ] = NT {
> make numpydoc.txt : numpy/make.bat : @numpydoc
>     [ conditional <depends> : [ glob-tree-ex numpy : *.rst ] ] ;
> action numpydoc
> {
>     rd /S /Q "$(>:D)/_build"
>     cd "$(>:D)"
>     call "$(>:D=)" && echo "done" > "$(<)"
> }
> } else {
> make numpydoc.txt : numpy/Makefile : @numpydoc ;
> action numpydoc
> {
>     rm -rf "$(>:D)/_build"
>     cd "$(>:D)"
>     make "$(>:D=)" && echo "done" > "$(<)"
> }
> }

OK, thanks, I'll try that out.

[I have to say I'm stunned to see that I have to write non-portable code
in my Jamfile. Isn't the whole point of boost.build to provide a
portable platform to write build logic in ? I'd actually expect commands
for copying and removing files among the very basic building blocks such
a tool needs to provide. This also relates to the other thread on the
"future of b2". I think that providing a platform-agnostic toolbox for
basic commands needed in any build logic goes a long way to make b2 and
boost.build more user-friendly and popular among developers.]

> The one key difference is that the above builds it in-place. But since
> that's the same effect you had by trying to copy to the build dir and
> then copy back I think that's OK.

I don't really mind where the docs are build - I just wanted things to
conform to how the rest is built.
For my own builds I mostly just build Boost.Python stand-alone with
SCons. The Boost.Build logic is needed such that Boost.Python is
available for a) Boost binary releases, b) online docs on boost.org and
c) anyone who wants to build things as part of Boost.

> Also, the numpydoc.txt placeholder target depends only on the RST
> sources. I.e. it will not catch changes of PNG, CSS, HTML, etc files
> as it would be a circular dependency. But that could be remedied with
> some different globs.
>
> And, caveat.. The above is untested off the cuff code :-)
>
> And one last item.. Are you aware that there's a built in RST->HTML
> using docutils transformation?

I am (I'm using it to build David's article on hybrid programming, as
shown in the Jamfile. ;-) )

Many thanks for your help !

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...