The C++ shared runtime version, how to identify within the NAR

[GregDomjan]

I think there was a proposal on the sonatype issues for adding a version to the AOL. I think it was proposed as adding the OS version. But rather I think it should have been the c++ shared lib version.
ie. When you use shared lib <linkCPP> which defaults to true
msvc of msvcrt(80/90/100/110) or
g++ of glibc(1.5, 1.6).

Suggesting some thoughts on a resolution

• The linker name could be extended to include a version, or perhaps there could be included as a classifier.
  Gives generally the same result and this leaves it for NAR to manage and can vary for each AOL.
• It could be added as semantic version information, different OL would change co-ords. Don't like this as a solution as it makes a mess of cross OS.
• Could continue with the information not being visible from pom/narinfo, but include subfolders or naming conventions to include the version. (boost adds the vc runtime version the filenames on a default bjam build as an example).

This issue doesn't stop current binary distributions from supporting a latest compiler - in the case of boost they have a farm of test builds for different AOL even if they don't distribute them.

Whatever OS modules NAR might provide as examples/pre compilations to central would have that issue for almost all C++ shared run time.

[dscho]

@GregDomjan any hints how we could go about designing this support in a backwards-compatible manner?

[GregDomjan]

Have not thought of anything great yet, have been busy elsewhere.

Seems mainly an issue with shared std lib, I'm not sure if it is also an issue with static, and mostly it seems to depend on the memory model and related std:: class changes at API boundaries as to whether it makes a difference.
Ideally an app can depend on just one c/c++ runtime, but it could have multiple?

On thought was along the line of making the C++ shared runtime a dependency similar to other dependencies, then the maven tooling can show possible incompatabilities in the dependency tree.

Adding that meta would need then to have different artifacts for different linker/stdlib versions.

So far with WixToolset NAR package I have have found that

• multiple sub folders doesn't work well with the current NarInfo, nar-maven needs work to be able to address multiple
• adding the stdlib/linker version to the artifact id puts the information to early, for cross OS artifacts the artifacts would be split instead of as one dependency.

[dscho]

To add some information why I might appear so pushy: we have 17 open issues and I do not see any of them going anywhere. I'd rather have a small set of tickets that have a good chance of getting resolved eventually than more than a handful of tickets only a tiny subset (that might be lost between the others) has a chance of getting resolved at all.

[dscho]

@GregDomjan can I close this, seeing as there is no progress and unlikely to be from both you and me, because we're both so overworked?

[levalleux-ludo]

Hello,
I really need such a possibility to identity different versions of my components regarding the linker version (gcc446 vs gcc441 for instance, or msvc10 vs msvc13) and further also taking into account different build configuration (single vs multi-tread, debug vs release, etc).
From my expertise, the nar-plugin is able to generate with any compiler toolchain in any kind of build configuration, using profiles in POM, for instance (generation in multiple executions).
But it lacks a way to distinguish delivered attached artifacts from the others (AOL is too restrictive), and another way to manage the dependancies to choose the relevant one regarding the kind of production (in an abstract way for the user, when you build a msvc10-mt-debug, you would have to or prefer to link with the msvc10-mt-debug of your dependencies).
What the nar-plugin does for AOL is very good in terms of level of abstraction.
I just need something similar but extended to a larger choice of "targets".
I would be able to propose a technical solution soon, I will submit it to the community for feedback and, ideally, for integration in the main project.
But please keep this discussion open so that we can share our thoughts and progress on this point.

[dscho]

@levalleux-ludo I will keep this discussion open as long as it looks like there might be some progress some day... (I actually planned to close this issue early in August for that reason, but forgot)

I am not really familiar with that part of the code, but I could imagine that a NarLayout30.java might be required to handle this extension in a backwards-compatible manner.

How would you feel about taking a crack at this project?

[dscho]

@GregDomjan @levalleux-ludo Please let me lay it down clearly: the NAR project relies on contributions by volunteers, just like myself. Without doubt, the NAR plugin is already a pretty complex piece of software, and the issue we are talking about is trickier still to get right. Therefore I would fully understand if you do not want to tackle this project, but it would be good form to state that clearly, too, so we can move on. So: are you interested in pushing this ticket forward?

[ctrueden]

Let's discuss on the maven-nar list.

[levalleux-ludo]

Hello @dscho
Sorry, I missed your question in your last message.
I am still interested to contribute in the nar-maven-plugin project, because I used it in my company and I would prefer to integrate our specific modifications in the official trunk.
I am not familiar with the contribution process, so it requires time and a few effort to me but I have seen there exist some "how to" to help me.
But, regarding my professional constraints I miss time (probably like most of people) !
For now, I can at least report where I am:

• I merged recently the 3.2.0 official code in my version. Congratulations for this release because it looks to be more mature, improved and a few defects have been corrected.
• In parallel, and I mocked up a solution to deal with "extended" targets (= aol) to take into account the compiler version (VC100 vs VC130, or GCC446 vs GCC481, etc.) and also a build variant (debug, release, multi-threading, etc). The main stuff can be done at POM level directly, with build profiles. Only a few corrections/improvement have been necessary in the plugin code, in several classes, but without challenging the current design.
  Before pushing the solution as is, I would be glad to explain the way I have followed.
  How can I do that ? Is there a kind of technical memo I could write and submit ?

[dscho]

I am still interested to contribute in the nar-maven-plugin project,

Great! I hate seeing a ticket go nowhere (so much time lost all around), and I love seeing a ticket go forward.

In parallel, and I mocked up a solution to deal with "extended" targets (= aol) to take into account the compiler version (VC100 vs VC130, or GCC446 vs GCC481, etc.) and also a build variant (debug, release, multi-threading, etc). The main stuff can be done at POM level directly, with build profiles.

That definitely sounds intriguing!

Only a few corrections/improvement have been necessary in the plugin code, in several classes, but without challenging the current design.

Even better!

Before pushing the solution as is, I would be glad to explain the way I have followed. How can I do that ? Is there a kind of technical memo I could write and submit ?

The way I would tackle this is by pushing this branch, even in a non-final state, then open a Pull Request, clearly indicating in the title with a DONT-MERGE-YET that this is intended to be developed together. I am a big, big proponent of working together. Then, write the things you have in mind into the initial comment. Subsequently, the topic branch can be rewritten and polished, the technical aspects can be clarified, and every interested developer can help improve the design and the code.

[ctrueden]

@levalleux-ludo Still interested in contributing your improvements? It's never too late! 😉