Yes I think I mentioned earlier that I have it hosted at
https://github.com/isaachier/git. I have been busy with a few things
so have not continued much since I started this conversation, but it
covers a large part of the Makefile if not all the significant
portions.
On Tue, Feb 20, 2018 at 11:28
On Thu, Jan 25, 2018 at 6:21 PM, Isaac Hier wrote:
> Hi Jeff,
>
> I have been looking at the build generator, which looks promising, but
> I have one concern. Assuming I can generate a CMakeLists.txt that
> appropriately updates the library sources, etc. how do you suggest I
> handle new portabili
On 1/25/2018 7:21 PM, Isaac Hier wrote:
Hi Jeff,
I have been looking at the build generator, which looks promising, but
I have one concern. Assuming I can generate a CMakeLists.txt that
appropriately updates the library sources, etc. how do you suggest I
handle new portability macros? For exam
Hi Jeff,
I have been looking at the build generator, which looks promising, but
I have one concern. Assuming I can generate a CMakeLists.txt that
appropriately updates the library sources, etc. how do you suggest I
handle new portability macros? For example, assume someone adds a
macro HAVE_X to i
Stephan, I totally agree about the advanced options. At first, I left
them as visible options seeing as the Makefile does not comment which
are advanced and which are basic.
In terms of the up-to-dateness, I find it easier to "fast-forward" all
the changes at once without tangling myself in a load
On 01/24/2018 10:19 PM, Isaac Hier wrote:
> Thanks for your interest! This patch is based on the cmake-build
> branch of https://github.com/isaachier/git, but the full history is on
> the cmake branch (squashed it for easier readability). Hope that
> helps.
Thanks. I use the cmake branch because I
Thanks for your interest! This patch is based on the cmake-build
branch of https://github.com/isaachier/git, but the full history is on
the cmake branch (squashed it for easier readability). Hope that
helps.
On Wed, Jan 24, 2018 at 4:15 PM, Stephan Beyer wrote:
> Hi Isaac,
>
> On 01/24/2018 02:45
CMake is very portable (see
https://open.cdash.org/index.php?project=CMake for details). About the
whole autoconf history in Git, I came across this post by Linus while
researching if anyone had done something with CMake in the git project
before:
> NO! At least the Makefile is debuggable and unde
Hi Isaac,
On 01/24/2018 02:45 PM, Isaac Hier wrote:
> I realize this is a huge patch, but does anyone have feedback for the
> general idea?
Thank you very much. I am *personally* interested in this due to several
reasons (which are mostly that I am used to CMake and when I do
something on the Git
On 1/24/2018 2:59 PM, Isaac Hier wrote:
Jeff, no worries, fair enough. I know https://github.com/grpc/grpc
uses a shared file to generate code for several build systems instead
of maintaining them individually. I plan on doing the work anyway just
because I have my own reasons to use CMake in G
On Wed, Jan 24 2018, Junio C. Hamano jotted:
> Isaac Hier writes:
>
>> I realize this is a huge patch, but does anyone have feedback for the
>> general idea?
>
> I personally am not interested, especially with the justification
> given in the cover letter.
>
> Perhaps the one in this patch may b
Jeff, no worries, fair enough. I know https://github.com/grpc/grpc
uses a shared file to generate code for several build systems instead
of maintaining them individually. I plan on doing the work anyway just
because I have my own reasons to use CMake in Git (for packaging in
https://github.com/rusl
On 1/22/2018 7:16 PM, Isaac Hier wrote:
This patch adds a mostly complete (aside from building tests, documentation,
installation, etc.) CMake build to the git project. I am not sure how much
interest there is in a CMake build, so please send me feedback one way or
another. Personally, I believ
Isaac Hier writes:
> I realize this is a huge patch, but does anyone have feedback for the
> general idea?
I personally am not interested, especially with the justification
given in the cover letter.
Perhaps the one in this patch may be "mostly complete", and I am
sure you can make it "complete
On Wed, Jan 24, 2018 at 5:45 AM, Isaac Hier wrote:
> I realize this is a huge patch, but does anyone have feedback for the
> general idea?
>
I don't know anything about CMake so I can't comment on the patch
itself. Having additional build systems does not bother me, but it
does mean that someone
I realize this is a huge patch, but does anyone have feedback for the
general idea?
On Mon, Jan 22, 2018 at 7:16 PM, Isaac Hier wrote:
> This patch adds a mostly complete (aside from building tests, documentation,
> installation, etc.) CMake build to the git project. I am not sure how much
> inte
This patch adds a mostly complete (aside from building tests, documentation,
installation, etc.) CMake build to the git project. I am not sure how much
interest there is in a CMake build, so please send me feedback one way or
another. Personally, I believe CMake will help with Windows builds and is
17 matches
Mail list logo