- Boost - lists.boost.org

[git] Bumping git version requirement to 1.7.10
by Beman Dawes 01 Jan '14

01 Jan '14

https://svn.boost.org/trac/boost/wiki/Git/GitHome documents Boost's version requirement for Git, currently at 1.7.3. The regression scripts are using the clone --single-branch option, which became available at git 1.7.10, so we are planning to bump the version requirement. Done anyone have a problem with this? --Beman

6 11

[urgent] Testing help needed..
by Rene Rivera 31 Dec '13

31 Dec '13

I finally have the changes to the regression scripts sufficiently complete that I've managed to do a few minimal cycles of regression testing from the git repos. I now need some help in various ways: 1. General testing.. I need some of the regular testers to do runs with their setups with the new scripts. To test I suggest starting from a new testing location. And follow the usual instructions except get the run.py script from < https://raw.github.com/boostorg/boost/develop/tools/regression/src/run.py>. The options are exactly the same as the SVN version of the scripts (the --tag is mapped to master or develop as needed). If you run patch scripts you will have to adjust paths for the new arrangement. In particular the boost tree is now checked out to <testing-root>/boost_root. 2. Non-nix testing.. I don't have the time or resources available to check if the scripts and git invocations work on Windows. I need one person to test and likely make changes to the regression script to do the right things on Windows. Testing should be the same as above. But doing changes locally and testing them is challenging. The procedure I use is (as shell commands): > mkdir testing-dev > cd testing-dev > link <BOOST_DEVELOP>/tools/regression/src/run.py run.py > ln -s < BOOST_DEVELOP>/tools/regression/xsl_reports xsl_reports > ln -s < BOOST_DEVELOP>/tools/regression/src tools_regression_src > ./run.py --runner=<RUNNER_NAME> --skip-script-download --use-local That lets you edit the regression.py and run.py scripts in your local develop checkout. The options make it skip most of the run.py code, but otherwise make it behave as the regular testing except using your local changes. If you need to test changes to run.py in the normal use case you will have to commit+push the changes and then test. 3. Report generation.. It seems that the reports are failing to get generated for some reason. I suspect that the new scripts putting the git commit SHAs as the tested version number are messing up the results generation. I need someone familiar with the result generation to fix this. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

4 6

[Boost][Proto] BOOST_PROTO_USE_NORMAL_RESULT_OF seems incorrectly defined
by Hui Li 31 Dec '13

31 Dec '13

In proto/proto_fwd.hpp, based on how the macro BOOST_PROTO_USE_NORMAL_RESULT_OF is used, it's meant to be defined when the compiler supports c++11 decltype and implements N3276, for example, BOOST_PROTO_RESULT_OF is boost::result_of when BOOST_PROTO_USE_NORMAL_RESULT_OF is defined. However, its definition seems incorrect, and is inconsistent with the comments next to it. #ifdef BOOST_NO_CXX11_DECLTYPE_N3276 ^^^^^^ should this be #ifndef ? # // Proto can only use the decltype-based result_of if N3276 has been # // implemented by the compiler. # // See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf # ifndef BOOST_PROTO_USE_NORMAL_RESULT_OF # define BOOST_PROTO_USE_NORMAL_RESULT_OF # endif #endif Am i missing something here? Hui

2 2

Versioning of individual modules
by Peter A. Bigot 31 Dec '13

31 Dec '13

Forked from Re: [boost] [git] tagging in modules Context below. Guided questions follow the quoted context. On 12/30/2013 11:02 AM, Beman Dawes wrote: > On Thu, Dec 26, 2013 at 7:24 PM, Peter A. Bigot <pab(a)pabigot.com> wrote: > >> Not relevant to the original thread, but since I just noticed it: >> >> git-push by default does not push tags: you need to specifically ask for >> the tag to be pushed (by name), or use --tags. So this sequence does >> nothing visible: >> >> git tag -a 1.2 >> git push >> >> Personally I'd prefer if tag symbols were a little more informative than >> "1.2", and followed a pattern that places them in a namespace reserved for >> the module, such as timer-1.2. Because tags aren't normally pushed, >> they're useful for individual developers to use as markers. However, >> git-pull will automatically retrieve tags attached to commits that are >> fetched unless --no-tags is given, so if a repository (from boostorg, or >> another developer) defines (or moves) a tag it might overwrite your local >> tag without warning. So it's important to know what tags you can expect >> might conflict with those in a remote repository to avoid conflicts. >> > Updated: > > https://svn.boost.org/trac/boost/wiki/StartModWorkflow#Releasetags > <https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea…> > https://svn.boost.org/trac/boost/wiki/StartModMaint > #Lightweightlibraryrelease<https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea…> > > >> I'd also really like to see any module that uses internal versioning also >> provide a mechanism by which code can determine which version is being >> used. E.g., for the above there ought to be a <boost/timer/version.hpp> >> header which has: >> >> #define BOOST_TIMER_VERSION_MAJOR 1 >> #define BOOST_TIMER_VERSION_MINOR 2 >> >> Otherwise I'm not seeing any value for module-level version tags in the >> repository. Matter of taste, though. >> > While I'm sympathetic, we should get comments and buy in from library > maintainers before recommending this. Are a lot of libraries already doing > something similar? If so, what? And do we follow Rene's suggestion and > recommend Predef? Could you please start a separate discussion with a > subject that let's maintainers know this is affects them? Thanks! > > There is a tangentially related issue: The git and modular boost related > docs are being developed without any reference to or updating of existing > developer documentation. We need to get that underway. Ditto web site > changes. > > >> I would expect, on superproject release, that each module would continue >> to receive a boost-X.Y tag marking the module commit that corresponds to >> the submodule SHA1 used for the release. This is another reason to make >> sure module-level tags are clearly distinguished (lest somebody think the >> tag corresponds to a boost version rather than a module version). >> > Sounds about right, but we would need to work out the mechanics. Who does > the tagging? A script release managers run? General questions related to this topic: *) When a module pushes to master, must all commits that appear directly on the master branch be considered "stable" or is it only necessary that the HEAD always be stable? The context for this is actually in "[git] avoiding fast forward merges" at http://lists.boost.org/Archives/boost/2013/12/210110.php. It's primarily a superproject decision but module maintainers should be aware of it. *) Should all modules be assigned version numbers, or may module "releases" be unversioned master commits that "inherit" the Boost version when incorporated into a release? My opinion: Don't bother unless there's clear evidence that the module will be shipped or used outside of a versioned Boost installation. *) If a module has a module-specific version number, should it be expected to provide that version number in a standard location and name so that preprocessor directives interrogate and adapt user code based on it? What mechanism should be used for this? My opinion: Absolutely. If the module is named timer (sorry I keep picking on that module), then I would like to see: #include <boost/timer/version.hpp> define a macro BOOST_TIMER_VERSION which has an ordinal integer value that may be used in comparisons in preprocessor conditionals to select available features. I support Rene Rivera's suggestion to use the BOOST_VERSION_NUMBER macro from Boosts.Predef to accomplish this. Of course, if no modules need module-level versioning, this won't be necessary. *) What syntactic format should be used for git tags that record version numbers? My opinion: If the module is named timer, and the version number is 1.2, the tag timer-1.2 would be created and pushed to the boostorg timer repository by the timer maintainer. *) By what process is the superproject version associated with the commit on the master branch that is selected for a given Boost release? My opinion: If the Boost release is 1.56, every module incorporated into that release has a boost-1.56 tag created, identifying the master branch commit that is incorporated into the release. This tag would be added by the release manager when the superproject is tagged using a trivial "git submodule foreach git tag boost-1.56" in the superproject master branch followed by "git submodule foreach push origin boost-1.56" after sanity checks. Other inputs? Peter

