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
