bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic token kinds


From: Akim Demaille
Subject: Re: Dynamic token kinds
Date: Sun, 23 Dec 2018 17:06:10 +0100


> Le 23 déc. 2018 à 12:46, Frank Heckenbach <address@hidden> a écrit :
> 
> Akim Demaille wrote:
> 
>>> but
>>> unfortunately git is quite data hungry and I'm a bit short on data
>>> volume (no broadband in my new appartment yet, and mobile data is
>>> paid in gold here in Germany),
>> 
>> Ouch.  We're lucky in France, that's very cheap.
> 
> I'm lucky to have a relatively fast connection at all. There are
> areas where RFC 1149 is the preferred transport layer.

:) :) :)


>> Please find the tarball here:
>> 
>> https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.1.127-777b.tar.gz
>> https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.1.127-777b.tar.xz
> 
> Thanks. I've tried it and it works with my parsers.

Great!


>> The best way would be to provide tarballs directly from my
>> GitHub repo.  After all, it's already running travis for the
>> tests, it can easily build tarballs.  However, I don't know
>> how to expose them, I don't think there is a free
>> (as in beer) way to do that.  If you have an idea, I'll take it!
> 
> I don't know too much about GitHub. As I said, I had hoped "Download
> Zip" would do it, but that's not self-contained.

I guess it's only an archive of the current files in the
repo.  So it's probably carrying nothing about gnulib.

[gnulib]
> I never liked that
> design, and apparently it's now causing me actual problems by
> breaking the simple download and vastly increasing the clone size
> (AFAICS, most of it is downloading the gnulib history which I don't
> care a tiny bit about, especially not when just trying to build
> Bison).

I can understand this.  However, this is the only model I can
see that really allows the maintainer of a package to be able
to use the latest version of the library, in case it addresses
a recent portability issue.  It's not too inconvenient to use
as a user of git, and it's completely invisible for the end
user (i.e., users of the tarballs).


> Perhaps what I can do (as I slight kludge) for future patches is to
[...]

The easiest, by far, would be for me to provide you with a
viable tarball :(




reply via email to

[Prev in Thread] Current Thread [Next in Thread]