First of all, I also want to thank Joakim for bringing up the discussion before making changes. My thoughts are as follows:
> Currently my focus is on removing the sibling-build features. 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. My personal views is that I use it and find it convenient. However, if there is a sentiment for removing it, I will just resort to using -DCMAKE_INSTALL_PREFIX instead. Hence, I favour keeping it, but will bend if the sentiment is towards removing it. 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. If everything is related to removing sibling builds, then I guess we first need to address that part (possibly mooting the rest?) Cheers, Alf ________________________________ From: Opm [[email protected]] on behalf of Joakim Hove [[email protected]] Sent: Thursday, May 21, 2015 12:17 AM To: [email protected] Subject: [OPM] Installation sub directories Hello; after merging the opm-cmake Pull Requests I am now in the process of trying to simplify the build system in opm-cmake. Currently my focus is on removing the sibling-build features. Much of the build system is permeated by the assumption that the different modules are in ${module} subdirectory, i.e. if we invoke cmake as: cmake –DOPM_ROOT=/path/opm The build system will search for headers and libraries of opm-core in: header-search : /path/opm/opm-core/include/{…} library-search : /path/opm/opm-core/lib64/{…} Whereas when the opm modules are installed with ‘make install’ they will go to: header-install : ${CMAKE_INSTALL_PREFIX}/include/{…} library-install : ${CMAKE_INSTALL_PREFIX}/lib64/{…} I.e. the module subdirectory is absent. My suggestion plan is that: 1. The implicit ${module} subdirectory is removed from the eventual search path – if you invoke cmake with –DOPM_ROOT= cmake will search for headers and libraries in ${OPM_ROOT}/include and ${OPM_ROOT}/lib64 respectively. 2. If you want to employ a different version of one the modules you can invoke cmake as: cmake –DOPM_ROOT=/default/root -DDUNE_CORNERPOINT_ROOT=/special/dune-cornerpoint The use of module subdirectories is not strictly bound to sibling builds; but they certainly simplify sibling-build search semantics. Dune also seems to have these directories. Any opinions on this? Are there some fundamental issues with the use of module subdirectories which I have overlooked? Joakim RDI project with IT elements -> Contact R&D Toolbox<https://statoil.service-now.com/selfservice/catalog_item_detail.do?sysparm_document_key=sc_cat_item,78bfbbce6fb455001f6446916e3ee453> ------------------------------------------------------------------- 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 [email protected] http://www.opm-project.org/mailman/listinfo/opm
