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 :) 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. >> 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. > 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 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. Bozzo
