Boost logo

Boost :

Subject: [boost] [gsoc] Getting started with a repository (Was: Re: Live read-only GIT mirrors of Boost trunk SVN)
From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2013-05-28 10:47:12


Following on from an earlier discussion...

On 4 May 2013 20:00, Stefan Seefeld <stefan_at_[hidden]> wrote:

> On 05/04/2013 01:25 PM, Dave Abrahams wrote:
> > on Sat May 04 2013, Stefan Seefeld <stefan-AT-seefeld.name> wrote:
> >
> >> it would be great if the sandbox could be converted quickly, so GSoC
> >> students can use it ?
> > We don't expect anyone to commit to https://github.com/boostorg/sandbox
> > once the transition is complete. In fact, it would be good to stop now.
> > Instead, people should use individual Git repositories.
>
> OK, that makes sense. So sanbox projects become entirely independent
> with the only dependency being some upstream boost version (which may
> correspond to either a release or a development version).
>

So, students can assume that users have boost installed on their machine in
a standard location, and can set up a separate git repository for their
project. Great.

I remember there used to be a template in the sandbox for getting started;
all I see right now is this:

http://svn.boost.org/svn/boost/sandbox/template_under_construction/

It looks like it's the right kind of thing, but is this still
under_construction (cc'ing Stjepan)? It seems to produce a basic set of
directories, Jamfiles, etc. when following these steps:

svn co http://svn.boost.org/svn/boost/sandbox/template_under_construction/
cd template_under_construction
python file_template.py sandbox
# Answer some question prompts

>> It would be great if they didn't need to learn a thousand tools before
> >> being able to focus on the project itself, and so having a
> >> well-defined and -documented process to set things up and get started
> >> would be very helpful.
> > I don't know what you mean here, sorry.
>
> Never mind. I was thinking of a mix of versioning tools used for sandbox
> projects, boost trunk, etc., causing an unnecessarily steep learning
> curve. But if individual projects are to be hosted separately anyhow,
> that's much less of a concern (though it would still be useful to have
> clear and up-to-date guidelines for directory layout, build system,
> etc., to make it easier to merge to trunk should we ever get this far).
>

Is setting up Jamroot / Jamfiles still the recommended way of getting
started?

Cheers,

Darren


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk