Ticket #1852 (closed bug: fixed)

Opened 4 years ago

Last modified 4 years ago

Configure.pl errors in 2.10.0

Reported by: doughera Owned by: dukeleto
Priority: normal Milestone: 2.10
Component: configure Version: 2.10.0
Severity: high Keywords:
Cc: Language:
Patch status: Platform: all

Description

Working from the parrot-2.10.0.tar release, Configure.pl complains

During configuration the following steps failed:
    54:  auto::sha1
    55:  auto::git_describe
You should diagnose and fix these errors before calling 'make'

and the resulting lib/Parrot/Config/Generated.pm file does not contain keys for either sha1 or git_describe.

The exact texts of the error messages generated by Configure.pl differ depending on whether or not the user has git installed, but are wrong in either case. For a release, there is no need to run git at all.

If git *is* installed, Configure.pl exits with an error status. If git is *not* installed, Configure.pl exists with a success status, but still prints the warning messages.

Change History

follow-up: ↓ 2   Changed 4 years ago by coke

Andy-

If you're building this based on an export of the git tag, the git tag
moved. You might need to get the updated tag via "git fetch --tags".

in reply to: ↑ 1   Changed 4 years ago by doughera

Replying to coke:

If you're building this based on an export of the git tag, the git tag moved. You might need to get the updated tag via "git fetch --tags".

Nope, I was working from the posted tarball, obtained from  ftp://ftp.parrot.org/pub/parrot/releases/devel/2.10.0/parrot-2.10.0.tar.bz2

  Changed 4 years ago by coke

I can duplicate the error when using the tarball.

follow-up: ↓ 5   Changed 4 years ago by mikehh

I ran my normal testing procedure on the tarball and everything went ok up to fulltest.

However, although the message is generated it does not prevent the build and it continues fine, so in effect it is a spurious message that comes because the configure steps are checking for information in .parrot_current_git_describe and .parrot_current_sha1 both of which contain a single newline (0x0a) on my system, rather than the git describe or sha1 strings.

In effect we need to check that we are building from the tarball and not a development build and remove the error message.

Cheers Michael (mikehh)

in reply to: ↑ 4   Changed 4 years ago by doughera

Replying to mikehh:

However, although the message is generated it does not prevent the build and it continues fine,

That depends. If git is installed, then Configure.pl exits with an error status. The build will continue only if whatever is controlling the build process ignores the error status. I don't know offhand if rakudo's build process ignores errors or not, but it's certainly reasonable for a build script to pay attention to them.

In effect we need to check that we are building from the tarball and not a development build and remove the error message.

I think the fix is deeper but simpler. If Configure.pl is not building from a git repository, it should simply never try to invoke git in the first place. This will, as a welcome side effect, also avoid error messages in cases where git is not installed at all, and in cases where 'git' still refers to the GNU Interactive Tools (which is the case on the default NetBSD 5.0.1 setup I occasionally have access to for testing).

follow-up: ↓ 7   Changed 4 years ago by jkeenan

1. IIRC, in the long distant Subversion past, we used the presence/absence of a file called DEVELOPING to indicate whether you were working from the repository (presence) or from a release (absence). I just downloaded a tarball and unpacked it. It contained the file DEVELOPING. If the old rules still applied, the tarball should not have included DEVELOPING. This means that there was some oversight in the release instructions. This will have to be fixed.

2. Warning: Untested hypothesis coming up. We should modify the runstep() method in each of config/auto/sha1.pm and config/auto/git_describe.pm to say at an early point, return 1 unless (-f 'DEVELOPING'). (We may have to modify certain tests in t/configure/ and t/steps as well.)

I'm under the weather and can't stay up late enough to work this out. Is there anyone in the Eastern Hemisphere who could give this a shot?

Thank you very much.

kid51

in reply to: ↑ 6   Changed 4 years ago by doughera

Replying to jkeenan:

2. Warning: Untested hypothesis coming up. We should modify the runstep() method in each of config/auto/sha1.pm and config/auto/git_describe.pm to say at an early point, return 1 unless (-f 'DEVELOPING').

