On 2/7/2011 7:57 PM, Dave Abrahams wrote:
At Mon, 07 Feb 2011 09:53:52 -0600, Rene Rivera wrote:
What about a library developer? What does the tree structure they work with look like? How does integrate with their development repo? I guess the non-version controlled tree produced by the above could be used as a "complete (integrated) release tree", but I'd like to know the specifics, and give them a try.
I would also like to know:
1. How does that non-versioned complete integrated tree work as regards to updates/pulls?
Today, you call GenHeaders explicitly, but if you check out Marcus' work you don't have to.
I tried finding where & how Marcus did what you say, by going to the github link you give in the other response.. But I don't see what there you are referring to.
2. What does it mean for testing? Specifically, complete incremental testing?
Nothing? What, specifically, are you worried about?
OK.. How would we run the existing testing in incremental mode with a "forwarding headers tree plus separate sources"? What would testers need to rely on? Cmake? Python? Ryppl? Ctest? SSH? Git? FTP? HTTP? HTTPS? Git protocol?
3. Or is there no way to get a complete with source integrated tree?
Please define "complete with source integrated tree" so I can answer that question.
I mean a tree in the form we have it now, or equivalent to what we intend to *release* as the *single* Boost C++ Libraries package. I ask from a testing manager POV. I need to know what the changes might be for testers and me managing the testing infrastructure. And testers need to know what will be required of them. I'm not that interested in knowing what the experience is from the library developer POV, because I know Beman and others will investigate that aspect more fully than I could.
I'm worried as not having an easy way to get that would make testing rather difficult.
Note, I dont' consider "use ryppl", or "use cmake", as an acceptable answer ;-) As being locked into any particular tool is something I'm vehemently against.
I don't think I'd give you an answer like that to any of these questions. But that said, being "locked in" somehow is unavoidable; we're locked into SVN now aren't we? We're certainly locked into C++ and Python and Boost.Build and DocBook and BoostBook and QuickBook and... the list goes on. Or do you mean something distinct by "locked in?"
Note, I'm ignoring doc tools with this.. I guess I do mean something distinct by "locked in". The current set of tools, a good portion of them just scripts, do not in my view lock us in because they are relatively straightforward to move to something else that provides the basic equivalent functionality. This is because they map essentially to operations one could do by hand. But I do concede that is a rather thin definitional line ;-) My fear is that we end up with a system that is conceptually hard to understand how to put together and hence hard to make work. For example, testing at the moment doesn't depend on SVN. It's possible to download the tree as a tar archive through the almost universally available HTTP protocol. This is because we have testers, or at least have had testers, that can't do anything else. So if there's a requirement to have Git protocol access, that's likely a killer for testing. This is just one example. I'd have to see what the entire testing pipeline looks like to figure out where the "locked in" points are. I.e. I need to know what's actually going on, rather than just a "run this and that's it" answer. Hoping-that-I-didn't-confuse-things-more-ly ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail