On Mon, Dec 16, 2013 at 1:59 PM, James Sharpe wrote: Why not create a vagrant config for this: http://www.vagrantup.com?

Very interesting! I had never heard of Vagrant. Dave Abrahams has voiced the opinion that a test-on-demand setup moving Boost closer to a continuous integration environment would be a lot easier to implement if the testers were running in uniformly configured virtual machines. While Dave's point was well taken, I was having trouble understanding how that could be easily and cheaply implemented. It appears Vagrant might be very helpful in attacking that problem. I doubt I'm going to have enough time to try Vagrant any time soon, so I think it would be great if someone else could give it a try and report back about the experience. Thanks, --Beman

On Tue, Dec 17, 2013 at 9:23 AM, Vladimir Prus wrote:

On 17.12.2013 17:58, Beman Dawes wrote:

...

On Mon, Dec 16, 2013 at 1:59 PM, James Sharpe wrote:

Why not create a vagrant config for this: http://www.vagrantup.com?

...

Very interesting! I had never heard of Vagrant.

Dave Abrahams has voiced the opinion that a test-on-demand setup moving Boost closer to a continuous integration environment would be a lot easier to implement if the testers were running in uniformly configured virtual machines.

What 'uniformly configured' means exactly? I don't think that could mean that all Linux testers use VM with Ubuntu 13.10 32-bit, since that would not detect any RHEL5 64-bit bugs?

- Volodya

I agree, we've never had very uniform configuration before, but that meant we've had a lot of diversity in our tests. Though this makes setting up a tester more difficult, it gives us a lot of unique coverage. I'd consider this a huge plus, with the correlating downside being that it can be very difficult to get a test runner setup. Another way to think about our great diversity, look at the platforms: AIX, FreeBSD (also Mac), Linux, Windows. Then multiply them by all the different compiler+library configurations: gcc-4.[4-8], gcc* with cpp[98,11,1y], clang-3.[0-4], clang* with libstd++, intel-[11,12,13], msvc-[8-12], msvc with stlport, borland?, gcc* mingw, and more! We would literally need hundreds of setups to get all those combinations. Plus, I think several of the people who run tests don't have them running in a VM, they just kick them off from the command line. (Although all my teeks99-* tests are run with the exact same VM image...one for linux one for windows.) Speaking of windows, I get the impression from reading the vagrant site that they don't work well with windows. The only reference I found to vagrant with windows was this github repo: https://github.com/WinRb/vagrant-windows which indicated that you would need to have a base windows VM image. In this case, licensing would obviously preclude it from being distributed amongst testers. One idea for the windows side, is to ask if Microsoft would be interested in donating some Azure virtual machines to dedicate to boost visual studio testing. We could get one machine image setup for each of the five supported compilers and then use a vagrant-like system to work with a CI scheduler to test those compilers. Tom

On Tue, Dec 17, 2013 at 10:28 AM, Cox, Michael wrote:

Recommend changing:

sudo mv b2 /usr/bin

to

sudo mv b2 /usr/local/bin

/usr/bin is managed by package managers. You shouldn't normally put anything there since (a) it can be overwritten with the next package update and (b) you don't see what is custom-built and what is installed with packages (this comes in the way when upgrading the system). /usr/local/bin is better in this sense, but still I prefer not to put anything there anyway. I put my custom binaries to ~/bin. I'm on Kubuntu though, not sure if Fedora supports ~/bin.

On 17 December 2013 13:27, Daniel James wrote:

It's probably better to use 'sudo ./b2 install --prefix=/usr/local' to install the whole thing for standalone use.

Sorry, that should be from 'tools/build/v2' so that it just installs all of boost build, not all of boost.

On 17 December 2013 14:33, Beman Dawes wrote:

Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I don't feel strongly about that.

If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this: $ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.

On 18 December 2013 22:22, Bjørn Roald wrote:

On 12/18/2013 10:01 PM, Jonathan Wakely wrote:

...

On 17 December 2013 14:33, Beman Dawes wrote:

...

Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I don't feel strongly about that.

If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this:

$ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.

Are you sure you would have this problem if you run Fedora in a virtual machine you created,

I haven't tried, but are you suggesting the default sudoers file is different if Fedora is installed in a VM? How does the OS know it's running as a VM guest?

You would have full root access, wouldn't you?

No, not as a non-root user you create. Not by default anyway. I think you can make "sudo make me a sandwich" work by creating the user as an Administrator during the Fedora installation process, which causes the user to be added to the 'wheel' group.

