let's try to dig into your requirements instead of trying to explain generic mechanisms, can you provide some concrete C++ examples, please?
Regards, Hervé Le lundi 7 janvier 2019, 14:23:48 CET Christofer Dutz a écrit : > Hi Hervé, > > thanks for that info ... I adjusted the topic to distinguish from the other > topic :) > Well I first ran into problems when taking over the maintenance of the > Flexmojos maven plugin, which allowed building Flex applications with > maven. A while ago a "bug" was fixed, which that plugin relied on > (non-standard scopes were treated as compile when it came to transitive > dependencies - I think). In flex there were different types of linking > (Think of it as "static linking" (scope "compile" and "test") and "dynamic > linking" (scope "rsl") (RSL = Runtime Shared Library)). > Now with C/C++ we have a similar problem. > > What I would like to be able to do, would be that if I am using a plugin to > provide the means to build a custom type of module, that there would be an > additional extension point in the plugin.xml where we could provide an > additional scope resolver (or whatever we call the thing). So If I'm for > example providing something that's going to be a "cpp-library" then I could > for example use scopes like "dynamicly-linked" or "staticly-linked" and the > thing would tell maven how to transitively resolve these libraries. Ideally > this would sort of be a stack, so if a scope isn't recognized, it defaults > to the next level. > As this has been a problem I have been running into again and again but > always with different problems, I would really like to have this solved or > help with solving it (I'm not expecting you folks to do that for me) > Chris > > > PS: I'm currently using the cmake maven plugin abstracting even more from > the actual build > > Am 05.01.19, 08:31 schrieb "Hervé BOUTEMY" <[email protected]>: > > Hi Christofer, > > I know C/C++ people who used nar-maven-plugin [1] with success: did you > have a look? > > Notice: in Maven, "polyglot" term has always been used for other POM > format than XML. > Here, it's more on Maven support for non-java languages > > One key requirement in such multi-languages context will be to have > common understanding and vocabulary on the requirements of the alternate > languages, sharing concrete examples to make sure both java and non-java > people see the same case. > That was my key finding when I worked a little bit to help these C/C++ > people discover the plugin and find their way. But I never got too much > in details on how finely they managed dependencies: I know there were both > static and dynamic libraries, and multi-platform support, then 2 key topics > for C/C++ than Java does not require > > Regards, > > Hervé > > [1] http://maven-nar.github.io/ > > Le vendredi 4 janvier 2019, 11:08:47 CET Christofer Dutz a écrit : > > > Hi all, > > > > after leaving the Flex project I sort of lost the need for supporting > > alternate dependency strategies. Now in PLC4X we’re currently starting > > to > > work on the C and C++ versions of our PLC drivers. > > This brings the old > > > problem up again that not all programming languages have the same > > super-simple dependency types as Java has them. > > I remember us discussing options to provide extensions for maven, that > > for > > example the type of a pom would not only pull in a dedicated > > lifecycle > > mapping, but also provide an alternate dependency resolution > > mechanism. > > > > > In the C/C++ world we unfortunately have things like static and > > dynamic > > linking etc. I would really like to not start with hacks as I always > > did > > them in Flex and Flexmojos (which is now no longer possible anyway). > > > > > Chris > > > > > > > --------------------------------------------------------------------- > 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]
