Hi for the dependencies I guess (but not sure) this is just a very fast C/C++ parser which is independent of the actual compiler, so it could be at the base.
for the binary dependencies and the different compilers, it is not so much the compilers and options that change name, in fact they have not for quite some time. It is their output which relies on 2 things: - some system libraries and their API/ABI (e.g. libc, WIN32.dll) - the compiler runtime API/ABI (libstdc++, MSVC70.DLL, fortran libs etc.) So even if we take out the knowledge from cpptasks the central question if one can do binary dependencies with native languages as maven uses it with Java is still there. Regards Mark Donszelmann -----Original Message----- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 3:23 PM To: Maven Users List Subject: Re: Native dependencies See my inline comment On 6/14/05, Donszelmann, Mark <[EMAIL PROTECTED]> wrote: > 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. > Love this feature. It is possible to build this at the base.? Then build more compiler specific plugins on top of this. > 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... > This is my point about cpptask trying to do to much. It is very difficult to maintain cpptask to keep up with constant changes from all new/supported OSes/compilers > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
