On 24/04/15 20:31, Martti Kühne wrote:

On Fri, Apr 24, 2015 at 6:25 PM, Sebastian Lau wrote:

...

Hi,

At the moment I'm trying to rewrite grive [1], because its maintainer did not migrate it to the new Google APIs. After reviewing the code, I decided, that maybe using the google api cpp client libraries would be a good choice since the original author of grive did implement similar things as the official google API[2] does.

So I created packages for those APIs in the AUR[3]. Everything fine so far.

The problem is, google is using an old version (3.7) of the simple embedded webserver mongoose[4] as backend in its current stable release[5]. I tried using the current version of mongoose, but the developers have some functions removed that google uses. So I'm stuck with using version 3.7 .

Since however cmake won't build shared libraries (even with -DBUILD_SHARED=ON) of google-api-cpp-client, mongoose is already statically linked into the libgoogleapis_mongoose.a . The only problem is that one header of googleapis (mongoose_webserver.h) has the line "#include ". No problem for compilation, but when using the headers in an own project, there won't be any file at this place. The mongoose 5 package in AUR installs its header to '/usr/include/mongoose.h'.

So I'm stuck with the question wether - to create a new package "mongoose3" for the header only since nothing more is needed (more dependencies) and hope for google fixing that issue with the next more current release or - just include the mongoose header in "/usr/include/mongoose3.h", patch the include in google webserver to use that file and include the license of mongoose version 3 in my google-api-cpp-client package.

Personally, I'd prefer the second conclusion since AFAIK no other package needs this header and google is working on its web section on the master branch, so it probably won't be needed anymore in near future. But I'm not sure, so it would be nice to have your opinion on that.

Greets,

Sebastian

[1] https://aur.archlinux.org/packages/grive/ [2] https://github.com/google/google-api-cpp-client/tree/v0.1 [3] https://aur.archlinux.org/packages/?O=0&C=0&SeB=nd&K=google-api-cpp&outdated=&SB=n&SO=a&PP=50&do_Search=Go [4] https://github.com/cesanta/mongoose [5] https://aur.archlinux.org/packages/google-api-cpp-client/

That's a case for our old friend

sed -r -i 's@(#include <)mongoose/(mongoose\.h>)@\1\2@'

This change may be implemented using an additional diff source file or with a different sed line, but I particularly like sed -r for being not as backslashy for when I need groups.

cheers! mar77i Hi,

Thanks, but that's not the issue. I could create a patch or use sed, if I knew the right way to package this. The main question is wether it is better to include that header (originally not belonging to another program) in the google C++ APIs package (since no other package needs that file) or to create an extra package like mongoose3 with that file only (since that would be the right way - it is an header from another program). Regards, Sebastian

On 24/04/15 20:31, Martti Kühne wrote:

On Fri, Apr 24, 2015 at 6:25 PM, Sebastian Lau wrote:

...

Hi,

At the moment I'm trying to rewrite grive [1], because its maintainer did not migrate it to the new Google APIs. After reviewing the code, I decided, that maybe using the google api cpp client libraries would be a good choice since the original author of grive did implement similar things as the official google API[2] does.

So I created packages for those APIs in the AUR[3]. Everything fine so far.

The problem is, google is using an old version (3.7) of the simple embedded webserver mongoose[4] as backend in its current stable release[5]. I tried using the current version of mongoose, but the developers have some functions removed that google uses. So I'm stuck with using version 3.7 .

Since however cmake won't build shared libraries (even with -DBUILD_SHARED=ON) of google-api-cpp-client, mongoose is already statically linked into the libgoogleapis_mongoose.a . The only problem is that one header of googleapis (mongoose_webserver.h) has the line "#include ". No problem for compilation, but when using the headers in an own project, there won't be any file at this place. The mongoose 5 package in AUR installs its header to '/usr/include/mongoose.h'.

So I'm stuck with the question wether - to create a new package "mongoose3" for the header only since nothing more is needed (more dependencies) and hope for google fixing that issue with the next more current release or - just include the mongoose header in "/usr/include/mongoose3.h", patch the include in google webserver to use that file and include the license of mongoose version 3 in my google-api-cpp-client package.

Personally, I'd prefer the second conclusion since AFAIK no other package needs this header and google is working on its web section on the master branch, so it probably won't be needed anymore in near future. But I'm not sure, so it would be nice to have your opinion on that.

Greets,

Sebastian

[1] https://aur.archlinux.org/packages/grive/ [2] https://github.com/google/google-api-cpp-client/tree/v0.1 [3] https://aur.archlinux.org/packages/?O=0&C=0&SeB=nd&K=google-api-cpp&outdated=&SB=n&SO=a&PP=50&do_Search=Go [4] https://github.com/cesanta/mongoose [5] https://aur.archlinux.org/packages/google-api-cpp-client/ That's a case for our old friend

sed -r -i 's@(#include <)mongoose/(mongoose\.h>)@\1\2@'

This change may be implemented using an additional diff source file or with a different sed line, but I particularly like sed -r for being not as backslashy for when I need groups.

cheers! mar77i

Hi, Thanks, but that's not the issue. I could create a patch or use sed, if I knew the right way to package this. The main question is wether it is better to include that header (originally belonging to another program) in the google C++ APIs package (since no other package needs that file) or to create an extra package like mongoose3 with that file only (since that would be the right way - it is an header from another program). Regards, Sebastian