On 11/08/2014 12:40 AM, Edward Diener wrote:

On 11/7/2014 1:50 PM, Vladimir Prus wrote:

...

Back in 2009, Boris Schäling wrote a Boost.Build tutorial that many deemed to be better than the tutorial in the official documentation. It took quite some time, but it's now part of Boost.Build, here:

http://www.boost.org/build/tutorial.html

I'd appreciate any comments.

Note that previously, I planned to integrate this tutorial with the boostbook documentation. It's becoming clear that there's just no time for that, and the tutorial is added as HTML page. I haven't decided yet what to do with old tutorial in boostbook sources.

Can this tutorial be placed as part of the offcial Boost Build documentation on the 'master' branch, with perhaps a link to it from the Boost Build TOC ?

Edward, it now part of the devel branch, and will be merged to master in due course. As for link from TOC, I'll think about it, but it might be tricky to accomplish. Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

On 9 Nov 2014 18:01, "Paul A. Bristow" wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of

...

Sent: 07 November 2014 18:50 To: boost@lists.boost.org Subject: [boost] Boost.Build: new tutorial

Back in 2009, Boris Schäling wrote a Boost.Build tutorial that many deemed to be better than the tutorial in the official documentation. It took quite some time, but it's now part of Boost.Build, here:

http://www.boost.org/build/tutorial.html

I'd appreciate any comments.

Helpful.

I feel that a lot of the trouble with b2 (it would be helpful to mention

Vladimir Prus that it is also called bjam?) bjam to b2 renaming is explained as per the patch [1], but it may be worth to add similar note to the tutorial [1] https://svn.boost.org/trac/boost/ticket/9304 Mateusz Łoskot (Sent from mobile)

On 11/09/2014 08:39 PM, Steve M. Robbins wrote:

On November 9, 2014 05:01:20 PM Paul A. Bristow wrote:

...

I feel that a lot of the trouble with b2 (it would be helpful to mention that it is also called bjam?) is the syntax - I find it truly bizarre.

You're not the only one who feels that way!

Would you prefer Python instead - when Python port is ready? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

[Please do not mail me a copy of your followup] "Steve M. Robbins" spake the secret code <2922516.Yh02HbQAIQ@riemann> thusly:

Well, personally, I prefer not to have to learn a new build system if I don't have to. So my first stance would be: what's wrong with cmake, for example?

Ditto. Progress is being made on creating a package manager for use with CMake https://github.com/ruslo/hunter; cmake has a community that can actually answer questions. Bjam is orphaned AFAICT. Having struggled with bjam/b2 in order to get it compiling the rewrite of Boost.Test documentation and associated examples, I consider time spent learning bjam to be a wasted effort. I'll only ever use it in order to contribute to Boost and if Boost were anything less than the awesomeness that it is, bjam would have made me want to fork and kill it (bjam, that is) from boost just to make my life sane. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Although I know enough bjam to not get much personally from a tutorial, I am happy to see it improve. We use bjam in our project so a better tutorial makes it easier for casual contributors and power users to get up to speed. Although the syntax is finicky it's the best I've seen. So thanks to Steven and Vladimir for maintaining it all these years! -Matt On Nov 12, 2014 12:17 AM, "Vladimir Prus" wrote:

On 11/12/2014 01:58 AM, Richard wrote:

...

[Please do not mail me a copy of your followup]

"Steve M. Robbins" spake the secret code <2922516.Yh02HbQAIQ@riemann> thusly:

Well, personally, I prefer not to have to learn a new build system if I

...

don't have to. So my first stance would be: what's wrong with cmake, for example?

Ditto. Progress is being made on creating a package manager for use with CMake https://github.com/ruslo/hunter; cmake has a community that can actually answer questions. Bjam is orphaned AFAICT.

I think you've expressed this opinion earlier, repeating it does not make it stronger, and the email that started this topic is about Boost.Build tutorial - let's stick to it.

- Volodya

-- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 09 November 2014 17:49 To: boost@lists.boost.org Subject: Re: [boost] Boost.Build: new tutorial

On 11/09/2014 08:39 PM, Steve M. Robbins wrote:

...

On November 9, 2014 05:01:20 PM Paul A. Bristow wrote:

...

I feel that a lot of the trouble with b2 (it would be helpful to mention that it is also called bjam?) is the syntax - I find it truly bizarre.

You're not the only one who feels that way!

Would you prefer Python instead - when Python port is ready?

My brain is full ;-) So not much, as I have got used to the b2 devil that I know but love to hate. I think Robert is right when he says b2 tries too hard to do things magically, but when it fails, it is too difficult to see why and near impossible to decide how to fix it. Hence the endless stream of cries for help on the lists. I'd also like to see many more *examples* of the common setups. FWIW. Paul

I've been a complainer about b2/bjam forever. I think the main problem has been a misstep in the original concept. It does so much stuff auto-magically that when things are not quite right it's impossible to figure out what to do . It seems like it outsmarts the user and tries to do what the user "wants" when the user doesn't have something set up right. If I have two compilers installed and I might get one or the other depending on ?. I would rather that it stops with "multiple compilers found - select specific compiler! with ... ". So if I haven't got things right, I just keep fixing stuff until it works rather than embarking on a guessing game. This doesn't have to be done as a huge redesign. Currently every time a user has a problem he gets information one where to look and what to try. Better would be to tweak the code so it fails as soon as possible with an error message. Eventually, the requests for help would diminish as all the common errors would be addressed. my 2 cents. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Build-new-tutorial-tp4668812p466885... Sent from the Boost - Dev mailing list archive at Nabble.com.