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" <
[hidden email]>:
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" <
[hidden email]>:
>
> 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:
[hidden email]
> For additional commands, e-mail:
[hidden email]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
[hidden email]
> For additional commands, e-mail:
[hidden email]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[hidden email]
For additional commands, e-mail:
[hidden email]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[hidden email]
For additional commands, e-mail:
[hidden email]
Locked
