+1 for the Maven Hybrid solution (CoC, Ease of use [something I miss when I work with other languages], solving occurring problems)
Sebastian > Am 27.05.2019 um 14:41 schrieb Christofer Dutz <christofer.d...@c-ware.de>: > > Hi all, > > as the discussion had come up multiple times now … mainly on Slack, I would > like to do a dedicated discussion here on the list about the topic. > > Up to now we had built the build to generally build every module with maven, > utilizing plugins to enable triggering builds with things like CMake. > The maven build then took care of packing the results and handling the > dependencies (At least this was how I built things for the C++ module) > With the plc4net however we’re using an execution of “dotnet” to build a > solution. > In this case the build is entirely handled by dotnet and all maven does is > trigger the build and fail if the execution fails with any non 0 return code. > We are currently doing something similar with python: where we’re just > calling python to execute the setup.py script. > > What is your opinion on how we should do our builds? > If we go down the path like I initially setup C++, we have the benefit of > utilizing the maven ecosystem and we will not have any problems during > releases. > It however comes with some comfort disadvantages for the “native” guys. But > things like code-generation will work nicely. > > If we go down a non-maven path we will have to deal with all of this > ourselves … we will have to come up with a way to handle everything ourselves > Or learn how to do it in python and CMake and dotnet, and … The other thing > is that we can’t integrate the driver generation as easy as with maven. > Either we manually execute the code generation multiple times with maven to > generate multiple output directories before executing the individual build > system > Or we have to build custom generators for every build-system we are using. > > Even if I like the way I setup the C++ build, I doubt all people will like it > as it requires them to do things differently than they are used to. > But I would strongly object implementing multiple code-generators. > > One option would be to split up the plc4x git repo into multiple repos – each > one for one language … so we’d have a plc4j, plc4cpp, plc4net and plc4python. > Each of these would be dedicated to one particular language and have build > tools that fit them. However I strongly object this option, as it would > require the > Release manager to understand and setup each of these environments. > > Another option which I think would be a valid compromise, would be to have > all languages in one repo the way we currently have it and Maven as > triggering build system. > The code is generated by maven but the build itself is handled by the > particular build system. > This will require people working exclusively in VisualStudio or some Python > IDE, to manually run a “mvn generate-sources” first, but I think that’s a > reasonable restriction. > > The benefit is that releasing this should be possible with our current > release process which has a limited setup cost for the Release Manager. > > I would opt for the hybrid option with Maven as initiating build system for > releases and code generation and CI stuff but to have the native build system > for every language to build the individual parts. > Namely this would be: > > * Plc4cpp: CMake > * Plc4net: dotnet > * Plc4Python: python setup.py > > Not quite sure how we can get the test-results to be reported correctly. > > What are your thoughts on this? > > Chris > >
