FYI.. to those that care.. I checked in changes to SVN to inject the Predef library into Boost. I say inject because the source is not actually in the SVN repo, it's external and still in github. But is being brought in through their SVN interface. Some testers have already runs the tests for it.. And at some point to be determined with some coordination with the community I will switch the "boost/detail/endian.hpp" header to point to the Predef compatibility equivalent... I suspect at the earliest one more week for that assuming no problems surface. 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
Hi Rene, On Sunday, 28. July 2013 20:51:59 Rene Rivera wrote:
FYI.. to those that care.. I checked in changes to SVN to inject the Predef library into Boost. I say inject because the source is not actually in the SVN repo, it's external and still in github. But is being brought in through their SVN interface.
Thanks for the explanation. Unfortunately, injection via "svn:externals" breaks all "git svn" (unofficial) mirrors and working copies. "git svn" just does not track externals right now. No big problem, I will just checkout a pure svn copy until the git convertion is finished.
Some testers have already runs the tests for it.. And at some point to be determined with some coordination with the community I will switch the "boost/detail/endian.hpp" header to point to the Predef compatibility equivalent... I suspect at the earliest one more week for that assuming no problems surface.
Yes, this sounds good. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On Mon, Jul 29, 2013 at 5:51 AM, Rene Rivera
FYI.. to those that care.. I checked in changes to SVN to inject the Predef library into Boost. I say inject because the source is not actually in the SVN repo, it's external and still in github. But is being brought in through their SVN interface.
Weren't externals banned from Boost SVN long time ago?
On Jul 29, 2013, at 1:27 AM, Andrey Semashev
On Mon, Jul 29, 2013 at 5:51 AM, Rene Rivera
wrote: FYI.. to those that care.. I checked in changes to SVN to inject the Predef library into Boost. I say inject because the source is not actually in the SVN repo, it's external and still in github. But is being brought in through their SVN interface.
Weren't externals banned from Boost SVN long time ago?
I couldn't find anything about it in the list archives. Maybe your google fu is better than mine. That being said, my scripts all hung this morning, because svn wanted me to confirm a (new) ssh fingerprint for github.com. This was definitely a WTF moment for me - "I am checking out boost, why is it asking about github?" Can't say I'm in favor of it. -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Mon, Jul 29, 2013 at 8:22 AM, Marshall Clow
On Jul 29, 2013, at 1:27 AM, Andrey Semashev
wrote: FYI.. to those that care.. I checked in changes to SVN to inject the Predef library into Boost. I say inject because the source is not actually in
On Mon, Jul 29, 2013 at 5:51 AM, Rene Rivera
wrote: the SVN repo, it's external and still in github. But is being brought in through their SVN interface.
Weren't externals banned from Boost SVN long time ago?
I couldn't find anything about it in the list archives. Maybe your google fu is better than mine.
That being said, my scripts all hung this morning, because svn wanted me to confirm a (new) ssh fingerprint for github.com. This was definitely a WTF moment for me - "I am checking out boost, why is it asking about github?"
Sorry about that.. I guess I should have posted about it in the testing list also just as an additional warning.
Can't say I'm in favor of it.
I'm not in favor of it either :-) But after I tried a few other alternatives this was the only that worked without a bunch more work on my part (either up front or continuously). But if anyone has alternatives I'm happy to try them. Here's what I tried.. Manually copying over changes from git to svn (lots of labor all the time and prone to errors); Writing a script to copy/merge/delete changes (hard to get working reliably); Getting git to mirror the modular structure in a non-modular git equivalent inside a Boost svn checkout (couldn't find a way to actually get this to work and seemed dangerous to intermix the two); Using links on my local checkout to mostly automatically reflect my local git to my local svn (because there are links to directories and hence symbolic svn can't deal with them to accomplish the effect). 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
I'm not in favor of it either :-) But after I tried a few other alternatives this was the only that worked without a bunch more work on my part (either up front or continuously). But if anyone has alternatives I'm happy to try them. Here's what I tried.. Manually copying over changes from git to svn (lots of labor all the time and prone to errors); Writing a script to copy/merge/delete changes (hard to get working reliably); Getting git to mirror the modular structure in a non-modular git equivalent inside a Boost svn checkout (couldn't find a way to actually get this to work and seemed dangerous to intermix the two); Using links on my local checkout to mostly automatically reflect my local git to my local svn (because there are links to directories and hence symbolic svn can't deal with them to accomplish the effect).
I've had good success with subgit in getting git and svn repos to always stay two way mirrors of one another. See https://github.com/ned14/boost-trunk for an example, though I've disabled the git to svn mirror there as all commits to github would appear under ned14 in svn because I never bothered with configuring the two way map. Note that subgit needs about 250Mb of RAM, sustained. It also introduces a certain amount of lag to both git and svn commits in order to duplicate the commit. As a temporary measure until we can drop svn forever, it's doable. Note that subgit can be configured to handle a modularized, decentralized git or svn structure, but that is probably significant work as you won't be able to reuse much of the existing scripts. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.
On Monday 29 July 2013 06:22:09 Marshall Clow wrote:
On Jul 29, 2013, at 1:27 AM, Andrey Semashev
wrote: On Mon, Jul 29, 2013 at 5:51 AM, Rene Rivera
wrote: FYI.. to those that care.. I checked in changes to SVN to inject the Predef library into Boost. I say inject because the source is not actually in the SVN repo, it's external and still in github. But is being brought in through their SVN interface.
Weren't externals banned from Boost SVN long time ago?
I couldn't find anything about it in the list archives. Maybe your google fu is better than mine.
I don't remember the exact post that made the official position regarding externals, but I remember there were concerns about them when we were switching to SVN. Here are some: http://thread.gmane.org/gmane.comp.lib.boost.devel/122110/focus=122119 http://thread.gmane.org/gmane.comp.lib.boost.devel/160386/focus=160491 To my recollection the final outcome was that we just don't use externals. I believe the branching issue still remains valid now for Boost.Predef (i.e. when branching 1.55, Boost.Predef will cause trouble).
On Tue, Jul 30, 2013 at 10:34 PM, Andrey Semashev wrote: I believe the branching issue still remains valid now for Boost.Predef
(i.e.
when branching 1.55, Boost.Predef will cause trouble). Given the temporary nature of this, I hope.. I decided that the "easiest"
was to write a short shell script to create/update the hardlinks to files
so that I can edit only "one source". But of course will have to commit
twice, once for git and another for svn.
So.. No more externals from Predef.
--
--
-- 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
On Wednesday 31 July 2013 22:51:05 Rene Rivera wrote:
On Tue, Jul 30, 2013 at 10:34 PM, Andrey Semashev
wrote:
I believe the branching issue still remains valid now for Boost.Predef (i.e. when branching 1.55, Boost.Predef will cause trouble).
Given the temporary nature of this, I hope.. I decided that the "easiest" was to write a short shell script to create/update the hardlinks to files so that I can edit only "one source". But of course will have to commit twice, once for git and another for svn.
So.. No more externals from Predef.
Thank you Rene. And a special thanks for the library. :)
On Jul 31, 2013, at 8:51 PM, Rene Rivera
On Tue, Jul 30, 2013 at 10:34 PM, Andrey Semashev
wrote:
I believe the branching issue still remains valid now for Boost.Predef (i.e. when branching 1.55, Boost.Predef will cause trouble).
Given the temporary nature of this, I hope.. I decided that the "easiest" was to write a short shell script to create/update the hardlinks to files so that I can edit only "one source". But of course will have to commit twice, once for git and another for svn.
So.. No more externals from Predef.
Yes, thanks! -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 7/28/2013 7:51 PM, Rene Rivera wrote:
FYI.. to those that care.. I checked in changes to SVN to inject the Predef library into Boost. I say inject because the source is not actually in the SVN repo, it's external and still in github. But is being brought in through their SVN interface.
Hey Rene, For some reason the VeecoFTC regression tester that we run on trunk for testing Windows Mobile appears to have broken after the addition of Predef. I don't have any good explanation for why this would be, but the end of the bjam.log now looks like this: D:/BoostRT/tools_bb/tools\builtin.jam:885: in linking-generator.generated-targets *** argument error * rule generator.generated-targets ( sources + : property-set : project name ? ) * called with: ( : object(property-set)@83655 : object(project-target)@9964 info_as_objcpp ) * missing argument sources D:/BoostRT/tools_bb/build\generators.jam:536:see definition of rule 'generator.generated-targets' being called D:/BoostRT/tools_bb/tools\msvc.jam:1083: in generated-targets D:/BoostRT/tools_bb/build\generators.jam:459: in construct-result D:/BoostRT/tools_bb/build\generators.jam:412: in run-really D:/BoostRT/tools_bb/build\generators.jam:386: in generator.run D:/BoostRT/tools_bb/tools\builtin.jam:800: in object(msvc-linking-generator)@91.run D:/BoostRT/tools_bb/build\generators.jam:994: in try-one-generator-really D:/BoostRT/tools_bb/build\generators.jam:1056: in try-one-generator D:/BoostRT/tools_bb/build\generators.jam:1294: in construct-really D:/BoostRT/tools_bb/build\generators.jam:1378: in construct D:/BoostRT/tools_bb/build\generators.jam:1069: in generators.construct-types D:/BoostRT/tools_bb/build\generators.jam:609: in convert-to-consumable-types D:/BoostRT/tools_bb/build\generators.jam:405: in run-really D:/BoostRT/tools_bb/build\generators.jam:386: in object(generator)@136.run D:/BoostRT/tools_bb/build\generators.jam:994: in try-one-generator-really D:/BoostRT/tools_bb/build\generators.jam:1056: in try-one-generator D:/BoostRT/tools_bb/build\generators.jam:1294: in construct-really D:/BoostRT/tools_bb/build\generators.jam:1378: in construct D:/BoostRT/tools_bb/build\generators.jam:1069: in generators.construct-types D:/BoostRT/tools_bb/build\generators.jam:609: in convert-to-consumable-types D:/BoostRT/tools_bb/build\generators.jam:405: in run-really D:/BoostRT/tools_bb/build\generators.jam:386: in object(generator)@132.run D:/BoostRT/tools_bb/build\generators.jam:994: in try-one-generator-really D:/BoostRT/tools_bb/build\generators.jam:1056: in try-one-generator D:/BoostRT/tools_bb/build\generators.jam:1294: in construct-really D:/BoostRT/tools_bb/build\generators.jam:1378: in generators.construct D:/BoostRT/tools_bb/build\targets.jam:1532: in construct D:/BoostRT/tools_bb/build\targets.jam:1332: in object(typed-target)@9975.generate D:/BoostRT/tools_bb/build\targets.jam:757: in generate-really D:/BoostRT/tools_bb/build\targets.jam:729: in object(main-target)@77732.generate D:/BoostRT/tools_bb/build\targets.jam:874: in targets.generate-from-reference D:/BoostRT/tools_bb/build\targets.jam:1245: in generate-dependencies D:/BoostRT/tools_bb/build\targets.jam:1302: in object(alias-target-class)@9984.generate D:/BoostRT/tools_bb/build\targets.jam:757: in generate-really D:/BoostRT/tools_bb/build\targets.jam:729: in object(main-target)@77736.generate D:/BoostRT/tools_bb/build\targets.jam:272: in object(project-target)@9964.generate D:/BoostRT/tools_bb/build\targets.jam:272: in object(project-target)@1151.generate D:/BoostRT/tools_bb\build-system.jam:707: in load D:\BoostRT\tools_bb/kernel\modules.jam:289: in import D:\BoostRT\tools_bb/kernel/bootstrap.jam:139: in boost-build D:\BoostRT\boost\boost-build.jam:17: in module scope I feel like I have encountered and resolved an issue like this in the past, but can't seem to remember what triggers this error. Any thoughts? (or any diagnostics that I should turn on to check for the problem?) Thanks, -Dave
participants (6)
-
Andrey Semashev
-
David Deakins
-
Jürgen Hunold
-
Marshall Clow
-
Niall Douglas
-
Rene Rivera