I'd be strongly inclined to base the test off (-d .git) instead.

follow-up: ↓ 9   Changed 4 years ago by dukeleto

  • status changed from new to assigned
  • platform set to all
  • component changed from none to configure
  • owner set to dukeleto

I took doughera's advice and fixed it (hopefully) in a5ba11ab5c0bc6f42706ac38ed442b269ebb3e56

Please test.

in reply to: ↑ 8 ; follow-up: ↓ 10   Changed 4 years ago by doughera

Replying to dukeleto:

I took doughera's advice and fixed it (hopefully) in a5ba11ab5c0bc6f42706ac38ed442b269ebb3e56 Please test.

It now does not exit with an error status, so it's a definite improvement. However, it's still not clean. To be specific:

On a system with git installed, the following "fatal" errror messages still appear:

auto::ctags -         Is (exuberant) ctags installed......................yes.
auto::revision -      Determine Parrot's revision...........................1.fatal: Not a git repository
auto::sha1 -          Determine Parrot's sha1............................done.fatal: Not a git repository
auto::git_describe -  Determine Parrot's git-describe....................done.

but fortunately, they aren't fatal at all. Configure.pl exits with a 0 status.

On a system without git installed, the following messages appear:

auto::ctags -         Is (exuberant) ctags installed......................yes.
auto::revision -      Determine Parrot's revision...........................1.Can't exec "git": No such file or directory at lib/Parrot/SHA1.pm line 75.
Use of uninitialized value $sha1 in scalar chomp at lib/Parrot/SHA1.pm line 76.
Use of uninitialized value $sha1 in concatenation (.) or string at lib/Parrot/SHA1.pm line 62.

auto::sha1 -          Determine Parrot's sha1............................done.Can't exec "git": No such file or directory at lib/Parrot/Git/Describe.pm line 78.
Use of uninitialized value $git_describe in scalar chomp at lib/Parrot/Git/Describe.pm line 79.
Use of uninitialized value $git_describe in concatenation (.) or string at lib/Parrot/Git/Describe.pm line 65.

auto::git_describe -  Determine Parrot's git-describe....................done.

but, again, Configure.pl exits with a 0 status.

However, rakudo is still unhappy. Installing this parrot into /tmp/parrot, and then running rakudo's Configure.pl gives the following errors:

        perl Configure.pl --parrot-config=/tmp/parrot/bin/parrot_config

Reading configuration information from /tmp/parrot/bin/parrot_config ...
Use of uninitialized value $bb in pattern match (m//) at build/lib/Rakudo/CompareRevisions.pm line 20.
Use of uninitialized value $g in pattern match (m//) at build/lib/Rakudo/CompareRevisions.pm line 11.
Use of uninitialized value $g in concatenation (.) or string at build/lib/Rakudo/CompareRevisions.pm line 11.
Invalid revision specifier: '' (expected something of format RELEASE_1_2_3-123-gdeadbee)

Whether this is something that should be addressed at parrot's end or at rakudo's end, I don't know, but it probably shouldn't be left as is.

in reply to: ↑ 9 ; follow-up: ↓ 11   Changed 4 years ago by jkeenan

Replying to doughera:

Can you try again subsequent to commit 5ac740e715f755125ae2423207657700471c2fe2 ?

thanks.

kid51

in reply to: ↑ 10 ; follow-up: ↓ 12   Changed 4 years ago by doughera

Replying to jkeenan:

Replying to doughera: Can you try again subsequent to commit 5ac740e715f755125ae2423207657700471c2fe2 ?

The Configure.pl warning messages are now gone.

Rakudo still is unhappy with the result.

in reply to: ↑ 11   Changed 4 years ago by doughera

  • status changed from assigned to closed
  • resolution set to fixed

Replying to doughera:

Replying to jkeenan:

Replying to doughera: Can you try again subsequent to commit 5ac740e715f755125ae2423207657700471c2fe2 ?

The Configure.pl warning messages are now gone. Rakudo still is unhappy with the result.

As of rakudo 2010.10-58-gb469741, rakudo is now happy with the result. Closing ticket.

Note: See TracTickets for help on using tickets.