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 > >
