Helper script && noinst_SCRIPTS
Hello! I have a question about GNU automake. I have a helper script in tests subdirectory of my project. This script is used ONLY for tests (make check). So, it should be distributed. I added the following lines dist_bin_SCRIPTS = fds_by_process.sh check_SCRIPTS = fds_by_process.sh in tests/Makefile.am Of course I don't want to install this script (by make install). So, I added noinst_SCRIPTS = fds_by_process.sh in tests/Makefile.am. Unfortunately, this script is installed by "make install". What's wrong? Thank you beforehand! -- Sincerely yours, Dmitry V. Krivenok Orange System Company Saint-Petersburg, Russia work phone: +7 812 332-32-40 cellular phone: +7 921 576-70-91 e-mail: [EMAIL PROTECTED] web: http://www.orangesystem.ru skype: krivenok_dmitry jabber: [EMAIL PROTECTED] icq: 242-526-443
Re: simple distcheck fails
Hi Ralf, On Friday 2008-11-28 06:25, Ralf Wildenhues wrote: >* Jan Engelhardt wrote on Thu, Nov 27, 2008 at 11:12:24PM CET: >> >> ---<8--- Makefile.am >> AUTOMAKE_OPTIONS = foreign subdir-objects >> noinst_DATA = foo.txt > >> make distcheck > >> make[1]: Entering directory `/dev/shm/t/obj/foo-0/_build' >> make[1]: *** No rule to make target `foo.txt', needed by `all-am'. >> Stop. > >Try using dist_noinst_DATA instead, so that foo.txt is added to the >tarball. That works. Now I am hitting the following problem — `make distcheck` from an obj dir fails, e.g. 14:04 yaguchi:/dev/shm/test > l total 256 drwxr-xr-x 2 jengelh users260 Nov 28 14:04 . drwxrwxrwt 4 rootroot 80 Nov 28 14:01 .. -rw-r--r-- 1 jengelh users 65 Nov 28 14:01 Makefile.am -rw-r--r-- 1 jengelh users 19388 Nov 28 14:03 Makefile.in -rw-r--r-- 1 jengelh users 32266 Nov 28 14:03 aclocal.m4 -rwxr-xr-x 1 jengelh users 52 Nov 28 14:02 autogen.sh -rwxr-xr-x 1 jengelh users 130473 Nov 28 14:03 configure -rw-r--r-- 1 jengelh users111 Nov 28 14:02 configure.ac -rwxr-xr-x 1 jengelh users 17867 Nov 28 14:03 depcomp -rw-r--r-- 1 jengelh users 68 Nov 28 14:04 foo.c -rw-r--r-- 1 jengelh users 23 Nov 28 14:03 foo.h -rwxr-xr-x 1 jengelh users 13620 Nov 28 14:03 install-sh -rwxr-xr-x 1 jengelh users 11135 Nov 28 14:03 missing 14:04 yaguchi:/dev/shm/test > md obj 14:04 yaguchi:/dev/shm/test > cd obj 14:04 yaguchi:../test/obj > ../configure >/dev/null 14:04 yaguchi:../test/obj > make CC foo.o CCLD foo 14:04 yaguchi:../test/obj > make distcheck V=2 [...] make[1]: Entering directory `/dev/shm/test/obj/foo-0/_build' depbase=`echo foo.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" -DPACKAGE_VERSION=\"0\" -DPACKAGE_STRING=\"foo\ 0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"foo\" -DVERSION=\"0\" -I. -I.. -g -O2 -MT foo.o -MD -MP -MF -$depbase.Tpo -c -o foo.o ../foo.c &&\ mv -f $depbase.Tpo $depbase.Po ../foo.c:1:17: error: foo.h: No such file or directory make[1]: *** [foo.o] Error 1 make[1]: Leaving directory `/dev/shm/test/obj/foo-0/_build' make: *** [distcheck] Error 2 That is because it uses "/dev/shm/test/obj/foo-0/_build/../.." as $srcdir (which however is the $builddir) instead of "/dev/shm/test/obj/foo-0/_build/.." Jan
lzip support
commit 6f949a61df1cfc778ab91de037b611bd8bad3735
Author: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Thu Nov 27 23:28:35 2008 +0100
Add LZIP support
---
ChangeLog | 10 ++
Makefile.in |8 +++-
automake.in |3 ++-
doc/automake.texi | 17 +++--
lib/Automake/Options.pm |3 ++-
lib/am/distdir.am |6 ++
6 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ef7f710..4e6cd33 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2008-11-27 Jan Engelhardt <[EMAIL PROTECTED]>
+
+ * automake.in (handle_dist): Recognize dist-lzip.
+ (make_paragraphs): Map LZIP to dist-lzip.
+ * doc/automake.texi (Dist): Add dist-lzip.
+ (Options): Likewise.
+ * lib/Automake/Options.pm (_process_option_list):
+ (dist dist-all): Add command to create an lzip-compressed tarball.
+ (distcheck): Handle lzip-compressed tarballs just like the others.
+
2008-11-24 Ralf Wildenhues <[EMAIL PROTECTED]>
Let `missing' also work with versioned and prefixed programs.
diff --git a/Makefile.in b/Makefile.in
index 7f8b810..1a269d1 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -534,6 +534,10 @@ dist-lzma: distdir
tardir=$(distdir) && $(am__tar) | lzma -9 -c >$(distdir).tar.lzma
$(am__remove_distdir)
+dist-lzip: distdir
+ tardir=${distdir} && ${am__tar} | lzip -9c >${distdir}.tar.lz
+ ${am__remove_distdir}
+
dist-xz: distdir
tardir=$(distdir) && $(am__tar) | xz -c >$(distdir).tar.xz
$(am__remove_distdir)
@@ -567,6 +571,8 @@ distcheck: dist
bunzip2 -c $(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.lzma*) \
unlzma -c $(distdir).tar.lzma | $(am__untar) ;;\
+ *.tar.lz*) \
+ lzip -9cd ${distdir}.tar.lz | ${am__untar};; \
*.tar.xz*) \
xz -dc $(distdir).tar.xz | $(am__untar) ;;\
*.tar.Z*) \
@@ -726,7 +732,7 @@ uninstall-am: uninstall-binSCRIPTS
.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
all all-am am--refresh check check-am clean clean-generic \
ctags ctags-recursive dist dist-all dist-bzip2 dist-gzip \
- dist-hook dist-lzma dist-shar dist-tarZ dist-xz dist-zip \
+ dist-hook dist-lzma dist-lzip dist-shar dist-tarZ dist-xz dist-zip \
distcheck distclean distclean-generic distclean-tags \
distcleancheck distdir distuninstallcheck dvi dvi-am html \
html-am info info-am install install-am install-binSCRIPTS \
diff --git a/automake.in b/automake.in
index 24bb193..f4085da 100755
--- a/automake.in
+++ b/automake.in
@@ -3723,7 +3723,7 @@ sub handle_dist ()
{
my $archive_defined = option 'no-dist-gzip' ? 0 : 1;
$archive_defined ||=
- grep { option "dist-$_" } qw(shar zip tarZ bzip2 lzma xz);
+ grep { option "dist-$_" } qw(shar zip tarZ bzip2 lzma lzip xz);
error (option 'no-dist-gzip',
"no-dist-gzip specified but no dist-* specified, "
. "at least one archive format must be enabled")
@@ -6633,6 +6633,7 @@ sub make_paragraphs ($%)
'XZ' => !! option 'dist-xz',
'LZMA'=> !! option 'dist-lzma',
+'LZIP'=> !! option 'dist-lzip',
'BZIP2' => !! option 'dist-bzip2',
'COMPRESS'=> !! option 'dist-tarZ',
'GZIP'=> ! option 'no-dist-gzip',
diff --git a/doc/automake.texi b/doc/automake.texi
index 065e6fa..19b9e1c 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -8258,6 +8258,12 @@ Generate an @samp{lzma} tar archive of the distribution.
@command{lzma}
archives are frequently smaller than @command{bzip2}-compressed archives.
@trindex dist-lzma
[EMAIL PROTECTED] @code{dist-lzip}
+Generate an @samp{LZIP} tar archive of the distribution. @command{lzip}
+archives are frequently smaller than @command{bzip2}-compressed archives,
+and provide magic bytes and a checksum over LZMA archives.
[EMAIL PROTECTED] dist-lzip
+
@item @code{dist-shar}
Generate a shar archive of the distribution.
@trindex dist-shar
@@ -8577,6 +8583,12 @@ Hook @code{dist-bzip2} to @code{dist}.
Hook @code{dist-lzma} to @code{dist}.
@trindex dist-lzma
[EMAIL PROTECTED] @option{dist-lzip}
[EMAIL PROTECTED] Option, @option{dist-lzip}
[EMAIL PROTECTED] dist-lzip
+Hook @code{dist-lzip} to @code{dist}.
[EMAIL PROTECTED] dist-lzip
+
@item @option{dist-shar}
@cindex Option, @option{dist-shar}
@opindex dist-shar
@@ -8748,7 +8760,8 @@ In order to use this option with C sources, you should add
These three mutually exclusive options select the tar format to use
when generating tarballs with @samp{make dist}. (The tar file created
is then compressed according to the set of @option{no-dist-gzip},
[EMAIL PROTECTED], @option{dist-lzma} and @option{dist-tarZ} options in use.)
[EMAIL PROTECTED], @option{dist-lzma}, @option{di
Helper script && noinst_SCRIPTS
Hello! I have a question about GNU automake. I have a helper script in tests subdirectory of my project. This script is used ONLY for tests (make check). So, it should be distributed. I added the following lines dist_bin_SCRIPTS = fds_by_process.sh check_SCRIPTS = fds_by_process.sh in tests/Makefile.am Of course I don't want to install this script (by make install). So, I added noinst_SCRIPTS = fds_by_process.sh in tests/Makefile.am. Unfortunately, this script is installed by "make install". What's wrong? Thank you beforehand! -- Sincerely yours, Dmitry V. Krivenok Orange System Company Saint-Petersburg, Russia work phone: +7 812 332-32-40 cellular phone: +7 921 576-70-91 e-mail: [EMAIL PROTECTED] web: http://www.orangesystem.ru skype: krivenok_dmitry jabber: [EMAIL PROTECTED] icq: 242-526-443
Re: lzip support
Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake already had LZMA support, can someone please explain LZIP vs LZMA and why we now have at least two LZMA compressed targets? Is offering support for two LZMA compressors encouraging the continued babbelization and subsequent disintegration of GNU projects? I see that LZIP is GPL licensed and is pretty small, and with just one author. It also seems that LZIP is not capable of decoding LZMA utils output. If automake now supports 'lzip', why does it not also offer to support 7-Zip', 'srpm', 'zoo', 'arc', and the many other possible archiving formats so that confusion of the user base can become complete? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: lzip support
On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: > Since LZIP support has appeared apparently out of the blue (no > prior discussion on this list), and Automake already had LZMA > support, can someone please explain LZIP vs LZMA and why we now > have at least two LZMA compressed targets? See http://lists.gnu.org/archive/html/lzip-bug/2008-11/msg3.html , I think this should answer it. > I see that LZIP is GPL licensed and is pretty small, and with just > one author. Sometimes, simplicity is the key. And I do not think that having exactly 1.0 authors makes a project insignificant. > It also seems that LZIP is not capable of decoding LZMA > utils output. In the gzip × bzip2 × lzma matrix, neither can decode another. So it's not like lzip would be missing a feature others would have. > If automake now supports 'lzip', why does it not also offer to support 7-Zip', > 'srpm', 'zoo', 'arc', and the many other possible archiving formats so that > confusion of the user base can become complete? I would say because 7zip, ZOO and ARC (what's with these 1990s packers?) do not support UNIX owners nor permissions (required for the beloved +x bit on scripts.).
Re: lzip support
On Fri, 28 Nov 2008, Jan Engelhardt wrote: I see that LZIP is GPL licensed and is pretty small, and with just one author. Sometimes, simplicity is the key. And I do not think that having exactly 1.0 authors makes a project insignificant. Actually I like the "1.0 authors" since it makes the copyright issues more clear and means that there is someone empowered to update the license or defend the copyright if necessary. In contrast FSF GNU projects require that all authors sign a contract with the FSF to assign copyrights. That is a tedious task. I like simplicity as well. From my point of view 'gzip' is an ideal package other than its compression ratio. If automake now supports 'lzip', why does it not also offer to support 7-Zip', 'srpm', 'zoo', 'arc', and the many other possible archiving formats so that confusion of the user base can become complete? I would say because 7zip, ZOO and ARC (what's with these 1990s packers?) do not support UNIX owners nor permissions (required for the beloved +x bit on scripts.). It was my impression that Automake adopted LZMA utils without fully evaluating the impact. Introducing a new archive format is really quite a big deal since it impacts many thousands of open source users well into the future. As it turned out, LZMA utils conflicted with another available LZMA utility, which caused some problems for FreeBSD and likely other distributions as well. My own package is now distributing .lzma packages. This is a big deal for it moving forward since changing the package format will break something. OS distributions are only recently becoming used to .lzma and have had to update scripts and tools to deal with it. Due to the preponderance of distribution formats, the actual amount of data on ftp sites is dramatically increasing rather than decreasing since packages feel that they must produce archives in every possible format. If an archive format was ever offered before, the feeling is that it must continue to be offered for the rest of time. It would be useful if the Automake project would thoroughly research all issues and come up with a plan which reduces total world impact. We need a Green Solution which avoids wasteful practices which surely increase global warming and further tax our dwindling fossil fuel supply. These are all factors which should be considered: * Number of files needing to be uploaded to distribution sites, or mirrored. * Individual file size. * Utility implementation license and copyrights. * Utility portability. * Utility performance and reliability. * Utility usage complexity. * Utility long-term maintenance expectations. * Effort to integrate into established packaging and source distribution systems. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: simple distcheck fails
Hello Jan, * Jan Engelhardt wrote on Fri, Nov 28, 2008 at 02:06:57PM CET: > `make distcheck` from an obj dir fails, e.g. > > 14:04 yaguchi:/dev/shm/test > l > total 256 > drwxr-xr-x 2 jengelh users260 Nov 28 14:04 . > drwxrwxrwt 4 rootroot 80 Nov 28 14:01 .. > -rw-r--r-- 1 jengelh users 65 Nov 28 14:01 Makefile.am > -rw-r--r-- 1 jengelh users 19388 Nov 28 14:03 Makefile.in > -rw-r--r-- 1 jengelh users 32266 Nov 28 14:03 aclocal.m4 > -rwxr-xr-x 1 jengelh users 52 Nov 28 14:02 autogen.sh > -rwxr-xr-x 1 jengelh users 130473 Nov 28 14:03 configure > -rw-r--r-- 1 jengelh users111 Nov 28 14:02 configure.ac > -rwxr-xr-x 1 jengelh users 17867 Nov 28 14:03 depcomp > -rw-r--r-- 1 jengelh users 68 Nov 28 14:04 foo.c > -rw-r--r-- 1 jengelh users 23 Nov 28 14:03 foo.h > -rwxr-xr-x 1 jengelh users 13620 Nov 28 14:03 install-sh > -rwxr-xr-x 1 jengelh users 11135 Nov 28 14:03 missing > 14:04 yaguchi:/dev/shm/test > md obj > 14:04 yaguchi:/dev/shm/test > cd obj > 14:04 yaguchi:../test/obj > ../configure >/dev/null > 14:04 yaguchi:../test/obj > make > CC foo.o > CCLD foo > 14:04 yaguchi:../test/obj > make distcheck V=2 > [...] > make[1]: Entering directory `/dev/shm/test/obj/foo-0/_build' > depbase=`echo foo.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" > -DPACKAGE_VERSION=\"0\" -DPACKAGE_STRING=\"foo\ 0\" -DPACKAGE_BUGREPORT=\"\" > -DPACKAGE=\"foo\" -DVERSION=\"0\" -I. -I.. -g -O2 -MT foo.o -MD -MP -MF > -$depbase.Tpo -c -o foo.o ../foo.c &&\ > mv -f $depbase.Tpo $depbase.Po > ../foo.c:1:17: error: foo.h: No such file or directory > make[1]: *** [foo.o] Error 1 > make[1]: Leaving directory `/dev/shm/test/obj/foo-0/_build' > make: *** [distcheck] Error 2 > > That is because it uses "/dev/shm/test/obj/foo-0/_build/../.." as > $srcdir (which however is the $builddir) instead of > "/dev/shm/test/obj/foo-0/_build/.." This seems to be a misunderstanding. What distcheck does here is the following: - first create a distribution tarball, - then, extract this tarball into a subdirectory foo-0/, - then, configure the sources in that subdirectory, in a VPATH setup, i.e., using a relative build directory named _build/. The most likely reason for the failure is that foo.h is not packaged. Solution then is to list it in *_SOURCES as well: bin_PROGRAMS = foo foo_SOURCES = foo.c foo.h Cheers, Ralf
Re: Helper script && noinst_SCRIPTS
Hi Dmitry, * Dmitry V. Krivenok wrote on Fri, Nov 28, 2008 at 09:40:09AM CET: > I have a helper script in tests subdirectory of my project. > This script is used ONLY for tests (make check). > So, it should be distributed. > > I added the following lines > dist_bin_SCRIPTS = fds_by_process.sh > check_SCRIPTS = fds_by_process.sh > in tests/Makefile.am > > Of course I don't want to install this script (by make install). > So, I added > noinst_SCRIPTS = fds_by_process.sh > in tests/Makefile.am. > > Unfortunately, this script is installed by "make install". Using either the check_SCRIPTS or the noninst_SCRIPTS line without the other two lines should be sufficient to fix this. Cheers, Ralf
Re: automake branch management
Hello Jan, all, [ This discussion started off-list (see below for discussion of that topic, too ;-). I'm quoting generously so that all context should be available ] * Jan Engelhardt wrote on Fri, Nov 28, 2008 at 12:19:45PM CET: > On Friday 2008-11-28 06:28, Ralf Wildenhues wrote: > > > >First off, why not discuss this on [EMAIL PROTECTED] > > Well seems to me more like a personal development idiom. Well, that may be, but even so, it generally really helps to keep _all_ discussion related to package development on-list (unless of course there is a reason for privacy), for several reasons: - one can search for it later and hope to actually find it. I've had this problem myself several times, after deleting off-list discussion that, at the time, looked like a finished topic to me. - it improves transparency of the project; lack of transparency may deter potential contributors, and makes it harder for future maintainers to learn about the motives behind some non-obvious decisions made earlier. I have been thankful for Automake mailing list archives from 2001 before, and have more than once wished I had archives from discussions in the 90s. - other list participants may have good ideas that one doesn't know about, doesn't have, and won't ever learn in an off-list discussion. - last but not least, curious developers may find the answer to questions such as yours in the archives, and won't have to ask me personally, should they have that same question. ;-) Now to the meat: > >* Jan Engelhardt wrote on Thu, Nov 27, 2008 at 11:32:50PM CET: > >> > >> I see that cherry-picking is used rather excessively in the automake git > >> repository. Is there anything that speaks against just merging "stable" > >> (whatever currently runs, atm this is origin/branch-1-10) regularly into > >> "master"? > > > >Well, when I started it, it seemed to me the easier way. Merging is > >problematic because not all changes from branch-1-10 belong in master. > >For example the release changes. I don't see how to avoid that. > > I usually do the release changes (version bump) when it is about > to be released. > > When you graph git://dev.medozas.de/pam_mount with `gitk --all` for example, > you may find that practice between 0.40--0.43 or 0.45--0.47. Yes, I see that. Maybe it is useful to try out such a changed setup when starting branch-1-11. Right now it seems problematic because master and branch-1-10 have quite a few independent (and mostly mechanical) changes which will cause merge conflicts, and I'm not really motivated to fix them. Hmm, trying out a 'git merge -s ours branch-1-10' mostly does the right thing: namely a zero content change, which causes any further merges to only consider newer history on the branch. Still, doing that makes history claim to have another 140some changes incorporated which aren't in fact there. Another thing that bothers me when merging from stable to master is that I'm not used to developing fixes on the stable branch. But given the chance for corruption with cherry-pick which I experienced in practice with 1.10.2, I'm willing to try out and change the strategy, but probably not before 1.11. So I think I will continue branch-1-10 as done now, and try to switch one branch-1-11 branches. Cheers, and thanks for the suggestion, Ralf
Re: lzip support
On Friday 2008-11-28 19:38, Bob Friesenhahn wrote: > On Fri, 28 Nov 2008, Jan Engelhardt wrote: > > It was my impression that Automake adopted LZMA utils without fully > evaluating the impact. My own package is now distributing .lzma > packages. It's only great until something better comes up :) > This is a big deal for it moving forward since changing the package > format will break something. OS distributions are only recently > becoming used to .lzma and have had to update scripts and tools to > deal with it. All I actually needed was a patch to the package builder (e.g. rpmbuild) to unpack lzip without having to explicitly call lzip. > Due to the preponderance of distribution formats, the actual amount > of data on ftp sites is dramatically increasing rather than > decreasing since packages feel that they must produce archives in > every possible format. Well talk to kernel.org for example. They are the ones still using gz besides bz2 (and they got one of the biggest packages) even when we can assume bzip2 is reasonably mature, more than any lzma. > If an archive format was ever offered before, the feeling is that > it must continue to be offered for the rest of time. *sigh* well, everybody is entitled to do his own liking and if that's providing all formats just because.
Re: missing help2man
* Werner LEMBERG wrote on Fri, Nov 28, 2008 at 07:18:46AM CET: > > > Anyway, maintainer-mode isn't very interesting; few packages use it. > > The more important question is what to do in non-maintainer mode, > > where (it seems to me) exactly the same problem will occur. For > > instance, in GNU Hello (well, except that has only one man page) or > > coreutils. > > Well, if `make' called by the user has to generate man pages with the > use of help2man, there *must* be a configure check for it. I don't > see a problem. The point is that this problem should only ever show up when you use VCS sources to build from, never from a release tarball: the tarball should always contain a copy of the man pages, and not need to rebuild them. Thus it would be over-reaching for example, to require that help2man is present, when configure is run from an extracted tarball. Cheers, Ralf
Re: simple distcheck fails
On Friday 2008-11-28 20:05, Ralf Wildenhues wrote: >> 14:04 yaguchi:../test/obj > make distcheck V=2 >> [...] >> make[1]: Entering directory `/dev/shm/test/obj/foo-0/_build' >> depbase=`echo foo.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ >> gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" >> -DPACKAGE_VERSION=\"0\" -DPACKAGE_STRING=\"foo\ 0\" -DPACKAGE_BUGREPORT=\"\" >> -DPACKAGE=\"foo\" -DVERSION=\"0\" -I. -I.. -g -O2 -MT foo.o -MD -MP -MF >> -$depbase.Tpo -c -o foo.o ../foo.c &&\ >> mv -f $depbase.Tpo $depbase.Po >> ../foo.c:1:17: error: foo.h: No such file or directory >> make[1]: *** [foo.o] Error 1 >> make[1]: Leaving directory `/dev/shm/test/obj/foo-0/_build' >> make: *** [distcheck] Error 2 >> >> That is because it uses "/dev/shm/test/obj/foo-0/_build/../.." as >> $srcdir (which however is the $builddir) instead of >> "/dev/shm/test/obj/foo-0/_build/.." > >This seems to be a misunderstanding. What distcheck does here is the >following: >- first create a distribution tarball, >- then, extract this tarball into a subdirectory foo-0/, >- then, configure the sources in that subdirectory, in a VPATH setup, > i.e., using a relative build directory named _build/. > >The most likely reason for the failure is that foo.h is not packaged. Ah that's it. Sigh, I so really prefer doing a git-archive HEAD | tar -C /tmp/whereever -xf- && run autogen.sh in whereever && pack up the stuff over distcheck atm :-P Jan
Re: automake branch management
On Friday 2008-11-28 20:37, Ralf Wildenhues wrote: >> When you graph git://dev.medozas.de/pam_mount with `gitk --all` for example, >> you may find that practice between 0.40--0.43 or 0.45--0.47. > >[...] Another thing that bothers me when merging from stable to >master is that I'm not used to developing fixes on the stable >branch. The motivation to manage it like this for pam_mount was that some past releases had rather many regressions which prompted me to do a bugfix-only branch. >[...] Still, doing that makes history claim to have another 140some >changes incorporated which aren't in fact there. If the code is already gone in master, that should be fine. It would usually indicate that the 140 fixes have been incorporated one way or another (and if that's replacing it by something new and shiny). Alternatively, you could run a 3-branch setup — master, fixestoboth and fixestocurrent, and only do the merge operations master<-fixestoboth and fixestocurrent<-fixestoboth to avoid "ours"-merges.
Re: lzip support
On Fri, 28 Nov 2008, Jan Engelhardt wrote: On Friday 2008-11-28 19:38, Bob Friesenhahn wrote: On Fri, 28 Nov 2008, Jan Engelhardt wrote: It was my impression that Automake adopted LZMA utils without fully evaluating the impact. My own package is now distributing .lzma packages. It's only great until something better comes up :) In this case, better means a single author and much less source code. But it does not currently seem to mean faster: freddy:~% ls -l GraphicsMagick-1.3.tar -r--r--r-- 1 bfriesen home 36925440 Nov 9 14:54 GraphicsMagick-1.3.tar freddy:~% ptime lzip -9 GraphicsMagick-1.3.tar real 1:19.836 user 1:19.347 sys 0.327 freddy:~% ptime lzip -d GraphicsMagick-1.3.tar.lz real0.882 user0.818 sys 0.061 freddy:~% ptime lzma -9 GraphicsMagick-1.3.tar real 55.439 user 54.630 sys 0.640 freddy:~% ptime lzma -d GraphicsMagick-1.3.tar.lzma real0.688 user0.622 sys 0.064 freddy:~% ptime gzip -9 GraphicsMagick-1.3.tar real2.970 user2.924 sys 0.039 freddy:~% ptime gzip -d GraphicsMagick-1.3.tar.gz real0.265 user0.223 sys 0.040 freddy:~% size /usr/local/bin/lzma 116956 + 8820 + 5748 = 131524 freddy:~% size /usr/local/bin/lzip 80304 + 4689 + 4307 = 89300 Compressed file sizes are quite similar. If an archive format was ever offered before, the feeling is that it must continue to be offered for the rest of time. *sigh* well, everybody is entitled to do his own liking and if that's providing all formats just because. Currently Automake does not seem to allow disabling gzip support. It makes sense to me that periodically Automake maintainers make an evaluation (and with the blessing of the FSF) intentionally deprecate generation of certain archive types as new archive types are added. The intention would be to diminish the number of archive types, which needlessly clog disk space and consume developer time. Initially there would be a warning, and after a couple of years, the less desired archive type would be removed entirely. At the moment I think that it is more desirable for bzip2 to be deprecated than gzip since the compression advantage of bzip2 is not that high and it takes much more CPU and memory. Zip is quite wasteful, but is perhaps most useful for Windows since it does not require 'tar' and there is native support in Windows. It should only be necessary to support one LZMA format. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: lzip support
On Friday 2008-11-28 21:37, Bob Friesenhahn wrote: > >> > If an archive format was ever offered before, the feeling is that >> > it must continue to be offered for the rest of time. >> >> *sigh* well, everybody is entitled to do his own liking and >> if that's providing all formats just because. > > Currently Automake does not seem to allow disabling gzip support. no-dist-gzip? What I was saying: you do not have to run make dist. You could run make dist-bzip2 instead. Producing one files as a side effect of build system is one thing, but uploading them to a public required manual intervention. > It makes sense to me that periodically Automake maintainers make an > evaluation (and with the blessing of the FSF) intentionally > deprecate generation of certain archive types as new archive types > are added. The intention would be to diminish the number of archive > types, which needlessly clog disk space and consume developer time. > > Initially there would be a warning, and after a couple of years, Woha, that's long. I take the freedom to usually do it within two releases. > the less desired archive type would be removed entirely. At the > moment I think that it is more desirable for bzip2 to be deprecated > than gzip since the compression advantage of bzip2 is not that high > and it takes much more CPU and memory. Well, compression always takes time. If you wanted to go for the best compression-to-time-ratio, you would have to go with uncompressed as the premium. > Zip is quite wasteful, but > is perhaps most useful for Windows since it does not require 'tar' > and there is native support in Windows. It should only be necessary > to support one LZMA format. Now how many Windows users can actually run shell scripts (as produced by autotools) out of the blue, without having, uh, a shell (from cygwin or msys). Once they however have such a unix layer, they also have tar and gzip at least.
Re: lzip support
On Sat, 29 Nov 2008, Jan Engelhardt wrote: Currently Automake does not seem to allow disabling gzip support. no-dist-gzip? What I was saying: you do not have to run make dist. If that works, then I was unaware of it. Initially there would be a warning, and after a couple of years, Woha, that's long. I take the freedom to usually do it within two releases. Many major OS distributions seem to be on a two-year cycle. An existing current distribution should not require continual maintenance to keep it its bits from rotting. Now how many Windows users can actually run shell scripts (as produced by autotools) out of the blue, without having, uh, a shell (from cygwin or msys). Once they however have such a unix layer, they also have tar and gzip at least. Even though Automake builds the distribution package, most of my Windows users use means other than shell scripts to download, extract, and build the package. The most they know about Unix is perhaps how to spell it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
