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. Thank You, Sibi Siddharthan On Sat, Apr 25, 2020 at 8:19 PM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi Sibi, > > On Sat, 25 Apr 2020, Sibi Siddharthan wrote: > > > On Sat, Apr 25, 2020 at 7:58 PM Johannes Schindelin > > <Johannes.Schindelin@xxxxxx> wrote: > > > > > > On Sat, 25 Apr 2020, Sibi Siddharthan wrote: > > > > > > > On Sat, Apr 25, 2020 at 6:59 PM Johannes Schindelin > > > > <Johannes.Schindelin@xxxxxx> wrote: > > > > > > > > > > > > > > We already use `GIT-VERSION-GEN` as the authoritative source for the Git > > > > > version, by parsing the line that contains. > > > > > > > > > > It would look very similar, at least in my mind, to generate the list of > > > > > source/script files by parsing the `Makefile`. > > > > > > > > > > Sibi, what do you think? > > > > > > > > One way of doing it is to track if the Makefile is changed in a commit, > > > > run a hook to see if it contains any new OBJs and match it with the > > > > CMake script. But this is too much work, in my opinion. > > > > > > Oh, sorry, I should have clarified: We already parse the > > > `DEF_VER=v2.26.GIT` line in `GIT-VERSION-GEN` to determine the Git > > > version. > > > > > > We should be able to do the very exact same thing to parse the `SCRIPT_SH` > > > lines like > > > > > > SCRIPT_SH += git-bisect.sh > > > > > > in the `Makefile` to accumulate the list of shell scripts, and likewise > > > the list of object files could be accumulated by parsing the `LIB_OBJS` > > > lines like > > > > > > LIB_OBJS += abspath.o > > > > > > (We would of course need to substitute the `.o` with `.c`, but that should > > > be easy.) > > > > > > That way, nobody will ever need to touch the CMakeLists.txt file when they > > > add a new source file to libgit.a. > > > > > > > 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. > > Ciao, > Dscho > > > > > > I was not trying to auto-detect what `sed` invocation changed. Those > > > changes _will_ need manual forward-porting to CMakeLists.txt. Thankfully, > > > those events are really rare. > > > > > > Makes sense? > > > > > > Ciao, > > > Dscho > > > > Thank You, > > Sibi Siddharthan > > > >
