[bug] 2.5.0 build with NO_PERL is broken

[bug] 2.5.0 build with NO_PERL is broken

[Renato Botelho]

I was working on update git on FreeBSD ports tree to 2.5.0 and I noted 2.5.0
is trying to use perl even when it's being built with NO_PERL knob.

/bin/sh: /usr/bin/perl: not found
Makefile:1701: recipe for target 'common-cmds.h' failed
gmake[2]: *** [common-cmds.h] Error 127
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: Leaving directory '/freebsd/ports/head/devel/git/work/git-2.5.0'

After a quick search, looks like commit 527ec3980b is the culprit since it
removed generate-cmdlist.sh and introduced generate-cmdlist.perl.

I just would like to check if it's planned to add perl dependency during
build time or it happened by accident and will be fixed so NO_PERL can work
again.

Thanks

Re: [bug] 2.5.0 build with NO_PERL is broken

[Renato Botelho]

Renato Botelho <garga <at> FreeBSD.org> writes:

> 
> I was working on update git on FreeBSD ports tree to 2.5.0 and I noted 2.5.0
> is trying to use perl even when it's being built with NO_PERL knob.
> 
> /bin/sh: /usr/bin/perl: not found
> Makefile:1701: recipe for target 'common-cmds.h' failed
> gmake[2]: *** [common-cmds.h] Error 127
> gmake[2]: *** Waiting for unfinished jobs....
> gmake[2]: Leaving directory '/freebsd/ports/head/devel/git/work/git-2.5.0'
> 
> After a quick search, looks like commit 527ec3980b is the culprit since it
> removed generate-cmdlist.sh and introduced generate-cmdlist.perl.
> 
> I just would like to check if it's planned to add perl dependency during
> build time or it happened by accident and will be fixed so NO_PERL can work
> again.

I also found that some commands require perl when NO_PERL is set:

git-submodule
git-request-pull
git-am

Definitely NO_PERL is not working as expected.

Re: [bug] 2.5.0 build with NO_PERL is broken

[Junio C Hamano]

Renato Botelho <garga@FreeBSD.org> writes:

> I also found that some commands require perl when NO_PERL is set:
>
> git-submodule
> git-request-pull
> git-am
>
> Definitely NO_PERL is not working as expected.

NO_PERL merely means "I want to build a subset of Git that is meant
to be usable on a system without a working Perl installed".  These
scripts that do require Perl installed are indeed not expected to
work under NO_PERL (if you think about it, that would be natural and
the only sensible expectation---otherwise we would have coded them
without using Perl at all, in which case there will be no need for
NO_PERL in the first place).

Re: [bug] 2.5.0 build with NO_PERL is broken

[Eric Sunshine]

On Fri, Aug 14, 2015 at 3:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Renato Botelho <garga@FreeBSD.org> writes:
>> I also found that some commands require perl when NO_PERL is set:
>
> NO_PERL merely means "I want to build a subset of Git that is meant
> to be usable on a system without a working Perl installed".  These
> scripts that do require Perl installed are indeed not expected to
> work under NO_PERL (if you think about it, that would be natural and
> the only sensible expectation---otherwise we would have coded them
> without using Perl at all, in which case there will be no need for
> NO_PERL in the first place).

Nevertheless, there's still the problem, due to 527ec39
(generate-cmdlist: parse common group commands, 2015-05-21), that git
doesn't build at all anymore when Perl is unavailable.

One option would be to go with the awk version of
'generate-cmdlist'[1], which restricts itself to POSIX and was tested
on Linux, FreeBSD, and Mac OS X[2], though I'm not sure we really want
to go there, particularly if you're uncomfortable[3] about introducing
awk into the toolchain.

Another option would be to rewrite the (more complex) generate-cmdlist
in shell, which I think should be possible, though it will be uglier
and more verbose.

[1]: http://article.gmane.org/gmane.comp.version-control.git/269307/
[2]: http://article.gmane.org/gmane.comp.version-control.git/269336/
[3]: http://article.gmane.org/gmane.comp.version-control.git/269324/

Re: [bug] 2.5.0 build with NO_PERL is broken

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

> Nevertheless, there's still the problem, due to 527ec39
> (generate-cmdlist: parse common group commands, 2015-05-21), that git
> doesn't build at all anymore when Perl is unavailable.

I do not think that is anything new.  We always have assumed "some"
version of Perl available in order to run t/ scripts.

Re: [bug] 2.5.0 build with NO_PERL is broken

[Eric Sunshine]

On Fri, Aug 14, 2015 at 5:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>> Nevertheless, there's still the problem, due to 527ec39
>> (generate-cmdlist: parse common group commands, 2015-05-21), that git
>> doesn't build at all anymore when Perl is unavailable.
>
> I do not think that is anything new.  We always have assumed "some"
> version of Perl available in order to run t/ scripts.

True, but prior to 527ec39, without Perl available, git itself could
at least be built and used (with some commands unavailable), even if
it couldn't be fully tested. As of 527ec39, however, git won't even
build because common-cmds.h can't be generated.

Re: [bug] 2.5.0 build with NO_PERL is broken

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Fri, Aug 14, 2015 at 5:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>> Nevertheless, there's still the problem, due to 527ec39
>>> (generate-cmdlist: parse common group commands, 2015-05-21), that git
>>> doesn't build at all anymore when Perl is unavailable.
>>
>> I do not think that is anything new.  We always have assumed "some"
>> version of Perl available in order to run t/ scripts.
>
> True, but prior to 527ec39, without Perl available, git itself could
> at least be built and used (with some commands unavailable), even if
> it couldn't be fully tested. As of 527ec39, however, git won't even
> build because common-cmds.h can't be generated.

I wouldn't bother digging in the history myself, but I am reasonably
sure that the current genereate-common-cmds is not the sole instance
that we relied on Perl to build (not test) in the past, and that is
another reason why I do not think this is anything new.

Re: [bug] 2.5.0 build with NO_PERL is broken

[Eric Sunshine]

On Fri, Aug 14, 2015 at 6:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> On Fri, Aug 14, 2015 at 5:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>>> Nevertheless, there's still the problem, due to 527ec39
>>>> (generate-cmdlist: parse common group commands, 2015-05-21), that git
>>>> doesn't build at all anymore when Perl is unavailable.
>>>
>>> I do not think that is anything new.  We always have assumed "some"
>>> version of Perl available in order to run t/ scripts.
>>
>> True, but prior to 527ec39, without Perl available, git itself could
>> at least be built and used (with some commands unavailable), even if
>> it couldn't be fully tested. As of 527ec39, however, git won't even
>> build because common-cmds.h can't be generated.
>
> I wouldn't bother digging in the history myself, but I am reasonably
> sure that the current genereate-common-cmds is not the sole instance
> that we relied on Perl to build (not test) in the past, and that is
> another reason why I do not think this is anything new.

Hmm. In my tests by setting PERL_PATH to a bogus (non-existent)
command, prior to 527ec39, git builds successfully, whereas, following
527ec39, it does not build. But, perhaps I overlooked something...(?)

Re: [bug] 2.5.0 build with NO_PERL is broken

[Renato Botelho]

Eric Sunshine <sunshine <at> sunshineco.com> writes:

> 
> On Fri, Aug 14, 2015 at 6:22 PM, Junio C Hamano <gitster <at> pobox.com>
wrote:
> > Eric Sunshine <sunshine <at> sunshineco.com> writes:
> >
> >> On Fri, Aug 14, 2015 at 5:02 PM, Junio C Hamano <gitster <at>
pobox.com> wrote:
> >>> Eric Sunshine <sunshine <at> sunshineco.com> writes:
> >>>
> >>> I do not think that is anything new.  We always have assumed "some"
> >>> version of Perl available in order to run t/ scripts.
> >>
> >> True, but prior to 527ec39, without Perl available, git itself could
> >> at least be built and used (with some commands unavailable), even if
> >> it couldn't be fully tested. As of 527ec39, however, git won't even
> >> build because common-cmds.h can't be generated.
> >
> > I wouldn't bother digging in the history myself, but I am reasonably
> > sure that the current genereate-common-cmds is not the sole instance
> > that we relied on Perl to build (not test) in the past, and that is
> > another reason why I do not think this is anything new.
> 
> Hmm. In my tests by setting PERL_PATH to a bogus (non-existent)
> command, prior to 527ec39, git builds successfully, whereas, following
> 527ec39, it does not build. But, perhaps I overlooked something...(?)

It builds but there will be at least 3 commands that won't work:

git-submodule
git-request-pull
git-am

I'm considering to add perl dependency as mandatory on FreeBSD ports tree,
and maybe this NO_PERL option doesn't make more sense nowadays...

Re: [bug] 2.5.0 build with NO_PERL is broken

[Eric Sunshine]

On Tue, Aug 18, 2015 at 7:05 AM, Renato Botelho <garga@freebsd.org> wrote:
> Eric Sunshine <sunshine <at> sunshineco.com> writes:
>> On Fri, Aug 14, 2015 at 6:22 PM, Junio C Hamano <gitster <at> pobox.com>
> wrote:
>> > Eric Sunshine <sunshine <at> sunshineco.com> writes:
>> >> On Fri, Aug 14, 2015 at 5:02 PM, Junio C Hamano <gitster <at>
> pobox.com> wrote:
>> >>> Eric Sunshine <sunshine <at> sunshineco.com> writes:
>> >>> I do not think that is anything new.  We always have assumed "some"
>> >>> version of Perl available in order to run t/ scripts.
>> >>
>> >> True, but prior to 527ec39, without Perl available, git itself could
>> >> at least be built and used (with some commands unavailable), even if
>> >> it couldn't be fully tested. As of 527ec39, however, git won't even
>> >> build because common-cmds.h can't be generated.
>> >
>> > I wouldn't bother digging in the history myself, but I am reasonably
>> > sure that the current genereate-common-cmds is not the sole instance
>> > that we relied on Perl to build (not test) in the past, and that is
>> > another reason why I do not think this is anything new.
>>
>> Hmm. In my tests by setting PERL_PATH to a bogus (non-existent)
>> command, prior to 527ec39, git builds successfully, whereas, following
>> 527ec39, it does not build. But, perhaps I overlooked something...(?)
>
> It builds but there will be at least 3 commands that won't work:

Hmm, I was under the impression from your initial mail[1] that Git
wouldn't even build without Perl available:

    /bin/sh: /usr/bin/perl: not found
    Makefile:1701: recipe for target 'common-cmds.h' failed
    gmake[2]: *** [common-cmds.h] Error 127

Doesn't this failure prevent generation of the 'git' executable altogether?

> git-submodule
> git-request-pull
> git-am

Also...

git-add--interactive
git-archimport
git-cvsexportcommit
git-cvsimport
git-cvsserver
git-difftool
git-instaweb
git-relink
git-send-email
git-svn

A C rewrite of git-am has recently graduated to 'master'.

> I'm considering to add perl dependency as mandatory on FreeBSD ports tree,
> and maybe this NO_PERL option doesn't make more sense nowadays...

That might make sense. Although some of the above commands may not be
used widely, others, such as git-send-email, probably are used
regularly.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/275905

Re: [bug] 2.5.0 build with NO_PERL is broken

[Renato Botelho]

> Eric Sunshine <sunshine <at> sunshineco.com> writes:
> 
> Hmm, I was under the impression from your initial mail[1] that Git
> wouldn't even build without Perl available:
> 
>     /bin/sh: /usr/bin/perl: not found
>     Makefile:1701: recipe for target 'common-cmds.h' failed
>     gmake[2]: *** [common-cmds.h] Error 127

This assumption is correct, current 2.5.0 doesn't build without perl.

> Doesn't this failure prevent generation of the 'git' executable altogether?
> 
> > git-submodule
> > git-request-pull
> > git-am
> 
> Also...
> 
> git-add--interactive
> git-archimport
> git-cvsexportcommit
> git-cvsimport
> git-cvsserver
> git-difftool
> git-instaweb
> git-relink
> git-send-email
> git-svn

When I build with NO_PERL=1, above files are a simple shell script saying
git was built without it:

#!/bin/sh

echo >&2 "fatal: git was built without support for `basename $0` (NO_PERL=1)."
exit 128

But the same doesn't happen with submodule, request-pull and am.

> A C rewrite of git-am has recently graduated to 'master'.

cool!

> That might make sense. Although some of the above commands may not be
> used widely, others, such as git-send-email, probably are used
> regularly.

There is a port called git-lite with few dependencies, sometimes people
install it on servers that only need to clone and update local copies of
repos. It's interesting to keep it working as expected with NO_PERL, since
it offers this option.