Not everyone wants/allows the jvm on their boxes. A small footprint c/c++ implementation can be important.
On December 21, 2018 at 08:03:14, Julian Feinauer ( [email protected]) wrote: Hi all, just a note fromm y side. I was driving around today and thought about what we are currently doing... writing the SAME THING in different languages only because there is no nice "native" interface between the languages. And I really don’t like that. Don't get me wrong... I'm very happy that we have another language in the project now and I think we should follow this path but I also think we have to find a better way. Otherwise we will loose with regards to features for the different languages, bugfixes, ... . I mean, basically it should be possible (with some pain) to get a C++ driver working in java and all the high level stuff has to stay there as it is very Java specific (like OPM). But, I see a problem in supporting drivers that are only written in C++ (my Java is sooo much better than my C++). Are there no real options to turn it around (java to native code) or something. I think we should not depend on too many libs in the drivers alone and all we need could be supplied and linked from the C++ drivers (like network communication and so...). Am I the only one feeling a real pain by our approach? Julian PS.: Really don't get me wrong. I'm totally pro support for MANY languages. But I'm totally against code forks in every language as this is a real maintenance HELL Am 21.12.18, 13:56 schrieb "Christofer Dutz" <[email protected]>: Hi all, well I have spent the last two days in trying to get the build and the build of the "boost" dependency working. Ich has proven to be "chanllenging". After giving up with trying to fix C++ problems in IntelliJ I tried out CLion (IntelliJ for C and C++) Internally they rely on CMake for building (https://cmake.org/) so I had a look at this: "CMake is an open-source, cross-platform family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of your choice." That sounds promising. Also there seems to be Maven support: https://github.com/cmake-maven-project/cmake-maven-project I think this could be a better option than using the native-maven-plugin which seems to have not been updated for a looooooong time. I'll experiment a little more on this ... Chris Am 20.12.18, 15:32 schrieb "Christofer Dutz" <[email protected]>: Hi all, I just pushed an initial commit of the C++ API Markus sent me. Thanks a lot for that :-) It took a little time to setup the plugins to build with maven … however I haven’t been able to fully run the compilation as I managed to fix most things, but am having some error I simply don’t understand in the Exception classes. In order to enable the C++ stuff, just comment in the “api” module in the plc4cpp modules pom.xml Looking forward to some discussions on this. Please treat both the build integration as well as the API itself as a basis for discussion. From the build side, It’s just one option that generally seems to work. If there are better options, I’d be happy to hear/see them. Chris
