On Tue, 2014-09-23 at 09:50 +0200, Bozo Dragojevic wrote: > On 22. 09. 14 19:57, Andrew Stitcher wrote: > > On Sun, 2014-09-21 at 23:43 +0200, Bozo Dragojevic wrote: > >> PROTON-660: Fix openssl.c build on windows > > Are you planning to do this work yourself? If so please take into > > account my last comments on this bug. I'd work on it myself except that > > I don't currently have the correct set up. If you can detail the set up > > (and it's not hard to set up) I'd do it. > > > > Yep, learning by doing :) What's the most convenient way for the review > process? > Patches to the mailing list? links to github commits? apache's reviewboard? > My guess is the later, except it's the most unfamiliar process to me :)
Reviewboard is currently best as it allows the most granular comments on the code itself - it can be a pain to set up, but it's usually not too bad. If we ever move to a git primary repo then github pull requests might work too. > > If you want to set up, just build openssl from source (which requires > ActivePerl iirc) > and just make sure to install in one of the locations that cmake looks at. I think that comes into the category of "too much effort"! > > > >> PROTON-691: allow proton to be built with add_subdirectory > > How important is this? The current way to integrate a proton build with > > another build is via the install directory, this seems to work well. > > > It's not super important, just very convenient. In that case I'd say without a patch to consider (there wasn't one attached to the JIRA when I looked) it can't be worth holding up 0.8. > > > Is there a specific scenario when you can't run 2 builds with a common > > install prefix? (This would actually probably make more sense added to > > the jira itself) > > > > The idea behind this is to get one build system (esp handy for VS and Xcode) > > We started with two build systems with the intermediate install step. > Since there always seem to be at least one proton bugfix waiting to go > upstream, > we keep track of a patched proton tree as a git submodule. For > development cycle > when one is working on said fixes it's really convenient to be able to > run our tests > in-tree quickly, skipping the install step. When proton stabilizes, all > this becomes irrelevant. > I think we are really focusing on getting Proton stabilised, to avoid this sort of thing. > I know such approach does not really scale because cmake's symbols are > not namespaced. > > So, if there is a more proper cmake-istic approach how to achieve a > similar workflow > I'd be happy to adapt in that direction. Not really. > > Bozzo
