On 2020-04-25 20:27:37+0530, Sibi Siddharthan <sibisiddharthan.github@xxxxxxxxx> wrote: > Hi Dscho, > > I guess this is a pain point having to manage two separate build systems. > I will modify CMake script to get its sources from the Makefile. > > > > I understand what you are trying to say, this is not impossible to do but doing > > > so will make the CMake script dependent on the Makefile for the sources. > > > I am not fan of this approach. > > > > > > We should write a separate script (say python) to match each of the sources in > > > the Makefile and the CMake file automatically whenever the changes detected. > > > This excludes the platform specific/compatibility stuff in config.mak.uname. > > > > Hmm. That is an approach that _I_ don't like. Why duplicate the > > information when you don't have to? > > > > I don't see any issue with keeping CMakeLists.txt dependent on Makefile. > > We could of course extract the lists into a separate file that is sourced > > both from the Makefile and from CMakeLists.txt, but that would actually > > not reflect that the Makefile _is_ authoritative. CMakeLists.txt will > > never be the authoritative source. (This email is hard to be replied, because Sibi do top-posting. And, I want to quote both on this). I'm still not a fan of CMake despite that I need to write it at previous $DAYJOBS. I would like to keep Makefile as authoritative source of information, and to convince other developers, we need to keep Makefile as authoritative source of information. Let's say this way, I dislike it, but if it works for you, that's fine, just don't add more burden for existing people. Remember that with CMake support, we will never able to use CMake generated build in-tree because we have an existing Makefile in-tree (not a problem since it's expected to be built out-of-tree if CMake is used), but please don't complain if it people accidentally break it. ./configure doesn't work correctly with `--without-<pkg>` and people seems to not interest in my series to respect it, for example. When writing this, I intended to write something to support out-of-tree build with current Makefile. Hopefully, it won't be rocket science. Last but not least, (this point was discussed with Sibi off-list) about our test infrastructure, when we add a new test, we can simply run: make test Makefile will pick it up, and run all tests just fine. CMake's glob only works at CMake configuration time. If there's a new test after CMake was run, and nothing changed in CMakeList.txt. The list generated by CMake will still be the same, ctest wouldn't know that there's a new test. People need to manually run cmake again to pick it up (or as Sibi told me off-list, that developer is question can run by hand path/to/git/source/t/t-9999-true.sh That's not a problem for the person write that test, but it'll be problem for other people, who will fetch the new source to their own repo, and naively run msbuild and ctest. It's analogue to this habit in git (me in my previous $DAYJOBS) yes | git add -p Anyway, get back to the solution (should this series be accepted), I think it'll work if we can split: SOURCE_FILES += cmake.c into a source-list.mak Then, cmake will do some magic with `configure_file` or something similar, IIRC, it's a reduced functionallity of sed. -- Danh