2 3

[git-help] clone asks for passphrase for every library
by Nathan Ridge 30 Dec '13

30 Dec '13

Hello, I'm trying out git + modular boost for the first time. When I try to clone the repository as described here [1], I run into a problem where the recursive clone process asks me for my SSH key's passphrase for every submodule (library) that it is checking out. Is there a way to avoid this? Thanks, Nate [1] https://svn.boost.org/trac/boost/wiki/TryModBoost

4 4

[GIL] Pixel Layout Padding?
by TONGARI J 30 Dec '13

30 Dec '13

Hi there, The current gil::pixel design has a deficiency that you can't specify the align of pixel, for example, you can't have an RGBX pixel in GIL where X is padding. An alternative is to introduce a dummy channel for X, but that doesn't seem to be a good idea as we don't want to mess up the color space. So, maybe it'd be better to extend the current design, say, pixel<ChannelValue, Layout>, to something like pixel<ChannelValue, Layout, Align>. Then we can specify RGBX as pixel<uint8_t, rgb_layout_t, 4>, or XRGB as pixel<uint8_t, rgb_layout_t, -4> where minus means left justify. Ideas?

3 11

[git-help][urgent] How do I ignore an upstream change to one file?
by Rene Rivera 30 Dec '13

30 Dec '13

When I attempt to do an update of the boost superproject I get and error: Froggy:develop grafik$ git pull error: Your local changes to the following files would be overwritten by merge: tools/regression/src/regression.py Please, commit your changes or stash them before you can merge. Aborting Froggy:develop grafik$ I know I've made changes. I also know I don't want to throw away my changes. I also know that I don't want to merge the upstream changes to that one file. Hence.. How do I do a pull and have git ignore the upstream of only that file? (i.e. throw away the upstream changes because I know that my changes supersede them) Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

8 13

[git] New doc page: Cautions and Suggestions
by Beman Dawes 30 Dec '13

30 Dec '13

https://svn.boost.org/trac/boost/wiki/GitCautions\ Corrections, comments, and suggestions welcome. --Beman

2 2

[git] Post svn conversion merge point instructions moved
by Beman Dawes 30 Dec '13

30 Dec '13

The post svn conversion merge point instructions have been moved to a separate page. See https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint A set of preparatory steps suggested by Peter Dimov have been added. I'm unsure how Peter's prep steps interact with the actual merge point instructions. Particularly, what SHA is used for the merge point? Please take a look, and then suggest corrections or clarifications. Thanks, --Beman

2 2

[range] Should html docs be checked in?
by Mostafa 30 Dec '13

30 Dec '13

Can the maintainer(s) of range answer this question that came up in the documentation ML: On Sat, 28 Dec 2013 02:09:06 -0800, Daniel James <daniel(a)calamity.org.uk> wrote: > On 28 December 2013 00:15, Mostafa <mostafa_working_away(a)yahoo.com> > wrote: >> >> If html files, or any other files for that matter, are auto-generated >> then >> why are they included in the repo? The reason I ask because this >> difference >> in boostbook version causes a lot of extraneous noise when I do a git >> status. Instead of the three html files I was expecting to be modified >> when >> I changed a qbk file there are 153 extra html files that show up as >> modified. > > For many libraries they aren't. It's up to the library maintainer how > they're managed. What you can do is rebuild the documentation from a > clean checkout and commit that, then later edits shouldn't result in > so many changes.

5 9