There are a few good things (I think) about cpptasks. One of them is that it
streamlines all the compiler options as far as it can. Things such as
debug, optimize, include, output library, etc. Other options can still be given 
separately. 

The other thing cpptasks is quite good at (and a lot faster than Make) is 
include file dependency checking. On one of our projects it does 1500 files
in 30 seconds on my machine (which is not the latest). The same checking via
make takes quite a lot longer.

However, the point of a Native plugin for Maven (1 or 2) is not so much the
underlying technology (cpptasks or something else), but rather if one can 
handle binary dependencies properly. I guess one needs info on the architecture,
OS and compiler/linker (which is what we did in our NAR plugin), but to make it
complete we need to look at things such as the ABI (Application Binary 
Interface)
both for the system libraries and for the compiler runtime libraries.

It is here where I am not truly convinced that one can make things work across
platforms:

1. WIN32 seems to have the least problems. Things look pretty backward 
compatible.
2. MacOS X, the g++ compiler changed from 2.x, 3.1, 3.3 and now 4.0 but at least
is stable for a particular version of the OS. The g++ compiler output may not
be very backward compatible. (any thoughts here)
3. Linux, the g++ compiler changes rather independently from the OS version. 
Again g++ may suffer from backward compatibility problems.
4. Others...

In all, if one standardizes on a few platform/os/compiler combinations you can 
set up a maven repository and use binary dependencies, but it may be hard to
get it completely right.

Java of course does not suffer from all this, except that the ABI (at least the
runtime lib) does change from 1.2, 1.3, 1.4 and now 1.5. Is there anything
in M2 that allows me to publish the same library (with the same name) 
for both java 1.4 and java 1.5.

(we have such a case where we first wrote some mathematical lib in jdk 1.5
with templates, and later backported it to 1.4).

Regards
Mark Donszelmann


 

-----Original Message-----
From: dan tran [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 14, 2005 1:21 AM
To: Maven Users List
Subject: Re: Native dependencies

I may be wrong, but i think the reason of cpptasks is not maintainable because 
it tries to know too much.  If I am going to convert it to M2 mojo, i will just 
try to make it to replace 'make' functionality and leave the compiler and 
linker settings to the user.

After that, we may have ton of independent add-ins (MOJO) for compiler 
specifics.

thoughts?

-D

On 6/14/05, Donszelmann, Mark <[EMAIL PROTECTED]> wrote:
> Dan (and others),
> 
> a port to M2, whenever we migrate to it. This all depends on how 
> stable and goo M2 is. Have not investigated yet. The current NAR 
> plugin could do with some improvements. The jelly script is around 50 
> Kbytes, and could be more easily written in Java. There are a lot of 
> properties used, of which I have no idea where they go in M2.
> 
> I did make my own improvements to cpptasks, and reported some of them:
> new compilers, some options changed, etc. The cpptasks system is 
> usable and quite ok I think, just not maintained (very well).
> 
> Let me know.
> 
> Mark
> 
> -----Original Message-----
> From: dan tran [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 14, 2005 12:05 AM
> To: Maven Users List
> Subject: Re: Native dependencies
> 
> Mark, Do you plan to port your plugin to M2?
> 
> I think cpp-task is basically dead, I ended up to maintain cpptask 
> with my own changes to support more option.  Perhaps we can team up to 
> merge cpptask into M2 mojo
> 
> -D
> 
> On 6/13/05, Donszelmann, Mark <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > we found the maven-native-plugin limited in its functionality, 
> > especially where it concerns:
> >
> > 1. true cross-platform development
> > 2. declaring dependencies on other native libraries
> >
> > so, we developed our own. Feel free to have a look, and use it:
> >
> > http://java.freehep.org/freehep-nar-plugin
> >
> > builds, unpacks and distributes Native Archives.
> >
> > Its not complete, see the issues in JIRA, but we are getting there.
> >
> > Regards
> > Mark Donszelmann
> >
> >
> > -----Original Message-----
> > From: dan tran [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 13, 2005 2:07 PM
> > To: Maven Users List
> > Subject: Re: Native dependencies
> >
> > In case you are going to build native code, take a look at 
> > maven-native-plugin
> >
> > -D
> >
> > On 6/13/05, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> > > Will give it a try.  I am targeting Windows and *nix.
> > >
> > > Am new to Maven, so will have to go figure out the pregoal stuff 
> > > (ironically, I was just looking into that for something else!)
> > >
> > > >>> [EMAIL PROTECTED] 6/13/2005 3:44:55 PM >>>
> > > - put the native files under your local repo
> > > - add them to your dependencies list
> > >
> > > At run time system use pregoal to add the native files to a 
> > > localtion understand by your system, ORuse some sort of 
> > > environment valiable to add your file to linkage path
> > >
> > > What OS are you targeting?
> > >
> > > -D
> > >
> > >
> > >
> > > On 6/13/05, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> > > > I have a 3rd party JAR that requires a native library.  How do I 
> > > > specify the dependency such that the native library gets put in 
> > > > a
> > > place
> > > > where I can link with it at runtime?
> > > >
> > > >
> > > > Thanks,
> > > > Grant Ingersoll
> > > >
> > > >
> > > ------------------------------------------------------------------
> > > --
> > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to