- Boost - lists.preview.boost.org

Moving files around
by John Maddock 10 Jan '15

10 Jan '15

Can I just fire a shot across the bows before we all get too carried away moving files around here there and everywhere? *The move has to make logical sense* - reducing dependencies is a worthy goal, but not if it makes stuff harder to maintain and/or harder for the user to find what they're looking for. Let me give you a trivial example: boost/utility/declval.hpp was moved into the type_traits repository to reduce dependencies on utility. OK fair enough. But I see no tests or docs, and the docs at the very least are still in "utility". So now we have a situation where maintenance of that functionality is split over two repositories each with different maintenance teams. That's not good. Perhaps more to the point, if I'm a user and I'm looking for boost/something/whatever.hpp, it had better darn well be in package "something" or I'm going to be pretty annoyed. This applies equally to folks wanting to use "whatever.hpp" as to folks wanting to submit pull requests. In fact if the above doesn't hold I suspect that a) Folks will give up and reinvent smaller utilities for themselves. b) Use an older version of Boost ("I new where everything was there"). c) Not submit bug reports or pull requests cause they can't figure out where they should go. I guess what I'm saying is that while re-factoring is a good idea, it needs a vision to improve "discover-ability" and make Boost's structure more logical, not merely easier for a package manager. Now please do carry on as you were ;) John.

3 2

[functional] How to avoid a dependency on functional?
by Beman Dawes 10 Jan '15

10 Jan '15

Filesystem has a dependency on <boost/functional/hash_fwd.hpp> in order to supply this: inline std::size_t hash_value(const path& x) { # ifdef BOOST_WINDOWS_API std::size_t seed = 0; for(const path::value_type* it = x.c_str(); *it; ++it) hash_combine(seed, *it == '/' ? L'\\' : *it); return seed; # else // BOOST_POSIX_API return hash_range(x.native().begin(), x.native().end()); # endif } The problem with this is that functional is a heavy-weight dependency for such relatively minor feature. See http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-weights.html Is there any recommended way to avoid the functional dependency? Thanks, --Beman

5 14

[Boost.Filesystem] unique_path uses a random number generator from the OS, correct?
by Ben Fritz 09 Jan '15

09 Jan '15

The reference docs for unique_path state: Remarks: Implementations are encouraged to obtain the required randomness via a cryptographically secure pseudo-random number generator, such as one provided by the operating system. I'm confused by the "implementations are encouraged to" text. Isn't Boost.Filesystem the implementation of unique_path? Specifically, it *looks like* this is provided in unique_path.cpp which will use either CryptGenRandom from the Windows API; or /dev/urandom or /dev/random on POSIX systems. This means the random number comes from system/OS utilities, and not Boost itself, correct? -- Ben Fritz

2 1

A proposal for the creation of a new module, Core Type Traits
by Peter Dimov 09 Jan '15

09 Jan '15

This is a more formal statement of the same suggestion I've already given in other threads. Currently, library developers who need type traits functionality face a choice: either to use the TypeTraits library, and make their libraries dependent on MPL, Preprocessor, TypeOf and Utility, or to duplicate its functionality locally. Similarly, developers who want to specialize a type trait on a type of theirs, even a trivial empty struct, need to include the TypeTraits headers for the traits to be specialized, which brings in MPL and Preprocessor on a header-level, and makes their module dependent on TypeTraits and its dependencies listed above. Local replication, as in Boost.Move, rightly attracts charges of code duplication, with the associated potential maintenance problems when the implementations diverge. These two problems could be avoided if we were to have core type traits whose interface consisted solely of a member integral constant called "value", without any other required members or base classes, and which were only allowed to depend on Config or StaticAssert. This solves the second problem because it will then be possible for a developer to specialize a trait, such as is_pod, by using a forward declaration of the form template< class T > struct is_pod; in the appropriate namespace, like boost::core_type_traits, and then adding his specializations: template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); }; without including ANY additional headers. If we look at the current implementation of Boost.TypeTraits, for example is_pointer, we see this: template< typename T > struct is_pointer_impl { BOOST_STATIC_CONSTANT(bool, value = (::boost::type_traits::ice_and< ::boost::detail::is_pointer_helper<typename remove_cv<T>::type>::value , ::boost::type_traits::ice_not< ::boost::is_member_pointer<T>::value >::value >::value) ); }; in namespace detail, and then this: BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_pointer,T,::boost::detail::is_pointer_impl<T>::value) which takes care of everything else. Note that is_pointer_impl is EXACTLY what we need! It is the core implementation of the trait and exposes only ::value and nothing else. The full-featured boost::is_pointer is built on top of that. If detail::is_pointer_impl was called core_type_traits::is_pointer, this would immediately take care of the two problems at the top of this post, while not affecting the users of Boost.TypeTraits in any way. In particular, note that if a developer specializes detail::is_pointer_impl, is_pointer automatically picks up this specialization. Therefore, I propose that a new module, libs/core_type_traits, is created, which: - provides core type traits that only expose a member integral constant called "value" as part of its documented interface and nothing else; - allows these traits to be forward declared, without requiring header inclusion; - is not allowed to depend on anything except Config or StaticAssert; - is the place to which TypeTraits's is_pointer_impls gradually migrate, along with their tests. This - solves the dependency problems some of us are facing, - avoids unnecessary code duplication, - still allows type trait specialization, with clients of both libraries automatically picking up the specialization, - is backward compatible with respect to existing uses of Boost.TypeTraits because the new library will contain the same code and the same tests. Thank you for your attention. :-)

4 8

bpm added to tools/bpm on develop
by Peter Dimov 09 Jan '15

09 Jan '15

I've added bpm, the Boost Package Manager, to tools/bpm on develop. To build it, do b2 tools/bpm/build//install at the Boost root and b2 will build bpm with the default toolset and place it in dist/bin. To try it out, first you might want to review the fs_remove_all function in fs.cpp, or use a drive or filesystem that does not hold valuable files, :-) then make an empty directory, copy bpm(.exe) there, make a text file bpm.conf with the following line: package_path=http://www.pdimov.com/tmp/pkg-develop-1612497/ then do f.ex. "bpm install filesystem". pkg-develop-1612497 is just a sample "release" that I made by running tools\bpm\scripts\package.bat at the root of my source tree, which happened to be at revision 1612497 of develop. It therefore contains Windows line endings (and b2.exe), so it will generally not be suited for installation on non-Windows systems. A POSIX release would need to be prepared from a POSIX source tree and will probably need to install bootstrap.sh instead of b2.exe, with bpm then issuing a message that ./bootstrap.sh needs to be run. I've done my development on Windows so far and have not had time to test on POSIX.

2 3

Road to low-quality-code is paved with good intentions of dropping dependencies
by Antony Polukhin 09 Jan '15

09 Jan '15

Hi all, I've been looking through the latest changes to drop dependencies. Stuff that I saw is very frightening. For example: https://github.com/boostorg/move/blob/develop/include/boost/move/detail/typ… . Every boost release some issues are fixed in intrinsics of TypeTraits and is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels like loading a gun and pointing it on own foot. Another example is a sad story of boost::swap. We can not use Boost.Move here because it will add "a lot of dependencies" to Boost.Core. This leads us to nonoptimal implementation, which is sad. The Solution Almost *all* of the Boost libraries depend on TypeTraits, MPL, Core, Assert, StringRef. Language emulation features implemented in Exception, Move, StaticAssert, TypeIndex should be also widely used. hash_fwd.hpp must be used by almost all the containers and structures. So may be we should think of those libraries as of "base" libraries! I do not mean that they must be moved in a single "base" folder. I'm talking only about dependency reports: those libraries must be treated by the dependency tool as a single one and must have the level 1. Those libraries are "base", because they are the very common part of Boost framework. Not using them is more like a bad decision, reimplementing parts of them is an afwull decision. Threating them as base/common/core/main part of Boost seems reasonable. -- Best regards, Antony Polukhin

15 34

[bpm] Option to skip test dependencies?
by Beman Dawes 09 Jan '15

09 Jan '15

In looking at the Boost Package Manager [bpm] options, there is one omission I suspect users will ask for right away: an option to skip dependencies created by tests and perhaps examples. Is it possible to experiment with some simple strategy, like skipping the dependency check for "test" libraries to see what effect this has? Thanks, --Beman

2 1

ATTN library maintainers: libraries missing metadata files
by Peter Dimov 08 Jan '15

08 Jan '15

