Complexity in the build system is certainly worth addressing.
That said, I don't understand what the ramifications of this change will be so I'll ask some questions to help assess the situation. This will be from the point of view of a developer. Suppose that I'm using and making changes to the Git master sources of two or more OPM project modules (e.g., opm-parser, opm-core, and opm-autodiff). Am I supposed to "git clone" the source trees as subdirectories of my OPM_ROOT or are the sources supposed to be placed somewhere else? Will there be restrictions on where I put my build trees (e.g., must these be subdirectories of the corresponding source trees)? Can I have multiple build trees for a single module? Do I have to run "make install" in an upstream module (e.g., opm-core) to have any changes visible to downstream modules (e.g., opm-autodiff)? In short, what is the use-case you're developing for the OPM build system? Are you moving towards a work-flow in which "make install" is the only inter-module communication device for build products (i.e., headers, libraries and/or executables)? In the current system supporting sibling builds I can put all source trees (git clones) in a single top-level directory, mirror that structure in an entirely separate build tree (not subdirectory of the source trees) and have the build system automatically pick up the correct paths for headers (subdirectories of the source trees) and libraries (subdirectories of the build trees). This feature is *very* convenient for build testing. Bård ________________________________ From: Opm [opm-boun...@opm-project.org] on behalf of Joakim Hove [jo...@statoil.com] Sent: 21 May 2015 13:12 To: 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
_______________________________________________ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
