On Sun, Apr 26, 2020 at 6:11 AM Danh Doan <congdanhqx@xxxxxxxxx> wrote: > > 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. > To prevent the CMake script from overwriting the current Makefile, I can add a check at the beginning to stop the configure if the build is done in source. > 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. > Me and Dscho discussed that we will use the Makefile for getting the source list. So we will basically parse the Makefile for the requires sourced to be used( in CMake itself). So devs can just maintain the Makefile alone. This approach works for SCRIPT_SH SCRIPT_LIB SCRIPT_PERL SCRIPT_PYTHON TEST_BUILTINS_OBJS LIB_OBJS BUILTIN_OBJS XDIFF_OBJS VCSSVN_OBJS PROGRAM_OBJS do not work, as a few of them link with curl and expat. As git-bugreport was added recently to the next branch. This should not be major issue I guess. > -- > Danh Thank You, Sibi Siddharthan