The following libraries are currently missing the metadata file meta/libraries.json, which describes the library: libs/algorithm/meta/libraries.json does not exist libs/assign/meta/libraries.json does not exist libs/bimap/meta/libraries.json does not exist libs/compatibility/meta/libraries.json does not exist libs/detail/meta/libraries.json does not exist libs/disjoint_sets/meta/libraries.json does not exist libs/function_types/meta/libraries.json does not exist libs/graph_parallel/meta/libraries.json does not exist libs/icl/meta/libraries.json does not exist libs/iostreams/meta/libraries.json does not exist libs/locale/meta/libraries.json does not exist libs/local_function/meta/libraries.json does not exist libs/numeric/meta/libraries.json does not exist libs/parameter/meta/libraries.json does not exist libs/ptr_container/meta/libraries.json does not exist libs/python/meta/libraries.json does not exist libs/random/meta/libraries.json does not exist libs/range/meta/libraries.json does not exist libs/rational/meta/libraries.json does not exist libs/scope_exit/meta/libraries.json does not exist libs/serialization/meta/libraries.json does not exist libs/statechart/meta/libraries.json does not exist libs/sync/meta/libraries.json does not exist libs/typeof/meta/libraries.json does not exist libs/type_erasure/meta/libraries.json does not exist libs/uuid/meta/libraries.json does not exist libs/winapi/meta/libraries.json does not exist Many of those libraries already have pull requests that contain the file. Please accept them and then merge them to master as well. :-) The file format is documented here: http://www.boost.org/development/library_metadata.html

2 3

Boost.Sort library hierarchy and namespacing
by Steven Ross 08 Jan '15

08 Jan '15

For the Boost.Sort library, I'm planning to add these (non-detail) files: boost/sort/sort.hpp boost/sort/spreadsort/spreadsort.hpp boost/sort/spreadsort/integer_sort.hpp boost/sort/spreadsort/float_sort.hpp boost/sort/spreadsort/string_sort.hpp Should all of these be in the boost::sort namespace? It seems silly to have a boost::sort::spreadsort namespace when there are only 5 publicly-visible functions in it. I actually can't imagine how of these names will conflict with names in other boost libraries, but using a boost::sort namespace appears conventional. Are there any objections or concerns based on this? Once this is done, I'd like to integrate this library into the boost build and testing system for the next appropriate release (I test it currently with modular boost).

2 2

Directory structure not quite right yet?
by Peter Dimov 08 Jan '15

08 Jan '15

Typically, when some library is installed in, say, $LIB, its headers reside in $LIB/include and its .a/.lib files in $LIB/lib. Our libraries, when built, go to $BOOST/stage/lib, which is close enough. But our header directory is just $BOOST, which doesn't seem right, as the whole of Boost is accessible through it. It makes sense, at least to me, to have the headers in $BOOST/include/boost, instead of just $BOOST/boost. The transition to Git would have been a good time to switch to that - there were enough other changes to the structure. I'm not saying that we should switch right away or something like that, but am I the only one to whom such a switch (at some unspecified time in the future) seems a good idea?

12 41

Is TypeOf library maintained?
by Adam Wulkiewicz 08 Jan '15

08 Jan '15

Hi, I'm asking because the most recent change in develop was done in 2013 and the last merge to master (or rather SVN release) was done in 2011. Would it be possible to along with the metadata PR have this trivial fix merged: https://github.com/boostorg/typeof/pull/1 ? It hangs there more than a half year. Thanks, Adam

2 1

New dependency report
by Peter Dimov 08 Jan '15

08 Jan '15

Here: http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-overview.html http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-levels.html and (new) here: http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-weights.html "Weight" is on how many other modules a module depends, both directly and indirectly.

1 0

[Tick] Universal quantified concepts/traits
by Vicente J. Botet Escriba 06 Jan '15

06 Jan '15

Hi, I'm trying to represent the concept of a mathematical Functor (as in Haskell) with Concept Lite. Here is what I want to express: A Functor W is a type constructor for wrappers of another type T providing a function map taking a function (T) -> U and a W<T> and returning a W<U>. Here is how I think that could be done with Concept Lite. If I understand the proposal correctly we need to add the type T and the function parameter to the concept. concept Functor<typename W, typename T, typename F > = requires { using WT = ApplyType<W, T>; // type constructor using U = ResultType<F, T>; using WU = ApplyType<W, U>; Function<F, U, T> && requires (F f, WT wt) { WU { map(f, wt) }; } }; But this is not exactly what I want to conceptualize. The wrapped type T and the function F should be universally quantified, that is, the concept concerns only the type constructor W: Functor<W>. I have a problem introducing the universal quantification of T and F. I don't know how to do it without using again a template. concept Functor<typename W> = template <typename T, typename F> // universal quantification on T and F requires { using WT = ApplyType<W, T>; using U = ResultType<F, T>; using WU = ApplyType<W, U>; Function<F, U, T> && requires (F f, WT wt) { WU { map(f, wt) }; } } }; But this is not valid code, isn't it. Is there something wrong with this kind of concepts? What would be the best way to conceptualize this kind of concepts with the Tick library ? Best, Vicente

3 5

bpm, a tool to install a modular Boost distribution
by Peter Dimov 06 Jan '15

06 Jan '15

One month ago, Stephen Kelly wrote: > git affects the developer workflow, but that thread was about creating > modular releases and downloads, which is a different goal and has a > different set of problems to solve. That's what that thread was about. I > didn't see any desire to have that as a goal in the thread. > > Git doesn't affect users. > > Before and after transition to git, they download all-of-boost.zip from > the boost website. To address this point of his, I've been working at a tool, bpm, that can install a modular Boost distribution. As I've already mentioned in other threads, it works like this: D:\boost-1.60.0>bpm install system bpm: installing module 'system' bpm: installing module 'assert' bpm: installing module 'config' bpm: installing module 'core' bpm: installing module 'predef' bpm: installing module 'build' bpm: the following libraries need to be built: system bpm: (use ./b2 to build) bpm: recreating header links bpm: recreating index That is, when told to install Boost.System, it downloads and installs the 'system' package into ./libs/system, along with all its dependencies, then creates links to the headers (like 'b2 headers') in ./include and an ./index.html file listing the installed libraries. The full syntax is: D:\boost-1.60.0>bpm Usage: bpm [-v] [-q] command [options] [modules] -v: Be verbose -vv: Be more verbose -q: Be quiet bpm install [-n] [+d] [-k] [-a] [-i] [-p] <module> <module>... Installs the specified modules and their dependencies into the current directory. -n: Only output what would be installed +d: Do not install dependencies -k: Do not remove partial installations on error -a: All modules (use instead of a module list) -i: Installed modules -p: Partially installed modules bpm remove [-n] [-f] [-d] [-a] [-p] <package> <package>... Removes the specified packages. (A package, like 'numeric', can contain more than one module.) -n: Only output what would be removed -f: Force removal even when dependents exist -d: Remove dependents as well. Requires -f -a: Remove all packages. Requires -f -p: Remove partially installed packages bpm list [-a] [-i] [-p] [-b] [prefix] Lists modules matching [prefix]. -a: All modules (default when no -b) -i: Installed modules (default when -b) -p: Partially installed modules -b: Modules that require building bpm headers Recreates the header links in the include/ subdirectory of the current directory. bpm index Recreates the file index.html, which lists the installed modules, in the current directory. -- This all works already under Windows. (I haven't finished the POSIX part yet but it should be close.) I could have made a Windows binary available for people to play with, but I'd rather give sources (at first). bpm contains code to do rm -rf <directory>, and if I've made a mistake somewhere, it could cause damage. So, if there is interest and there are no objections, I'd like to put this tool into the Boost repository, in tools/bpm.

5 10

[GIL] runtime assertion error
by Stephan Menzel 06 Jan '15

06 Jan '15

Hello, I was playing with GIL a little and started out with the tutorial. After adapting it a bit I noticed a runtime assertion error here in color_base.hpp +343: template <typename Element, typename Layout, int K> typename element_reference_type<homogeneous_color_base<Element,Layout,K> >::type dynamic_at_c(homogeneous_color_base<Element,Layout,K>& cb, std::size_t i) { assert(i<K); return (gil_reinterpret_cast<Element*>(&cb))[i]; } The example works if I compile in release but I still wanted to bring it up because of an extensive comment above this template that states that this assertion checks for compiler specific behavior and mentions flags that need to be set but not which flags. I believe there might be a bug there. Also, since it's the tutorial, I suppose it should work under most circumstances. I have a sample of the code attached. It's gcc 4.8 here in Linux 64. Nothing fancy. Boost 1.56. Cheers, Stephan

2 4

