search

rrthomas / libpaper

Library and command-line tools for configuring and getting information on paper sizes
GNU Lesser General Public License v2.1
9 stars 11 forks source link

1.2.0: build issue #19

Closed kloczek closed 2 years ago

kloczek commented 2 years ago

Looks like there is no dist tar ball with integrated gnulib and ..

[tkloczko@devel-g2v libpaper-1.2.0]$ ./bootstrap
bootstrap: warning: Consider installing git-merge-changelog from gnulib.
bootstrap: running: /usr/bin/libtoolize --quiet
bootstrap: running: git clone --shallow-since=2021-01-13 'git://git.sv.gnu.org/gnulib.git' 'gnulib'
Cloning into 'gnulib'...
fatal: unable to connect to git.sv.gnu.org:
git.sv.gnu.org[0: 209.51.188.168]: errno=Connection timed out
git.sv.gnu.org[1: 2001:470:142::168]: errno=Network is unreachable

Issue:

rrthomas commented 2 years ago

As per README, no need to bootstrap a source distribution.

rrthomas commented 2 years ago

As you can see in https://github.com/rrthomas/libpaper/blob/master/bootstrap.conf , gnulib is used only for non-POSIX functions and other functionality (crucially to libpaper, the relocatable-perl module). (The use of free-posix and realloc-posix is to work around a build problem.)

kloczek commented 2 years ago

That is thae isse that libpaper it is not so complicated that it needs to use non-POSIX functions ..

rrthomas commented 2 years ago

Ha! Well, they are not very complicated functions: getline, strcase and strndup. Still, they are all easy to get wrong, and I don't see much point in duplicating work in their implementation when I can use tried-and-tested definitions that are shared with other projects. Gnulib is well-maintained, and benefits from frequent fixes and improvements.

kloczek commented 2 years ago

Don't get me wrong .. I'm not pointing on that to remove that yesterday or tody 😋 Using libgnu was OK +15 years ago but if you will look around in mean time some projects managed to drop use of it and raplace by something else😃

rrthomas commented 2 years ago

Unfortunately(!), I've been adding gnulib to projects in the last 15 years, and indeed it's more useful today than it was when I started. I have thought about what it would take to remove it from one or two specific projects, and the answer is that it would be a lot of work, whether to find replacements for the various non-standard APIs that it provides, or for the other non-code tooling that it offers (such as relocatability). For portable code, GLib may be a reasonable base. For portable build systems (replacing also GNU autotools) I'm less sure: all the alternatives that I've seen seem to require system-specific code in the build system, whereas I typically have none in most projects and just a handful of lines for Windows in one or two. Moving away from C makes things much easier, but of course that is often not practical (for example, I did rewrite libpaper entirely in Perl, but that would have required substantial patches to its existing C clients, and in the end I gave up and went back to C). I have also used Vala for some projects (e.g. I rewrote GNU Zile in Vala), which would make it easier to move away from autotools and gnulib; but "easier", not "easy".