On Dec 19, 2013 6:37 AM, "Bjørn Roald" wrote:

On 12/19/2013 02:13 AM, Jonathan Wakely wrote:

...

On 18 December 2013 22:22, Bjørn Roald wrote:

...

On 12/18/2013 10:01 PM, Jonathan Wakely wrote:

...

On 17 December 2013 14:33, Beman Dawes wrote:

...

Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I

don't

...

...

...

...

feel strongly about that.

If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this:

$ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.

Are you sure you would have this problem if you run Fedora in a virtual machine you created,

I haven't tried, but are you suggesting the default sudoers file is different if Fedora is installed in a VM? How does the OS know it's running as a VM guest?

No, I am not suggesting that. You could add

redi ALL=(ALL:ALL) ALL

to /etc/sudoers then to make the procedure work, or simply use su instead to log in as root before the install step.

Yes, I know. My point is that the current instructions don't work out of the box on Fedora.

...

...

You would have full root access, wouldn't you?

No, not as a non-root user you create. Not by default anyway.

OK, I was in the impression you tried in on a machine where you did not

have root access as in not having the root password in your case. I have root access on my own systems, that's not the point. The instructions assume you are working as a non-root user. If you have root access why use sudo at all?

...

I think you can make "sudo make me a sandwich" work by creating the user as an Administrator during the Fedora installation process, which causes the user to be added to the 'wheel' group.

In that case you should be able to add the user to the "wheel" group at

any time to make the sudo based procedure work. But that is likely to be specific for that distribution. Yes I know, that's not the point.What I was saying is the current instructions (which are meant for people without GNU/Linux experience, not for me) don't work out of the box on other distros. Providing another distro-specific workaround is not going to solve that. But as I said in the first place, if it's expected that people follow those instructions exactly and use the suggested distro then it doesn't matter.

On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael wrote:

On Mon, Dec 16, 2013 at 11:42 AM, Beman Dawes wrote:

Hopefully this won't cause a Linux distribution flame war, but I run Fedora Linux in VirtualBox mainly because it tends to be one of the first distributions to release the latest g++/clang++ compilers.

I inserted most of your comment above into the introduction to let readers know Fedora is another possibility.

After installing the distribution, installing vbox additions on Fedora (and maybe other distributions) requires you:

- Use the VirtualBox Manager app storage settings to "insert" VBoxGuestAdditions.iso into the CD/DVD-ROM drive - Use the Linux file manager to open the CD/DVD-ROM drive containing the VBoxGuestAdditions.iso and click "Run Software".

IIRC, that was the documented procedure and how I always did it, but then I blundered into the approach given and found it a bit easier. Could you please check and see if the "Devices" menu for your virtual machine running Fedora also has "Insert Guest Additions CD Image..." entry?

Recommend changing:

sudo mv b2 /usr/bin

to

sudo mv b2 /usr/local/bin

Done. Works as expected. Thanks. Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.

--Beman

On Tue, Dec 17, 2013 at 06:36:24PM +0400, Andrey Semashev wrote:

On Tue, Dec 17, 2013 at 6:24 PM, Beman Dawes wrote:

...

On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael wrote:

...

Recommend changing:

sudo mv b2 /usr/bin

to

sudo mv b2 /usr/local/bin

Done. Works as expected. Thanks.

Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.

Please, please don't recommend putting anything into /usr/bin. See my reply to Michael.

A major red flag I see is: you're messing with global machine state even if you work with /usr/local. I'd recommend that you avoid touching anything outside of the user unless you really need to. The less persistent state you end up with after testing a build, the less cruft will build up in the machine over time. The last thing you want is stray files from a previous test or unrelated test kicking in and tricking you. If you run your tests from a user, you can trivially make another one or recreate it if you suspect you've tainted it. With global state, you pretty much have to re-provision the whole machine. -- Lars Viklund | zao@acc.umu.se

On Tue, Dec 17, 2013 at 7:36 PM, Daniel James wrote:

On 17 December 2013 14:36, Andrey Semashev wrote:

...

On Tue, Dec 17, 2013 at 6:24 PM, Beman Dawes wrote:

...

On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael wrote:

...

Recommend changing:

sudo mv b2 /usr/bin

to

sudo mv b2 /usr/local/bin

Done. Works as expected. Thanks.

Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.

Please, please don't recommend putting anything into /usr/bin. See my reply to Michael.

You misread Michael Cox. He was recommending change from '/usr/bin' to '/usr/local/bin'.

Oh, sorry then.