Library list generated from meta/libraries.json files
by Peter Dimov 06 Jan '15

06 Jan '15

I've put a library list generated from the meta/libraries.json files, at: http://www.pdimov.com/tmp/boost/index.html Library authors may wish to take a look at their library entry and see if they're happy with it. What I've noticed so far is that many libraries are missing the boost-version (First Release) entry, and that Config is missing authors for some reason. The other thing is that the category names in the json files are the internal identifiers, which I've left as-is, as I didn't want to hardcode a mapping. We'll have to decide whether to use the proper names in the json files, or whether to have a separate categories.json with the mapping somewhere. I tend towards the first option.

4 13

[status] explicit-failures-markup.xml edit permissions
by Vladimir Batov 05 Jan '15

05 Jan '15

On some compilers some of my SFINAE-related "convert" regression tests fail. So, I tried to update status/explicit-failures-markup.xml to explicitly mark those test failures rather than masking/disabling them. For understandable reasons I have no permissions to modify the file, so that update of mine was denied. I tried contacting Daniel James as he often helps me with build matters but he is seemingly unavailable. I am hoping someone else might have edit-permissions to the file and be kind enough to add the following code (below) to the file for me? My apologies for such a wide post or if my request is misdirected. Your help in the matter is much appreciated. Thanks, Vladimir.  <library name="convert"> <test name="convert_test_has_begin"> <mark-failure> <toolset name="msvc-8.0*"/> <toolset name="msvc-9.0*"/> <toolset name="msvc-10.0*"/> <toolset name="msvc-11.0*"/> <note author="Vladimir Batov"> The relevant SFINAE support is broken in MSVC up to version 11. </note> </mark-failure> </test> </library>

3 2

[functional] Is anyone maintaining it?
by Andrzej Krzemienski 05 Jan '15

05 Jan '15

Hi Everyone, I can see that the pull request I submitted at https://github.com/boostorg/functional almost three months ago has not been acted upon. Is the library still maintained? Regards, &rzej

2 1

[test] Problems with UTF-8 paths in GIT.
by Rene Rivera 05 Jan '15

05 Jan '15

This commit < https://github.com/boostorg/filesystem/commit/785d521b54140763dd23ef091a18d…> is causing me some problems with some git clients. In particular the git client in Eclipse errors out with some unsupported / invalid messages. I know why those dir names are the way they are.. But we still are supposed to follow the naming rules we agreed to < http://www.boost.org/development/requirements.html#Directory_structure>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 3

[filesystem] Problems with UTF-8 paths in GIT.
by Rene Rivera 05 Jan '15

05 Jan '15

