On Wednesday 15 January 2014, Alexander Neundorf wrote: > On Wednesday 15 January 2014, Matthew Woehlke wrote: > > On 2014-01-14 18:00, Alexander Neundorf wrote: > > > On Tuesday 14 January 2014, Matthew Woehlke wrote: > > >> While that sounds good for 99.9% of cases, what about the case of > > >> project A that includes project B, where B is not updated, but A > > >> decides to start using project(...VERSION...). Now if B was using > > >> PROJECT_VERSION internally, it is broken. (Note that I'm implying that > > >> B is e.g. a separate repository that may not be "as easy to > > >> update/fix as A".) > > > > > > You mean > > > CMakeLists.txt: > > > > > > project(Foo VERSION 1.2.3) > > > > > > .... > > > > > > add_subdir(B) > > > > > > B/CMakeLists.txt: > > > > > > set(PROJECT_VERSION "4.5.6") > > > project(Bar) > > > > > > > > > Indeed. > > > In that case, PROJECT_VERSION will be unset afterwards. > > > > Exactly. I wanted to point it out, but as that's probably unusual, I > > would be okay ignoring that case. > > > > > If it would be > > > > > > B/CMakeLists.txt: > > > > > > > > > project(Bar) > > > set(PROJECT_VERSION "4.5.6") > > > > > > everything is fine. > > > > ...until B/C/CMakeLists.txt also calls project() :-). Basically, you > > (can) get into trouble if you "update" your project to use > > project(VERSION) and also have an "external" sub-project that tries to > > use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about > > this use case (having an embedded "external" project), I suspect it's > > not actually very common², and anyway there is only a problem when the > > sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in > > general, and more so the intersection of the two). > > > > Again, given the above, I've no objection to breaking that case, which > > may well only exist in the hypothetical sense with no 'in the wild' > > instances actually existing. > > And, to actually produce the breakage, at some place the VERSION argument > must have been added. > With the current state of my branch, this could be worked around by > unsetting the guard variable: > > > project(Foo VERSION 1.2.3) > .... > > unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND) > add_subdir(B) > > This way B would be protected from that change in behaviour.
I could also add more logic, to try to detect if PROJECT_VERSION has been set manually, e.g. project() could reset PROJECT_VERSION only if it has the same value as ${${ParentProjectName}_VERSION}. Then it would only break if there was a manual set(PROJECT_VERSION ...) before a project() call without VERSION, and if that manually set version was the same as the version in the "parent project". Or, maybe, project() without VERSION should simply NOT clear PROJECT_VERSION. Then it may be a somewhat inconsistent or not ideal behaviour, but OTOH there is zero chance for breaking an existing build by adding a VERSION somewhere. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers