For the record, all opm Jenkins building and deployment was maintained by yours truly for quite some time, so I am genuinely interested in hearing about issues.
Cheers, Alf 21. mai 2015 15:54 skrev Joakim Hove <jo...@statoil.com> følgende: > In Statoil the sibling builds have led to quite a lot of wasted developer > time when tracking down link and build problems when building and deploying > on Jenkins. Actually, I have not seen issues related to sibling support. Can you share more about the issues are you thinking of? Well – that might be because I have fixed them? We have had several issues with build system locating siblings of upstream modules instead of the installed modules. > the system is very complex to maintain. It has worked well; so the need for > updates has been very limited – but when/if updates are required it is > challenging. Over the years I have more or less given up, and concluded that build systems are beasts. I am not even sure designing for everybody to easily maintain is a good target. Some opinions from Roland, Markus and/or Arne Morten here is maybe helpful. Well - as long as we do not have a dedicated “build master” (and I am not volunteering) – I see it as an essential goal that all the core developers can maintain the system. But I fully agree that opinions from current master builders would be valuable. ________________________________ From: Opm [opm-boun...@opm-project.org] on behalf of Joakim Hove [jo...@statoil.com] Sent: Thursday, May 21, 2015 1:12 PM To: opm@opm-project.org<mailto:opm@opm-project.org> Subject: Re: [OPM] Installation sub directories This was discussed at the OPM meeting, and my recollection from the discussion on sibling builds is -a majority of developers use the feature -it does not add significant complexity when determining which libraries/binaries are actually linked -it is not a significant maintenance burden to keep With the conclusion that we keep it. Well – my recollection of the discussion is not that support for the sibling build was that unanimous. In my opinion the system with sibling builds is very friendly to the pure developer; but I disagree with this: it does not add significant complexity when determining which libraries/binaries are actually linked In Statoil the sibling builds have led to quite a lot of wasted developer time when tracking down link and build problems when building and deploying on Jenkins. Furtheremore this: -it is not a significant maintenance burden to keep Is just flat out wrong; the system is very complex to maintain. It has worked well; so the need for updates has been very limited – but when/if updates are required it is challenging. As for the rest of the points, I am struggling to understand exactly what is suggested. Like it is presented I have to take a deep dive in the build system to be able to make informed opinions. Well – you are right that the initial question I posed was actually just a simplification step on the way to a possible removal of the sibling builds; but the question of sibling builds or not has got all the attention – I guess that is the most important question; so fair enough. I will continue with and make a PR based on the LIBRARY_OUTPUT_PATH setting – then we can continue the discussion from there. Jaokim ------------------------------------------------------------------- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you ------------------------------------------------------------------- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you ------------------------------------------------------------------- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you
_______________________________________________ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
