You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gabriela Gibson <ga...@gmail.com> on 2013/01/01 22:17:00 UTC
Re: Proposal for OPW project
Hi All,
The following is a conversation that should have been held on the
list, please excuse the misunderstanding on my part.
> On 01.01.2013 15:09, Gabriela Gibson wrote:
> > Hi Brane,
> >
> > Daniel mentioned on the dev list that you are working on the C++
> > bindings and advised me to contact you and ask if you have any
> > suitable projects for me as an OPW intern.
> >
> > SWIG binding was my initial choice of project, but I was advised by
> > Stefan that it might be too difficult at my level of
> > experience/knowledge of the SVN api. Taking his advice, I changed to
> > the diff project at the last minute.
> >
> > However, my selected project is unlikely to keep me occupied for the
> > duration of the internship (I hope!). Daniel thinks that the some of
> > the C++ bindings might be a better entry point to binding work than
> > the SWIG bindings, if suitable projects exist.
> >
> > If you have any entry-level projects that I could get to work on, that
> > would be wonderful.
> >
> > Gabriela
On Tue, Jan 01, 2013 at 03:26:41PM +0100, Branko Čibej wrote:
> Hi Gabriela,
>
> The C++ bindings are in a very, very early stage of development.
> Basically just an idea with a few lines of code. There isn't even a
> design in place that could guide you in selecting which parts to
> implement; it's currently only a foggy notion in my head that we really
> should have a common object model for all the bindings, and that C++ may
> be a good starting point for designing one.
>
> Moreover, in one respect the C++ bindings have the same "problem" as the
> SWIG bindings -- you have to more or less know the whole C API in order
> to even begin designing the wrappers.
>
> There is one area that you may be able to help with, and that's setting
> up a proper test infrastructure for the C++ bindings. I'm planning to
> use Google's C++ test framework for that (see:
> http://code.google.com/p/googletest/). This would involve teaching
> configure and gen-make.py to find the GTest sources (very
> platform-specific) and rewiring the build generator to compile and link
> test programs with the GTest libs. I also have two test cases that could
> be easily converted to GTest.
>
> It's not really much work, but I've been putting it off for lack of
> time. So, if you don't mind digging into the mess that's our build
> system, you're welcome to have a go if you find yourself with enough
> time on your hands. I'll be more than happy to help you find your way
> through the less obvious parts.
>
> -- Brane
>
Hi Brane and everyone here,
I've used configure and friends before, albeit in a much smaller
setting, so the territory looks familiar.
Googletest and virtual hosts also looks also like good tools to know
about -- I'll need some reading-in time, but I'm confident I can take
this project on. Could you please send me the two test cases and I'll
have a go?
regards,
Gabriela
Re: [PATCH]: Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 03.01.2013 23:27, Gabriela Gibson wrote:
> Change default behaviour of get_deps.sh from downloading gtest
> library to making it an optional target.
>
> * get-deps.sh
> (usage): Add gtest to list of possible arguments.
> (get_deps): Remove gtest from list of default downloads.
>
> Patch by: Gabriela Gibson
Committed in r1428689. Thanks!
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
[PATCH]: Re: Proposal for OPW project
Posted by Gabriela Gibson <ga...@gmail.com>.
On Thu, Jan 03, 2013 at 06:09:33AM +0200, Daniel Shahaf wrote:
>
> Something's missing.
>
> If gtest is a dependency of svn 1.8, you should add it to the usage
> message of the script; if it's not, there's no reason to download it in
> the argc == 1 branch.
I have attached a patch, thank you for the comments.
Re: [PATCH]: Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 03.01.2013 05:09, Daniel Shahaf wrote:
> Gabriela Gibson wrote on Wed, Jan 02, 2013 at 09:21:01 +0000:
>> On 02/01/13 00:55, Branko Čibej wrote:
>>> On 01.01.2013 22:17, Gabriela Gibson wrote:
>>>> Hi Brane and everyone here,
>>>>
>>>> I've used configure and friends before, albeit in a much smaller
>>>> setting, so the territory looks familiar.
>>>>
>>>> Googletest and virtual hosts also looks also like good tools to know
>>>> about -- I'll need some reading-in time, but I'm confident I can take
>>>> this project on. Could you please send me the two test cases and I'll
>>>> have a go?
>>> See:
>>>
>>> subversion/bindings/cxxhl/tests/test_exception.cpp
>>>
>>> A suggestion about dealing with Ggoogle Test: We have to build the GTest
>>> libraries from source with the same compiler options as the rest of the
>>> library, see
>>>
>>> http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
>>>
>>> On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
>>> sources in /usr/src/gtest and the headers in /usr/include/gtest. I
>>> propose we make our configury do something similar to what we do with
>>> SQLite amalgamation; e.g., get-deps.sh could download and unpack the
>>> GTest sources into ./gtest, and configure could find them there unless
>>> told to look elsewhere.
>>>
>>> Windows will be a bit trickier, but if you can make it work on Linux,
>>> that's quite good enough, so don't worry about Windows at this point.
>>>
>>> -- Brane
>>>
>>>
>> Ok, patch for get-deps.sh attached.
>>
>> I have a question on the compilation process though. Gtest has
>> deprecated autoconf. The remaining options are to use cmake or
>> our own target. Do you agree that a target in the Subversion Makefile
>> is preferred?
>>
>> [[[
>> Changes to get-deps.sh to download gtest
>>
>> * get-deps.sh:
>> (Variable definitions): Adds three "GTEST_*" variables to assist in
>> downloading gtest sources
>> (get_gtest): New function: Download, unzip and move gtest source.
>> (get_deps): Check whether gtest is available
>> Call get_gtest()
>>
>> Patch by: <ga...@gmail.com>
>> ]]]
>> Index: get-deps.sh
>> ===================================================================
>> --- get-deps.sh (revision 1427508)
>> +++ get-deps.sh (working copy)
>> @@ -29,6 +29,9 @@ SERF=serf-1.1.1
>> ZLIB=zlib-1.2.7
>> SQLITE_VERSION=3.7.15.1
>> SQLITE=sqlite-amalgamation-$(printf %d%02d%02d%02d $(echo $SQLITE_VERSION | sed -e 's/\./ /g'))
>> +GTEST_VERSION=1.6.0
>> +GTEST=gtest-${GTEST_VERSION}
>> +GTEST_URL=http://googletest.googlecode.com/files/
>>
>> HTTPD=httpd-2.4.3
>> APR_ICONV=apr-iconv-1.2.1
>> @@ -103,11 +106,23 @@ get_sqlite() {
>>
>> }
>>
>> +get_gtest() {
>> + test -d $BASEDIR/gtest && return
>> +
>> + cd $TEMPDIR
>> + $HTTP_FETCH ${GTEST_URL}/${GTEST}.zip
>> + cd $BASEDIR
>> +
>> + unzip -q $TEMPDIR/$GTEST.zip
>> +
>> + mv $GTEST gtest
>> +}
>> +
>> # main()
>> get_deps() {
>> mkdir -p $TEMPDIR
>>
>> - for i in zlib serf sqlite-amalgamation apr apr-util; do
>> + for i in zlib serf sqlite-amalgamation apr apr-util gtest; do
>> if [ -d $i ]; then
>> echo "Local directory '$i' already exists; the downloaded copy won't be used" >&2
>> fi
>> @@ -126,6 +141,7 @@ get_deps() {
>> get_serf
>> get_zlib
>> get_sqlite
>> + get_gtest
>>
> Something's missing.
>
> If gtest is a dependency of svn 1.8, you should add it to the usage
> message of the script; if it's not, there's no reason to download it in
> the argc == 1 branch.
It's going to become an optional dependency of a non-default build
target. So I agree it shouldn't be downloaded by default. My bad, I
should have reviewed it a bit more before committing.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [PATCH]: Re: Proposal for OPW project
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Wed, Jan 02, 2013 at 09:21:01 +0000:
> On 02/01/13 00:55, Branko Čibej wrote:
>> On 01.01.2013 22:17, Gabriela Gibson wrote:
>>> Hi Brane and everyone here,
>>>
>>> I've used configure and friends before, albeit in a much smaller
>>> setting, so the territory looks familiar.
>>>
>>> Googletest and virtual hosts also looks also like good tools to know
>>> about -- I'll need some reading-in time, but I'm confident I can take
>>> this project on. Could you please send me the two test cases and I'll
>>> have a go?
>>
>> See:
>>
>> subversion/bindings/cxxhl/tests/test_exception.cpp
>>
>> A suggestion about dealing with Ggoogle Test: We have to build the GTest
>> libraries from source with the same compiler options as the rest of the
>> library, see
>>
>> http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
>>
>> On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
>> sources in /usr/src/gtest and the headers in /usr/include/gtest. I
>> propose we make our configury do something similar to what we do with
>> SQLite amalgamation; e.g., get-deps.sh could download and unpack the
>> GTest sources into ./gtest, and configure could find them there unless
>> told to look elsewhere.
>>
>> Windows will be a bit trickier, but if you can make it work on Linux,
>> that's quite good enough, so don't worry about Windows at this point.
>>
>> -- Brane
>>
>>
> Ok, patch for get-deps.sh attached.
>
> I have a question on the compilation process though. Gtest has
> deprecated autoconf. The remaining options are to use cmake or
> our own target. Do you agree that a target in the Subversion Makefile
> is preferred?
>
> [[[
> Changes to get-deps.sh to download gtest
>
> * get-deps.sh:
> (Variable definitions): Adds three "GTEST_*" variables to assist in
> downloading gtest sources
> (get_gtest): New function: Download, unzip and move gtest source.
> (get_deps): Check whether gtest is available
> Call get_gtest()
>
> Patch by: <ga...@gmail.com>
> ]]]
> Index: get-deps.sh
> ===================================================================
> --- get-deps.sh (revision 1427508)
> +++ get-deps.sh (working copy)
> @@ -29,6 +29,9 @@ SERF=serf-1.1.1
> ZLIB=zlib-1.2.7
> SQLITE_VERSION=3.7.15.1
> SQLITE=sqlite-amalgamation-$(printf %d%02d%02d%02d $(echo $SQLITE_VERSION | sed -e 's/\./ /g'))
> +GTEST_VERSION=1.6.0
> +GTEST=gtest-${GTEST_VERSION}
> +GTEST_URL=http://googletest.googlecode.com/files/
>
> HTTPD=httpd-2.4.3
> APR_ICONV=apr-iconv-1.2.1
> @@ -103,11 +106,23 @@ get_sqlite() {
>
> }
>
> +get_gtest() {
> + test -d $BASEDIR/gtest && return
> +
> + cd $TEMPDIR
> + $HTTP_FETCH ${GTEST_URL}/${GTEST}.zip
> + cd $BASEDIR
> +
> + unzip -q $TEMPDIR/$GTEST.zip
> +
> + mv $GTEST gtest
> +}
> +
> # main()
> get_deps() {
> mkdir -p $TEMPDIR
>
> - for i in zlib serf sqlite-amalgamation apr apr-util; do
> + for i in zlib serf sqlite-amalgamation apr apr-util gtest; do
> if [ -d $i ]; then
> echo "Local directory '$i' already exists; the downloaded copy won't be used" >&2
> fi
> @@ -126,6 +141,7 @@ get_deps() {
> get_serf
> get_zlib
> get_sqlite
> + get_gtest
>
Something's missing.
If gtest is a dependency of svn 1.8, you should add it to the usage
message of the script; if it's not, there's no reason to download it in
the argc == 1 branch.
> echo
> echo "If you require mod_dav_svn, the recommended version of httpd is:"
Re: [PATCH]: Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 02.01.2013 10:21, Gabriela Gibson wrote:
> Ok, patch for get-deps.sh attached.
Nice! Committed in r1427728.
I also added gtest to svn:ignore, and made a couple very minor
grammatical fixes in the log message -- adding full-stops to the end of
sentences.
> I have a question on the compilation process though. Gtest has
> deprecated autoconf. The remaining options are to use cmake or
> our own target. Do you agree that a target in the Subversion Makefile
> is preferred?
Given that we do not use cmake, making our own target is the only
reasonable alternative -- remember that we have to use the exact same
compiler and options. Happily that's not so hard, given that gtest is a
very clean build.
Note that you won't be touching Makefile.in at all for that -- the
source of the build configuration is build.conf.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
[PATCH]: Re: Proposal for OPW project
Posted by Gabriela Gibson <ga...@gmail.com>.
On 02/01/13 00:55, Branko Čibej wrote:
> On 01.01.2013 22:17, Gabriela Gibson wrote:
>> Hi Brane and everyone here,
>>
>> I've used configure and friends before, albeit in a much smaller
>> setting, so the territory looks familiar.
>>
>> Googletest and virtual hosts also looks also like good tools to know
>> about -- I'll need some reading-in time, but I'm confident I can take
>> this project on. Could you please send me the two test cases and I'll
>> have a go?
>
> See:
>
> subversion/bindings/cxxhl/tests/test_exception.cpp
>
> A suggestion about dealing with Ggoogle Test: We have to build the GTest
> libraries from source with the same compiler options as the rest of the
> library, see
>
> http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
>
> On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
> sources in /usr/src/gtest and the headers in /usr/include/gtest. I
> propose we make our configury do something similar to what we do with
> SQLite amalgamation; e.g., get-deps.sh could download and unpack the
> GTest sources into ./gtest, and configure could find them there unless
> told to look elsewhere.
>
> Windows will be a bit trickier, but if you can make it work on Linux,
> that's quite good enough, so don't worry about Windows at this point.
>
> -- Brane
>
>
Ok, patch for get-deps.sh attached.
I have a question on the compilation process though. Gtest has
deprecated autoconf. The remaining options are to use cmake or
our own target. Do you agree that a target in the Subversion Makefile
is preferred?
Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 01.01.2013 22:17, Gabriela Gibson wrote:
> Hi Brane and everyone here,
>
> I've used configure and friends before, albeit in a much smaller
> setting, so the territory looks familiar.
>
> Googletest and virtual hosts also looks also like good tools to know
> about -- I'll need some reading-in time, but I'm confident I can take
> this project on. Could you please send me the two test cases and I'll
> have a go?
See:
subversion/bindings/cxxhl/tests/test_exception.cpp
A suggestion about dealing with Ggoogle Test: We have to build the GTest
libraries from source with the same compiler options as the rest of the
library, see
http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
sources in /usr/src/gtest and the headers in /usr/include/gtest. I
propose we make our configury do something similar to what we do with
SQLite amalgamation; e.g., get-deps.sh could download and unpack the
GTest sources into ./gtest, and configure could find them there unless
told to look elsewhere.
Windows will be a bit trickier, but if you can make it work on Linux,
that's quite good enough, so don't worry about Windows at this point.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Proposal for OPW project
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 1, 2013 at 4:17 PM, Gabriela Gibson
<ga...@gmail.com>wrote:
> The following is a conversation that should have been held on the
> list, please excuse the misunderstanding on my part.
>
No worries - we've all been there before. You'll get the hang of it soon
enough. =) Keep up the posts!
Cheers. -- justin