On May 2, 2020 10:32 AM, Sibi Siddharthan Wrote:
> On Sat, May 2, 2020 at 1:02 AM Johannes Schindelin
> <Johannes.Schindelin@xxxxxx> wrote:
> > On Wed, 29 Apr 2020, Sibi Siddharthan wrote:
> >
> > > Adding the CMake script to contrib/buildsystem is a good option.
> >
> > I'd actually prefer it to live in a different subdirectory: what is in
> > contrib/buildsystem/ uses the technique of running `make` in a dry-run
> > mode, parsing the output, and then generating project files. But that
> > is not what CMakeLists.txt is about.
> >
> > How about contrib/cmake/?
> >
>
> The CMakeLists.txt will be non-functional if it in any other directory except
> the root source directory. To help users we can, add some instructions in
> INSTALL on how to use the script.
> OR
> create a dummy CMakeLists.txt in the root directory which just says
> `message("Copy and Replace the CMakeLists from `whatever-folder` to
> here")` along with some instructions if necessary. This is what LLVM does for
> autoconf.
> > > Is there any changes (apart from the CMakeLists.txt critique and)
> > > that I have to do on my part?
> >
> > No, I think that's it!
> >
> > Thanks,
> > Dscho
> >
> > >
> > > Thank You,
> > > Sibi Siddharthan
> > >
> > > On Wed, Apr 29, 2020 at 2:37 AM Jeff King <peff@xxxxxxxx> wrote:
> > > >
> > > > On Tue, Apr 28, 2020 at 08:52:37PM +0700, Danh Doan wrote:
> > > >
> > > > > On 2020-04-27 16:12:28-0400, Jeff King <peff@xxxxxxxx> wrote:
> > > > > > On Mon, Apr 27, 2020 at 04:08:52PM -0400, Jeff King wrote:
> > > > > >
> > > > > > > Skimming the patches, I do wish I didn't see so much
> > > > > > > repetition with the existing Makefile. I know that some of
> > > > > > > the logic will just have to be ported manually, but surely
> > > > > > > we could be pulling things like the list of libgit_SOURCES from the
> Makefile as the single source of truth?
> > > > > >
> > > > > > Thinking I surely couldn't be the only one to think of this, I
> > > > > > dug further into some of the sub-threads. And indeed, it seems
> > > > > > like you are on the same page here.
> > > > > >
> > > > > > IMHO it is worth making the cmake file depend as much as
> > > > > > possible on what's in the Makefile.
> > > > >
> > > > > Please correct me if I were wrong (I recall this from my memory
> > > > > without checking anything).
> > > > >
> > > > > The worst thing about CMake is we can't override (Make's)
> > > > > variable in Makefile generated by CMake.
> > > >
> > > > I really don't know enough about cmake to say one way or the
> > > > other. I can well believe there are parts of the Makefile that
> > > > will need to be manually translated, and that it may not ever hit full
> parity.
> > > >
> > > > But as long as it just a tool for people using Visual Studio, and
> > > > if they are happier being able to use that tool, even with a few
> > > > deficiencies, then it may still be worth doing.
> > > >
> > > > -Peff
> > >
Just a head's up that neither the HPE NonStop OSS nor IBM z/OS USS platforms currently have any support for CMake nor do I expect any support in the foreseeable future. We are seeing very strong adoption rates on both platforms (sorry, cannot share statistics at this time).
Regards,
Randall
-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
-- In my real life, I talk too much.
