On Sat Jan 23 04:27:45 2016, jkeenan wrote:
> Following up on my failed attempt to build Rakudo Star on an older Mac
> (https://rt.perl.org/Ticket/Display.html?id=127308), this morning I
> attempted to build the Rakudo compiler from blead. Following the
> instructions at http://rakudo.org/how-to-get-rakudo/#Installing-
> Rakudo, I downloaded the source, switched into the rakudo directory
> and tried to configure. Here is the result:
>
> #####
> Script started on Sat Jan 23 07:04:40 2016
> $ perl Configure.pl --gen-moar --gen-nqp --backends=moar
>
> ATTENTION: no --prefix supplied, building and installing to
> /Users/jimk/gitwork/rakudo/install
>
> sh: line 1: /Users/jimk/gitwork/rakudo/install/bin/nqp-m: No such file
> or directory
>
> Initialized empty Git repository in
> /Users/jimk/gitwork/rakudo/nqp/.git/
>
> fatal: https://github.com/perl6/nqp.git/info/refs download error -
> Protocol https not supported or disabled in libcurl
>
> Command failed (status 32768): git clone
> https://github.com/perl6/nqp.git nqp
> #####
>
> 2 problems:
>
> 1. /Users/jimk/gitwork/rakudo/install was not created. Why not? This
> seems like a very elementary problem.
Install is created -on install-. Configuring, if successful, installs moar &
nqp. make-ing, if successful, also installs.
Neither step succeeded, nothing installed, no need to create the dir.
Seems like it's not a problem at all.
> 2. Why is Rakudo configuration so dependent on a specific version of
> git or on a specific protocol?
It's a default designed for use by the majority of our developers and those
building from HEAD.
If you don't want to use the builtin config helper, you have a few options:
1) Download nqp & moar yourself and build them yourself. The configure step in
rakudo has a helper which works for a majority of the cases and pulls these
projects for you. If you do it yourself, then you can use whatever protocol
works for you. Do moarvm first, then nqp, and use the same --prefix on each
config step so everything gets installed in the same place.
2) Try using perl Configure.pl with the option:
--git-protocol={ssh,https,git}
Protocol used for cloning git repos
If your git client is too old to support https, perhaps it supports git or ssh.
3) Try the macport version. It's possible that might work, even on your
machine. No promises.
> Notwithstanding the age of this machine and the unavailability or
> unbuildability of any git version newer than the 1.6.3.2 which I have,
> I've been able to use 'git clone' on many github.com projects for at
> least 6 years. It appears that Rakudo, Moar, etc., have hard-wired
> themselves to expect certain versions of git and are therefore less
> accessible than most other projects on github.
It's defaulting to a particular protocol, not a version of git.
> Now, I can very well imagine that Rakudo, Moar and Perl 6 might all
> fail to build on a 12-year-old machine due to lack of memory or
> inability to install a minimal version of some C compiler. But they
> should not fail due to a limitation of the machine's version control
> client.
If your git client is 5 years old, it's not entirely unreasonable. There is a
very limited pool of developers on this project, and by necessity, they will be
working on hardware that is available to them, which is probably going to be of
a more recent vintage. They're going to target more recent versions of the OS,
the hardware, and the toolchain. That said, it's not your git client, per se,
that's the problem here.
We're happy to help folks who are trying to get something working on a less
common or older machine, but it is not a priority. But those folks have to take
a more active role in requesting support than someone running the latest
version of the tools.
That said, again, it's not a problem with the git client, per se.
> That's simply stupid. Can this be corrected?
There is absolutely no need for the penultimate sentence here, Jim. It's
simply... superfluous, and based on an incorrect analysis or incomplete
information. It certainly doesn't help inspire those of us with a limited
amount of time available to provide support.
> Thank you very much.
> Jim Keenan
You're welcome. As noted, I expect you'll get further if you build things
separately as noted above.
--
Will "Coke" Coleda