Sorry.. I used the wrong tag :-( Now using the correct tag. On Mon, Jan 5, 2015 at 11:27 AM, Gennadiy Rozental <rogeeff(a)gmail.com> wrote: > Rene Rivera <grafikrobot <at> gmail.com> writes: > > Sorry, I might be missing something: what does this have to do with [test]? > > Gennadiy > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[githelp] Delete/hide branch..
by Rene Rivera 05 Jan '15

05 Jan '15

In cleaning up the "regression" subrepo.. I'm wanting to delete or hide the master branch as it: has horribly outdated code, and I'm only going to ever edit the develop branch. How do I delete or hide a branch? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[build,quickbook] complete doxygen output
by Gennadiy Rozental 05 Jan '15

05 Jan '15

> Maybe you can ask a separate thread, describing > what you want, so that Boost.Book experts notice it more easily? Hi, Per Vlad suggestion I am creating a separate thread about this. It should probably go into documentation list as well, but I am not sure how to do this in gmane interface > I would like to help, but Boost.Build only runs doxygen and then invokes > various XSLT tarnsforms. Everything else is either doxygen itself, or > Boost.Book, where I can only make trivial tweaks. What I am after is alternative rule, which will not try to make quickbook like output out of doxygen, but instead just leave it alone. So I need to run doxygen place the output somewhere and somehow point my quickbook based docs to that output. How would the Boost.Build rule look like? > What do you mean by 'bind' here? I want to bind references to class/function/module names to entries in generated doxygen docs. I am fine with some quickbook template I can apply, but automation would be even better. Gennadiy

2 1

libraries.json missing boost-version, update-version
by Peter Dimov 05 Jan '15

05 Jan '15

I notice that the library list at the website has a "First Release"entry for each library; these apparently come from the tag <boost-version> in libraries.xml, which also has an <update-version>. The meta/libraries.json files, however, appear to have no such data. Is this intentional?

2 1

[build] Tests automatically create header links, but library builds do not
by Peter Dimov 05 Jan '15

05 Jan '15

If I remove my boost/ directory, and attempt to build, for example, atomic, by going into libs/atomic/build and invoking b2, it fails due to a missing header: D:\tmp2\libs\atomic\build>b2 toolset=msvc-8.0 ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_8.0_vcvarsall_x86.cmd ...updated 1 target... ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_8.0_vcvarsall_x86_amd64.cmd ...updated 1 target... Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...found 208 targets... ...updating 5 targets... common.mkdir ..\..\..\bin.v2\libs\atomic\build\msvc-8.0\debug\threading-multi compile-c-c++ ..\..\..\bin.v2\libs\atomic\build\msvc-8.0\debug\threading-multi\lockpool.obj lockpool.cpp ..\..\..\boost/atomic/detail/ops_msvc_x86.hpp(20) : fatal error C1083: Cannot open include file: 'boost/type_traits/make_signed.hpp': No such file or directory [...] Same if I do b2 --with-atomic from root. However, if I go into, say, libs/smart_ptr/test and invoke b2 there, it works: D:\tmp2\libs\smart_ptr\test>b2 toolset=msvc-8.0 ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_8.0_vcvarsa ll_x86.cmd ...updated 1 target... ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_8.0_vcvarsa ll_x86_amd64.cmd ...updated 1 target... Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...patience... ...found 1722 targets... ...updating 1253 targets... common.mkdir ..\..\..\bin.v2\libs\smart_ptr common.mkdir ..\..\..\bin.v2\libs\smart_ptr\test common.mkdir ..\..\..\bin.v2\libs\smart_ptr\test\yield_k_test~mt.test common.mkdir ..\..\..\bin.v2\libs\smart_ptr\test\yield_k_test~mt.test\msvc-8.0 common.mkdir ..\..\..\bin.v2\libs\smart_ptr\test\yield_k_test~mt.test\msvc-8.0\debug common.mkdir ..\..\..\bin.v2\libs\smart_ptr\test\yield_k_test~mt.test\msvc-8.0\debug\threading-multi mklink-or-dir ..\..\..\boost\smart_ptr Junction created for ..\..\..\boost\smart_ptr <<===>> ..\include\boost\smart_ptr link.hardlink ..\..\..\boost\predef.h Hardlink created for ..\..\..\boost\predef.h <<===>> ..\..\predef\include\boost\predef.h [...] Why is that? My first thought was that this was due to the fact that I was missing libs/Jamfile.v2 (I do various "clean" installations as an experiment to see what's needed and what isn't), but I put it back there and it doesn't help.

4 15

Linux regression test runners - What do devs want?
by Tom Kent 05 Jan '15

05 Jan '15

I've been pondering this recently, but a forced upgrade of my azure VMs last night is pressing the issue...and I wanted to solicit feedback before I go and set things back up... I've currently been running three testing machines for linux, with several testers on each, (windows is completely separate, and I'm happy with how that is running)...here was my past strategy: teeks99-03 - develop - lots of compiler versions (all I could get to run on ubuntu 12.04: gcc-4.4-4.8, clang-3.0-3.4) teeks99-04 - develop - only two compilers, with fast turnaround times (gcc-4.8, clang-3.4) teeks99-05 - master - lots of compiler versions (all I could get to run on ubuntu 12.04: gcc-4.4-4.8, clang-3.0-3.4) I can try to set things up like this again, but there are two reasons I was thinking about changing: 1) It seems that a lot of the gcc/clang versions have the same pass/fail results as the other versions of that compiler, so we're not adding a ton (though we may be adding the crucial points where a compiler change breaks something...is this something that devs have seen in practice?) 2) The new version of my runners (Ubuntu 14.04) doesn't easily support the old gcc versions, it would take a lot of effort to get some of the old ones running. Clang is even worse...it is much more difficult to get even two versions running side by side now. Instead of running lots of different versions, I was thinking about running various compatibility options of the two main compilers...I've seen some other test runners with things like libc++, c++11, c++14, etc. My real question, would developers be better served by these options than different versions? Would they prefer both with longer revisit times between each test type? Other thoughts? Tom

6 5