Custom build (e.g. CMake)

544 views
Skip to first unread message

jesper....@gmail.com

unread,
Apr 14, 2014, 3:26:42 PM4/14/14
to mave...@googlegroups.com
Hello,

I'm wondering if it is feasible to use nar-maven-plugin without the internal build engine. Coming from the C++ camp, we have a large code base which is largely CMake-based, and I'm investigating if nar-maven-plugin could be customized to work with that. The primary feature I'm looking for is dependency management, not building the actual C++ code.

Thanks in advance,

/Jesper

Roland Asmann

unread,
Apr 18, 2014, 11:16:43 AM4/18/14
to mave...@googlegroups.com
Hi Jesper,

I was looking into that myself and have found that it is not a big problem. You just have to make sure to get the output-files in the right location for the NAR-plugin to package it all up, but that's about it.
I'll try to make an example POM for you.

Roland

Roland Asmann

unread,
Apr 20, 2014, 11:47:38 AM4/20/14
to mave...@googlegroups.com
As promised, here's an example of both a pom.xml and a CMakeList.txt. I'm still testing it all myself, so the output is hardcoded for amd64-Linux. I hope I didn't remove to much info while deleting non-maven-related stuff!

I am using a SNAPSHOT of the CMake-plugin, because the current version only runs on JDK7 and my projects have to build on JDK6. Patch is already added in CMake-plugin, but unfortunately not released yet!

Roland
pom.xml
CMakeLists.txt

Jesper Eskilson

unread,
May 28, 2014, 2:42:13 PM5/28/14
to mave...@googlegroups.com


Den fredagen den 18:e april 2014 kl. 17:16:43 UTC+2 skrev Roland Asmann:
Hi Jesper,

I was looking into that myself and have found that it is not a big problem. You just have to make sure to get the output-files in the right location for the NAR-plugin to package it all up, but that's about it.
I'll try to make an example POM for you.


Thanks. I would like to avoid having to place such hard requirements on the CMake project about where to put things. We have a pretty large codebase in CMake projects, and it would be nice if it was possible to make the Maven site adapt to the CMake package structure.

However, there is one big thing missing, and that is dependency management. I would like to (with minimal effort on the developer's part) to be able specify dependencies on other Maven modules (using the same conventions or plugins) and have those dependencies automatically injected into the CMake build. On the CMake side, I can use INSTALL(EXPORT ...) to create a .cmake script file which will contain the "public" CMake "API" for a given project (i.e. a set of CMake targets), but for all of this to work, I need CMake to build the artifacts, and the Maven side to simply pick up whatever zip-file or tarball CMake has produced. I have a proof-of-concept pom.xml which does exactly this for a small toy project, but it needs to resort to some semi-black magic using external ruby scripts to get it all together.

Maybe I will write my own plugin for this, or possible extend nar-maven-plugin in some way. It would be nice if this was doable so that the generated Maven projects could use the same packaging type and have compatible binaries.

Roland Asmann

unread,
May 29, 2014, 9:46:36 AM5/29/14
to mave...@googlegroups.com
Hi Jesper,


On Wednesday, May 28, 2014 8:42:13 PM UTC+2, Jesper Eskilson wrote:
 
Thanks. I would like to avoid having to place such hard requirements on the CMake project about where to put things. We have a pretty large codebase in CMake projects, and it would be nice if it was possible to make the Maven site adapt to the CMake package structure.

However, there is one big thing missing, and that is dependency management. I would like to (with minimal effort on the developer's part) to be able specify dependencies on other Maven modules (using the same conventions or plugins) and have those dependencies automatically injected into the CMake build. On the CMake side, I can use INSTALL(EXPORT ...) to create a .cmake script file which will contain the "public" CMake "API" for a given project (i.e. a set of CMake targets), but for all of this to work, I need CMake to build the artifacts, and the Maven side to simply pick up whatever zip-file or tarball CMake has produced. I have a proof-of-concept pom.xml which does exactly this for a small toy project, but it needs to resort to some semi-black magic using external ruby scripts to get it all together.

Maybe I will write my own plugin for this, or possible extend nar-maven-plugin in some way. It would be nice if this was doable so that the generated Maven projects could use the same packaging type and have compatible binaries.

If the only problem you have is the location of the artifact, you could simply add the resources-plugin (execution 'copy') *after* CMake runs, and copy the artifact to the correct location for NAR to pick it up.
Since the person responsible for out CMake-configs is no longer in our company, I have taken it upon myself to edit them to build the final artifact in the location NAR expects it to be. But it shouldn't be too hard to have Maven do that for you.

I guess you will also have 'problems' with adding other NARs into your build-path, however. Here also you could use the resources-plugin to copy all dependencies into one (or more) directories that are referenced by your CMake-builds. We currently have a sort of multi-module structure (remember, I am still playing around with switching to Maven, nothing is done yet!) and all modules drop their binaries in '../lib' and all headers into '../headers'. I know it's ugly, but since those paths are added in the CMake-build, I can currently just reuse those and copy my binaries there. If your team can agree on adding eg 'target/headers' and 'target/binary' or something similar, you could just let NAR retrieve and unpack your dependencies and then add resources-plugin to copy the necessary files into that/those directories.

Or you could indeed try to write your own plugin/edit the NAR-plugin, but currently NAR is doing everything 'the Maven way'. I don't think it would be a good idea to change the plugin to fit your specific case, it's always best to adhere to standards... But writing a new plugin or copying stuff around for your project to work, is definitely a lesser evil. :-)

Hope this helps!

Roland

Jesper Eskilson

unread,
May 29, 2014, 10:10:36 AM5/29/14
to mave...@googlegroups.com
Ok, thanks. This work is still "off-the-radar", I hope to be able to allocate some real time to this. But I probably first need to convince my colleagues that Maven can provide some real benefits. :)

Curtis Rueden

unread,
May 29, 2014, 10:59:31 AM5/29/14
to Jesper Eskilson, NAR Maven plugin
Hi Jesper,

> I hope to be able to allocate some real time to this.

I think your goal to fuse NAR with CMake is laudible. What CMake (and C/C++ in general) painfully lacks is any sort of decent dependency management, and Maven+NAR is poised to provide that. So if you do find time to work on this, it would be very exciting.

> But I probably first need to convince my colleagues that Maven can provide
> some real benefits. :)

Right. There is a chicken-and-egg problem in that NAR certainly needs some TLC to fully achieve its potential with respect to native dependency management. E.g.: AOL is not always sufficient to identify link-time compatibility between binary code -- you might also need e.g. the C++ shared runtime version [1]. And more immediately, you'll likely stumble across some bugs in NAR as well.

But for long-term maintenance and usability of a project with a complex native dependency hierarchy, I think the effort of persevering would be worth it. Right now, building any complex cross-platform C++ project using CMake pretty much requires you to build the entire dependency stack from source yourself, which from my Java-centric perspective is just gruesome. It is huge detriment to productivity as well as community code contributions. Somehow leaning on Maven to achieve at least an "80%" solution would be fantastic.



--
You received this message because you are subscribed to the Google Groups "NAR Maven plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maven-nar+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages