You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Rodrigo Ruiz <rr...@gridsystems.com> on 2007/04/13 14:52:30 UTC
[M2] Native plugin and multi-platform C++ projects How-To
Hi all,
I am trying to migrate a C++ project to Maven2, but I have troubles to
find out the right way to go.
The current project uses a Makefile for several Unix systems (custom, no
automake used), and separate Visual Studio project files for Windows.
The artifact to generate is a shared library.
AFAICS, I have several options for the general project layout:
- Use the antrun plugin to build the project using the already existent
Makefile and VS project files. Surely, this is the fastest to implement
and the best for a quick prototype, but I would prefer to keep a single
build system. Right now, I see it more like a patch than a final solution.
- Use the native plugin and, making extensive use of profiles, manage to
get a single project that can be built in any platform. I am not sure
that it would be feasible to make the packaging and classifier of the
produced artifact reflect the library extension and the target
OS/platform in the file name.
- Using again the native plugin, create a multi-module project. The
parent would contain the C++ source code, while each child module would
be devoted to create a single OS/platform specific artifact.
Which one do you think is the best? Is there any other way to do this?
By the way, can native be used for C#, VB, Delphi, etc.?
There are more issues related to the same migration, but I think it is
better to go step by step ;-)
Please, any comment or advice would be very welcome!
Cheers,
--
-------------------------------------------------------------------
GRID SYSTEMS, S.A. Rodrigo Ruiz
Parc Bit - Edificio 17 Research Coordinator
07121 Palma de Mallorca
Baleares - Spain
http://www.gridsystems.com/
-------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Frederic Simon <fr...@gmail.com>.
Hi,
I worked a lot on creating a plugin that is merging the goodies from the
native plugin and the freehep nar plugin.
It's in production on a big project for linux build, but never had the time
to test it for windows.
For Linux (and may be others, since it's based on native plugin) I have the
following features:
- Creation of an artifact with classifier "include" and extension jar or zip
( XXX-include.zip ) that contains all *.h files that will be
resolved/unziped and added as -IXXX when another library is dependant on it.
- Creation of separate option list for debug and test compilation and
linking.
- Integration of tests phases (compile-tests, tests) with cppunit (or other
by configuration).
- Unification of names for libraries (no need to have artifactId starts with
libXXX)
- Addition of a native assembler enabling preparation for RPM based on
depedency tree.
- One folder in LD_LIBRARY_PATH with soft links to the local repository
libraries files (so, a, ...)
- Up-to-date mechanism for linking avoiding relinking if object files did
not changed
- Multithreaded compilation to run parallel calls to gcc or others
If you are interrested, the code of my last tag is here:
https://jade-plugins.svn.sourceforge.net/svnroot/jade-plugins/tags/1.3.7/
and it uses:
https://mvn-anno-mojo.svn.sourceforge.net/svnroot/mvn-anno-mojo/tags/1.2.4/
It is also on public maven repository:
<repository>
<id>jfrog-plugins</id>
<name>jfrog-plugins-dist</name>
<url>http://www.jfrog.org/artifactory/plugins-releases</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
For usage you can start from:
https://jade-plugins.svn.sourceforge.net/svnroot/jade-plugins/tags/1.3.7/plugins/build/jade-native-plugin/src/it/depend/linux-x86/pom.xml
I'm working on the doc now, so sorry but I don't have much (You will need to
browse the code for understanding configuration).
Hope it helps,
On 4/15/07, Eric Redmond <er...@gmail.com> wrote:
>
> On 4/14/07, Mark Donszelmann <Ma...@slac.stanford.edu> wrote:
> >
> > Hi
> >
> > agreed AOL is a classifier. The question is not if it is or not. The
> > question is
> > what the range of this classifier should be to handle ALL the areas
> > of native
> > code, and what their compatibility range should be.
> >
>
> I see. This is an interesting problem, since classifiers only add one
> extra
> dimension of distinction to an artifact. This problem can arise in JAR
> artifacts too - deploying a JAR for a "test" environment running
> "windows",
> for example. The only way I know to deal with this is by amalgamating
> information into a single classifier key, such as "wintest", as opposed to
> "macosdev".
>
> Eric
>
> Regards
> > Mark
> >
> > On Apr 14, 2007, at 11:15 AM, Eric Redmond wrote:
> >
> > > On 4/14/07, Mark Donszelmann <Ma...@slac.stanford.edu>
> > > wrote:
> > >>
> > >> Hi
> > >>
> > >> On Apr 13, 2007, at 2:00 PM, Christian Goetze wrote:
> > >>
> > >> > On 4/13/07, Mark Donszelmann <Ma...@slac.stanford.edu>
> > >> > wrote:
> > >> >> Hi Christian,
> > >> >
> > >> >> you may have a look at
> > >> >> http://java.freehep.org/freehep-nar-plugin
> > >> >> it does quite a bit of what you suggest, though it is not perfect.
> > >> >
> > >> > That is pretty neat - but the devil is in the details :)
> > >>
> > >> agreed. Our organization standardizes on a few combinations of
> > >> architectures
> > >> and OSs, but even then...
> > >>
> > >> > For example,
> > >> > you'd want various variants of the same artifact (debug, optimized,
> > >> > profiled, quantified, instrumented in other ways) ... Not sure
> > >> "AOL"
> > >> > cuts it.
> > >>
> > >> yes. Do you (or others) have any suggestions on how one could attack
> > >> this problem?
> > >
> > >
> > > This is traditionally hat "classifiers" are for. Is AOL a
> > > classifier of NAR
> > > artifacts? If not, then there you go.
> > >
> > > Eric
> > >
> > > Regards
> > >> Mark Donszelmann
> > >>
> > >>
> > >> > --
> > >> > cg
> > >> >
> > >> >
> > >> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >> > For additional commands, e-mail: users-help@maven.apache.org
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Eric Redmond
> > > http://codehaus.org/~eredmond
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> Eric Redmond
> http://codehaus.org/~eredmond
>
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Eric Redmond <er...@gmail.com>.
On 4/14/07, Mark Donszelmann <Ma...@slac.stanford.edu> wrote:
>
> Hi
>
> agreed AOL is a classifier. The question is not if it is or not. The
> question is
> what the range of this classifier should be to handle ALL the areas
> of native
> code, and what their compatibility range should be.
>
I see. This is an interesting problem, since classifiers only add one extra
dimension of distinction to an artifact. This problem can arise in JAR
artifacts too - deploying a JAR for a "test" environment running "windows",
for example. The only way I know to deal with this is by amalgamating
information into a single classifier key, such as "wintest", as opposed to
"macosdev".
Eric
Regards
> Mark
>
> On Apr 14, 2007, at 11:15 AM, Eric Redmond wrote:
>
> > On 4/14/07, Mark Donszelmann <Ma...@slac.stanford.edu>
> > wrote:
> >>
> >> Hi
> >>
> >> On Apr 13, 2007, at 2:00 PM, Christian Goetze wrote:
> >>
> >> > On 4/13/07, Mark Donszelmann <Ma...@slac.stanford.edu>
> >> > wrote:
> >> >> Hi Christian,
> >> >
> >> >> you may have a look at
> >> >> http://java.freehep.org/freehep-nar-plugin
> >> >> it does quite a bit of what you suggest, though it is not perfect.
> >> >
> >> > That is pretty neat - but the devil is in the details :)
> >>
> >> agreed. Our organization standardizes on a few combinations of
> >> architectures
> >> and OSs, but even then...
> >>
> >> > For example,
> >> > you'd want various variants of the same artifact (debug, optimized,
> >> > profiled, quantified, instrumented in other ways) ... Not sure
> >> "AOL"
> >> > cuts it.
> >>
> >> yes. Do you (or others) have any suggestions on how one could attack
> >> this problem?
> >
> >
> > This is traditionally hat "classifiers" are for. Is AOL a
> > classifier of NAR
> > artifacts? If not, then there you go.
> >
> > Eric
> >
> > Regards
> >> Mark Donszelmann
> >>
> >>
> >> > --
> >> > cg
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: users-help@maven.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Eric Redmond
> > http://codehaus.org/~eredmond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Mark Donszelmann <Ma...@slac.stanford.edu>.
Hi
agreed AOL is a classifier. The question is not if it is or not. The
question is
what the range of this classifier should be to handle ALL the areas
of native
code, and what their compatibility range should be.
Regards
Mark
On Apr 14, 2007, at 11:15 AM, Eric Redmond wrote:
> On 4/14/07, Mark Donszelmann <Ma...@slac.stanford.edu>
> wrote:
>>
>> Hi
>>
>> On Apr 13, 2007, at 2:00 PM, Christian Goetze wrote:
>>
>> > On 4/13/07, Mark Donszelmann <Ma...@slac.stanford.edu>
>> > wrote:
>> >> Hi Christian,
>> >
>> >> you may have a look at
>> >> http://java.freehep.org/freehep-nar-plugin
>> >> it does quite a bit of what you suggest, though it is not perfect.
>> >
>> > That is pretty neat - but the devil is in the details :)
>>
>> agreed. Our organization standardizes on a few combinations of
>> architectures
>> and OSs, but even then...
>>
>> > For example,
>> > you'd want various variants of the same artifact (debug, optimized,
>> > profiled, quantified, instrumented in other ways) ... Not sure
>> "AOL"
>> > cuts it.
>>
>> yes. Do you (or others) have any suggestions on how one could attack
>> this problem?
>
>
> This is traditionally hat "classifiers" are for. Is AOL a
> classifier of NAR
> artifacts? If not, then there you go.
>
> Eric
>
> Regards
>> Mark Donszelmann
>>
>>
>> > --
>> > cg
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> Eric Redmond
> http://codehaus.org/~eredmond
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Eric Redmond <er...@gmail.com>.
On 4/14/07, Mark Donszelmann <Ma...@slac.stanford.edu> wrote:
>
> Hi
>
> On Apr 13, 2007, at 2:00 PM, Christian Goetze wrote:
>
> > On 4/13/07, Mark Donszelmann <Ma...@slac.stanford.edu>
> > wrote:
> >> Hi Christian,
> >
> >> you may have a look at
> >> http://java.freehep.org/freehep-nar-plugin
> >> it does quite a bit of what you suggest, though it is not perfect.
> >
> > That is pretty neat - but the devil is in the details :)
>
> agreed. Our organization standardizes on a few combinations of
> architectures
> and OSs, but even then...
>
> > For example,
> > you'd want various variants of the same artifact (debug, optimized,
> > profiled, quantified, instrumented in other ways) ... Not sure "AOL"
> > cuts it.
>
> yes. Do you (or others) have any suggestions on how one could attack
> this problem?
This is traditionally hat "classifiers" are for. Is AOL a classifier of NAR
artifacts? If not, then there you go.
Eric
Regards
> Mark Donszelmann
>
>
> > --
> > cg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Mark Donszelmann <Ma...@slac.stanford.edu>.
Hi
On Apr 13, 2007, at 2:00 PM, Christian Goetze wrote:
> On 4/13/07, Mark Donszelmann <Ma...@slac.stanford.edu>
> wrote:
>> Hi Christian,
>
>> you may have a look at
>> http://java.freehep.org/freehep-nar-plugin
>> it does quite a bit of what you suggest, though it is not perfect.
>
> That is pretty neat - but the devil is in the details :)
agreed. Our organization standardizes on a few combinations of
architectures
and OSs, but even then...
> For example,
> you'd want various variants of the same artifact (debug, optimized,
> profiled, quantified, instrumented in other ways) ... Not sure "AOL"
> cuts it.
yes. Do you (or others) have any suggestions on how one could attack
this problem?
Regards
Mark Donszelmann
> --
> cg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Christian Goetze <cg...@gmail.com>.
On 4/13/07, Mark Donszelmann <Ma...@slac.stanford.edu> wrote:
> Hi Christian,
> you may have a look at
> http://java.freehep.org/freehep-nar-plugin
> it does quite a bit of what you suggest, though it is not perfect.
That is pretty neat - but the devil is in the details :) For example,
you'd want various variants of the same artifact (debug, optimized,
profiled, quantified, instrumented in other ways) ... Not sure "AOL"
cuts it.
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Mark Donszelmann <Ma...@slac.stanford.edu>.
Hi Christian,
you may have a look at
http://java.freehep.org/freehep-nar-plugin
it does quite a bit of what you suggest, though it is not perfect.
Regards
Mark Donszelmann
On Apr 13, 2007, at 11:48 AM, Christian Goetze wrote:
>> > - Using again the native plugin, create a multi-module project. The
>> > parent would contain the C++ source code, while each child
>> module would
>> > be devoted to create a single OS/platform specific artifact.
>
>> I use this option. However you still need to use profile to do
>> debug/release
>> type artifacts
>
> I'm not so sure this is going to be as simple as that. C/C++ artifacts
> are not nearly as nice and tidy as java artifacts. A java artifact is
> essentially a single file, the .jar file. A C/C++ artifact will be at
> minimum two files: the library and the header file(s). In addition to
> that, you will likely need to know the exact compilation options used
> to compile the code and to link the shared object, so you can match
> these in your actual project build. The compilation will need to know
> about your local repository location and set multiple classpath type
> parameters to point to the right headers and libraries. It would be a
> great thing to have, but having spent a significant amount of time
> developing C/C++ build systems, I can guarantee some interesting
> challenges. I don't think that maven is quite up to it yet, but it is
> certainly an interesting approach to build avoidance.
> --
> cg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Christian Goetze <cg...@gmail.com>.
> > - Using again the native plugin, create a multi-module project. The
> > parent would contain the C++ source code, while each child module would
> > be devoted to create a single OS/platform specific artifact.
> I use this option. However you still need to use profile to do debug/release
> type artifacts
I'm not so sure this is going to be as simple as that. C/C++ artifacts
are not nearly as nice and tidy as java artifacts. A java artifact is
essentially a single file, the .jar file. A C/C++ artifact will be at
minimum two files: the library and the header file(s). In addition to
that, you will likely need to know the exact compilation options used
to compile the code and to link the shared object, so you can match
these in your actual project build. The compilation will need to know
about your local repository location and set multiple classpath type
parameters to point to the right headers and libraries. It would be a
great thing to have, but having spent a significant amount of time
developing C/C++ build systems, I can guarantee some interesting
challenges. I don't think that maven is quite up to it yet, but it is
certainly an interesting approach to build avoidance.
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [M2] Native plugin and multi-platform C++ projects How-To
Posted by Dan Tran <da...@gmail.com>.
On 4/13/07, Rodrigo Ruiz <rr...@gridsystems.com> wrote:
>
> Hi all,
>
> I am trying to migrate a C++ project to Maven2, but I have troubles to
> find out the right way to go.
>
> The current project uses a Makefile for several Unix systems (custom, no
> automake used), and separate Visual Studio project files for Windows.
> The artifact to generate is a shared library.
>
> AFAICS, I have several options for the general project layout:
>
> - Use the antrun plugin to build the project using the already existent
> Makefile and VS project files. Surely, this is the fastest to implement
> and the best for a quick prototype, but I would prefer to keep a single
> build system. Right now, I see it more like a patch than a final solution.
>
> - Use the native plugin and, making extensive use of profiles, manage to
> get a single project that can be built in any platform. I am not sure
> that it would be feasible to make the packaging and classifier of the
> produced artifact reflect the library extension and the target
> OS/platform in the file name.
>
> - Using again the native plugin, create a multi-module project. The
> parent would contain the C++ source code, while each child module would
> be devoted to create a single OS/platform specific artifact.
I use this option. However you still need to use profile to do debug/release
type artifacts
Which one do you think is the best? Is there any other way to do this?
> By the way, can native be used for C#, VB, Delphi, etc.?
no, for .net check out maven for net under apache incubator
There are more issues related to the same migration, but I think it is
> better to go step by step ;-)
>
> Please, any comment or advice would be very welcome!
>
> Cheers,
>
> --
> -------------------------------------------------------------------
> GRID SYSTEMS, S.A. Rodrigo Ruiz
> Parc Bit - Edificio 17 Research Coordinator
> 07121 Palma de Mallorca
> Baleares - Spain
> http://www.gridsystems.com/
> -------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>