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" <herve.bout...@free.fr>:
> 
>     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: users-unsubscr...@maven.apache.org
>     For additional commands, e-mail: users-h...@maven.apache.org
>     
>     
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to