Re: Dynamic token kinds

[Frank Heckenbach]

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.

> > I suppose I could ask you to send me a "dist" archive for testing
> > now, or if only "data" files need changes compared to 3.2.2, post
> > those, but for testing future changes, that's not a very nice
> > workflow. Is there any better way?
> 
> 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.

> 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. Seems like gnulib
is the culprit (or one of them). Now I could go on a rant how gnulib
(and also automake etc.) insert themselves into user's sources
rather than being installed like usual libraries (which might have
been a sensible tactic in the 1980s where GNU software was usually
built on "hostile" systems, but not these days where most builds are
done on GNU-based systems anyway and even elsewhere, compatibility
layers (mingw etc.) can be easily installed). 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).

Perhaps what I can do (as I slight kludge) for future patches is to
extract a full release (like the above) first and then extract, say,
a GitHub download over it. Assuming gnulib etc. are not changed
critically between these versions, it might just work. [...] Well,
two more complications, I needed to get automake-1.16 from testing
(fortunately not so big, and hopefully just a one-time download),
and the GitHub download contains some dangling symlinks which I have
to remove (hopefully using the ones from the full release causes no
issues). So this simple procedure (noted FMI ;) seems to work for me:

tar xf ~/work/bison-3.2.1.127-777b.tar.xz
cd bison-3.2.1.127-777b
unzip ~/work/bison-make-symbol.zip
find -xtype l -delete
tar -C bison-make-symbol/ -cf - . | tar -xf -
./configure
make -j

Regards,
Frank