21. mai 2015 kl. 09:58 skrev Joakim Hove <[email protected]>: > Hello; > > thank you for your input. > > What, specifically, do you mean by "remove sibling build feature"? > > With that I mean that when searching for opm libraries and header files the > build system will not use heuristics to look in src/ and build/ folders. So > when looking for opm-core the build system will look in ${OPM_ROOT}/lib and > ${OPM_ROOT}/include, alternatively default directories like /usr. > > > My main concerns are that: > - it must not be too hard to make a "developer's install" (although it can be > harder than a "user's install") > > I don’t really understand what you mean with “developer’s install”; do you > mean the process of setting up your development environment such that you can > easily update and build the different modules, and get a final working > (developer) executable based on all the checked out code? As for difficulty – > see my comments below.
Yes that is exactly what I mean. > > - that install must contain only a single working directory for any module > (that then can be used to build all configs desired) > > Yes - absolutely > > - our current install docs (while outdated in the face of opm-cmake) assume a > sibling build > > Yes – I will update that in the face of opm-cmake, and maybe further. > > Also: what is the purpose of removing this? What are the user errors we are > trying to prevent? How significant is the simplification of the build system > that will result? I know we discussed this at the OPM meeting a few months > ago, but I'd like to know the motivation behind this a little better. > > My experience is that the effective find rules of the build system are quite > opaque; I have had numerous experiences where I thought I was including & > linking a module in location /path/to/xxx – but in the end it turned that the > build system had found a build/ & src/ combination elsewhere. I guess the > challenges with the sibling build system are mostly when installing – not in > a pure developer mode. Now – the fact that I am little challenged is maybe no > reason to change the system, but in addition the current find rules are so > complex that I consider the current system very difficult to maintain – it > does work though; so why mess with it? I may be a bit behind on this, but is there special treatment of directories called 'src' and 'build'? If so, I can see how that can lead to some confusion (I do not use that, > > > > OK: I fully realize that the sibling build is very convenient for the > developers. The alternative that I have in my head is based on the cmake > feature LIBRARY_OUTPUT_PATH: (untested loose idea): > > 1. Check out the source modules the way you want. > 2. When configuring pass the options > –DBUILD_OUTPUT=/path/to/build/output -DOPM_ROOT=/path/to/build/output (could > even sane “sibling-like” defaults here) I assume that you build in /path/to/build/opm-core-build etc.? > 3. Make a build target which copies the header files from the source > directory to /path/to/build/output/include > > That way no extra install is required, and the downstream modules will locate > the opm dependencies using the same search logic irrespective of whether we > are searching for an installed version of e.g. opm-core, or the build output > from a previous build. That seems quite reasonable, but do I have to 'make install' to see changes in downstream modules? That would be one extra step (and therefore prone to being forgotten from time to time). Or is your point precisely that I do not need to do that? Atgeirr _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
