retreiving the libraries the maven way?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

retreiving the libraries the maven way?

Nicolas Herbaut
Hello,

I started working on a new c++ project comming back after 4+ years of
java coding.

For java, I use nexus, which is a binary repository server, that
provides an nice REST API that allows clients to download dependencies
by providing the library name and a target version.

I'm wondering if it would be feasible and difficult to port this logic
into a cmake plugin, and allowing the find_library to seamlessly
retreive the library from the system OR from a nexus server.

currently all our dependencies are stored in the svn, which slows down
our builds and is not very flexible.

Let me be more specific by describing my usecase.

1- On a Windows PC, I need the zlib dll and the standard C dll to build
my project
2- I issue a find_library command specifying both custom library paths
and a nexus server URL
3 - for the standard C library, cmake findsout that it's already located
into the system
4 - for zlib, cmake performs a request to the server which acknowledge
the availability of the dll
5 - cmake downloads the library in a cache folder and tells the
generator to link to the library it downloaded
6 - if the library cannot be found on the system and on the binary
server, cmake fails
7 - the same thing happen on a mac system, but this time both the C lib
and zlib are on the path, hence binary server is not even queried for a lib.

Could you guys give me your insights for this project?


--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: retreiving the libraries the maven way?

Andreas Pakulat-2
Hi,

On Mon, Jan 14, 2013 at 9:17 AM, Nicolas Herbaut <[hidden email]> wrote:

> I started working on a new c++ project comming back after 4+ years of java
> coding.
>
> For java, I use nexus, which is a binary repository server, that provides an
> nice REST API that allows clients to download dependencies by providing the
> library name and a target version.
>
> I'm wondering if it would be feasible and difficult to port this logic into
> a cmake plugin, and allowing the find_library to seamlessly retreive the
> library from the system OR from a nexus server.
>
> currently all our dependencies are stored in the svn, which slows down our
> builds and is not very flexible.
>
> Let me be more specific by describing my usecase.
>
> 1- On a Windows PC, I need the zlib dll and the standard C dll to build my
> project
> 2- I issue a find_library command specifying both custom library paths and a
> nexus server URL
> 3 - for the standard C library, cmake findsout that it's already located
> into the system
> 4 - for zlib, cmake performs a request to the server which acknowledge the
> availability of the dll
> 5 - cmake downloads the library in a cache folder and tells the generator to
> link to the library it downloaded
> 6 - if the library cannot be found on the system and on the binary server,
> cmake fails
> 7 - the same thing happen on a mac system, but this time both the C lib and
> zlib are on the path, hence binary server is not even queried for a lib.

I think for C++ this is lot more impractical than for Java because
compiled C++ code is inherently unportable. You get a really big
matrix of versions, compilers and platforms. For example on windows
you have 6 msvc compilers in 2 architectures, 2 gcc-variants in 2
architectures, intel in 2 architectures. Possibly you'd even need
different versions for different windows versions. For MacOSX you only
have 2 compilers usually per MacOSX version you want to support. On
Linux there are breakages of the libc or libstdc++ ABI every few
years. And you'd have to multiply that with the number of versions
zlib provides. And then multiply that by the number of libraries you
want to support.

Its not undoable, but its a huge amount of libs a lot that can go
wrong and a lot to build up and maintain in the first place.

In addition to that, CMake has no plugin system I believe, so you'd
have to add that to the source code itself.

Andreas
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: retreiving the libraries the maven way?

Andreas Haferburg
In reply to this post by Nicolas Herbaut
CMake doesn't support this out of the box. For most library dependencies, it's not even possible to
retrieve their version, because either the FindXYZ scripts aren't written properly, or because the
library doesn't provide it in the first place. Every library and every Find script does things
differently. E.g. some find scripts use find_package(Lib) and define Lib_FOUND, others LIB_FOUND. My
favorite: find_package(Qt4) defines QT4_FOUND, but ALL OTHER variables are prefixed with "QT_".

I ended up setting up a library directory on our server which follows a simple naming convention,
<lib>-<version>-<compiler>. On the local developer machines, a similar directory exists for the
libraries. If a particular library directory doesn't exist locally, it is fetched from the server.
Simple, stupid, but since there is no meta information available as part of c++ libraries, that's
the best I could come up with. If you need more help I can post some scripts.

Best regards
Andreas


On 14.01.2013 09:17, Nicolas Herbaut wrote:

> Hello,
>
> I started working on a new c++ project comming back after 4+ years of java coding.
>
> For java, I use nexus, which is a binary repository server, that provides an nice REST API that
> allows clients to download dependencies by providing the library name and a target version.
>
> I'm wondering if it would be feasible and difficult to port this logic into a cmake plugin, and
> allowing the find_library to seamlessly retreive the library from the system OR from a nexus server.
>
> currently all our dependencies are stored in the svn, which slows down our builds and is not very
> flexible.
>
> Let me be more specific by describing my usecase.
>
> 1- On a Windows PC, I need the zlib dll and the standard C dll to build my project
> 2- I issue a find_library command specifying both custom library paths and a nexus server URL
> 3 - for the standard C library, cmake findsout that it's already located into the system
> 4 - for zlib, cmake performs a request to the server which acknowledge the availability of the dll
> 5 - cmake downloads the library in a cache folder and tells the generator to link to the library it
> downloaded
> 6 - if the library cannot be found on the system and on the binary server, cmake fails
> 7 - the same thing happen on a mac system, but this time both the C lib and zlib are on the path,
> hence binary server is not even queried for a lib.
>
> Could you guys give me your insights for this project?
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake


--
Scopis GmbH
Blücherstr. 22
10961 Berlin
Germany

E-Mail: [hidden email]
Tel.: +49 (30) 201 69 38 0
Fax.: +49 (30) 201 69 38 20
Internet: www.scopis.com

HRB 128315 Berlin Charlottenburg
USt-IdNr.: DE272721463
Steuernummer: 29/014/02034
Geschäftsführer:  Bartosz Kosmecki

Diese E-mail, einschließlich der Anhänge, ist ausschließlich für den oben genannten Adressaten
bestimmt und beinhaltet vertrauliche und/oder gesetzlich geschützte Informationen. Jedem anderen
Empfänger ist die Vervielfältigung, Weitergabe oder Veröffentlichung untersagt. Falls Sie diese
Mitteilung irrtümlicherweise erhalten haben, bitten wir um sofortige Information an den Absender und
Vernichtung der E-mail.

This e-mail, including the attachments, is for the exclusive use of the above-named addresses and
contains confidential information and/or information protected by law. Any other recipient is
prohibited from duplicating, passing on to third parties, or publishing this information. If by
error you are the recipient of this communication please inform the sender immediately and
permanently delete this e-mail.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake