I don't have all the details, but on static vs dynamic libs, static libs are classical dependencies from a Maven point of view, ie. downloaded from the repository and added to something like a classpath, where dynamic libs are classically managed by the distribution's package manager: I don't know how this is dealt with during the build, where updating the machine with a Linux package is not really an option
I'll try to get in touch with the guy I know who did work on that Regards, Hervé Le lundi 14 janvier 2019, 15:03:55 CET Christofer Dutz a écrit : > Hi Herve, > > well I know for example that I have some libraries, that are statically > linked and some expect libraries to be installed on the host system. I had > the exact same problem with Flex in the past ... here I could also have > dynamically linked versions of libraries, then I had to also reference all > the dynamically linked dependencies of that too. Usually always some > dependencies were intentionally statically linked and some intentionally > dynamically linked. It all boils down how to interpret the transitive > dependencies of a dependency depending on its linkage type. > So I guess this would be a quite generic requirement. One I seem to > encounter multiple times with different languages. > In my current example of PLC4X with C++, I simply statically link > everything. > Chris > > > > Am 08.01.19, 02:59 schrieb "Hervé BOUTEMY" <[email protected]>: > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
