[patch] fix parallel build failures in xfsprogs-3.0.0

[patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1.1: Type: text/plain, Size: 341 bytes --]

i noticed that xfsprogs-3.0.0 sometimes fails to build in parallel with an 
error about fsr not being able to find libhandle.  looking at the top level 
Makefile shows the obvious missing depend (fsr: libhandle).  playing around a 
bit found a few more not so obvious missing depends on the include subdir, so 
i fixed that too.
-mike

[-- Attachment #1.1.2: xfsprogs-3.0.0-parallel-build.patch --]
[-- Type: text/x-patch, Size: 914 bytes --]

http://bugs.gentoo.org/260005

--- a/Makefile
+++ b/Makefile
@@ -15,11 +15,11 @@
 LDIRT = config.log .dep config.status config.cache confdefs.h conftest* \
 	Logs/* built .census install.* install-dev.* *.gz
 
-LIB_SUBDIRS = include libxfs libxlog libxcmd libhandle libdisk
+LIB_SUBDIRS = libxfs libxlog libxcmd libhandle libdisk
 TOOL_SUBDIRS = copy db estimate fsck fsr growfs io logprint mkfs quota \
 		mdrestore repair rtcp m4 man doc po debian build
 
-SUBDIRS = $(LIB_SUBDIRS) $(TOOL_SUBDIRS)
+SUBDIRS = include $(LIB_SUBDIRS) $(TOOL_SUBDIRS)
 
 default: include/builddefs include/platform_defs.h
 ifeq ($(HAVE_BUILDDEFS), no)
@@ -29,9 +29,10 @@
 endif
 
 # tool/lib dependencies
-libxcmd: include
+$(LIB_SUBDIRS) $(TOOL_SUBDIRS): include
 copy mdrestore: libxfs
 db logprint: libxfs libxlog
+fsr: libhandle
 growfs: libxfs libxcmd
 io: libxcmd libhandle
 mkfs: libxfs libdisk

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Eric Sandeen]

Mike Frysinger wrote:
> i noticed that xfsprogs-3.0.0 sometimes fails to build in parallel with an 
> error about fsr not being able to find libhandle.  looking at the top level 
> Makefile shows the obvious missing depend (fsr: libhandle).  playing around a 
> bit found a few more not so obvious missing depends on the include subdir, so 
> i fixed that too.
> -mike

Seems fine.  Looks like that dep got missed when fsr moved.

the include dependency might be a big hammer, but *shrug* (it takes care
of the "estimate" dependency on include too)

I'll check this in, thanks.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Eric Sandeen]

Mike Frysinger wrote:
> i noticed that xfsprogs-3.0.0 sometimes fails to build in parallel with an 
> error about fsr not being able to find libhandle.  looking at the top level 
> Makefile shows the obvious missing depend (fsr: libhandle).  playing around a 
> bit found a few more not so obvious missing depends on the include subdir, so 
> i fixed that too.
> -mike

Oh, can you resend with a formal Signed-off-by: line?  Being a little
nitpicky here but we follow the same process as kernel patches.

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 683 bytes --]

On Tuesday 24 February 2009 00:22:40 Eric Sandeen wrote:
> Mike Frysinger wrote:
> > i noticed that xfsprogs-3.0.0 sometimes fails to build in parallel with
> > an error about fsr not being able to find libhandle.  looking at the top
> > level Makefile shows the obvious missing depend (fsr: libhandle). 
> > playing around a bit found a few more not so obvious missing depends on
> > the include subdir, so i fixed that too.
>
> Oh, can you resend with a formal Signed-off-by: line?  Being a little
> nitpicky here but we follow the same process as kernel patches.

where is the git tree now ?  i tried git://oss.sgi.com/xfs-cmds but that seems 
to be dead now.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Tue, Feb 24, 2009 at 02:21:43AM -0500, Mike Frysinger wrote:
> On Tuesday 24 February 2009 00:22:40 Eric Sandeen wrote:
> > Mike Frysinger wrote:
> > > i noticed that xfsprogs-3.0.0 sometimes fails to build in parallel with
> > > an error about fsr not being able to find libhandle.  looking at the top
> > > level Makefile shows the obvious missing depend (fsr: libhandle). 
> > > playing around a bit found a few more not so obvious missing depends on
> > > the include subdir, so i fixed that too.
> >
> > Oh, can you resend with a formal Signed-off-by: line?  Being a little
> > nitpicky here but we follow the same process as kernel patches.
> 
> where is the git tree now ?  i tried git://oss.sgi.com/xfs-cmds but that seems 
> to be dead now.

http://git.kernel.org/?p=fs/xfs/xfsprogs-dev.git;a=tree for the bleeding
edge development tree.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 1177 bytes --]

On Tuesday 24 February 2009 08:15:23 Christoph Hellwig wrote:
> On Tue, Feb 24, 2009 at 02:21:43AM -0500, Mike Frysinger wrote:
> > On Tuesday 24 February 2009 00:22:40 Eric Sandeen wrote:
> > > Mike Frysinger wrote:
> > > > i noticed that xfsprogs-3.0.0 sometimes fails to build in parallel
> > > > with an error about fsr not being able to find libhandle.  looking at
> > > > the top level Makefile shows the obvious missing depend (fsr:
> > > > libhandle). playing around a bit found a few more not so obvious
> > > > missing depends on the include subdir, so i fixed that too.
> > >
> > > Oh, can you resend with a formal Signed-off-by: line?  Being a little
> > > nitpicky here but we follow the same process as kernel patches.
> >
> > where is the git tree now ?  i tried git://oss.sgi.com/xfs-cmds but that
> > seems to be dead now.
>
> http://git.kernel.org/?p=fs/xfs/xfsprogs-dev.git;a=tree for the bleeding
> edge development tree.

ok, so i'll base all my patches on the git trees that are available on 
kernel.org.

the xfs.org wiki talks about git trees on sgi.com, but some of them are old 
and/or moved (like the xfs-cmds one) ...
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Felix Blyakher]

On Feb 24, 2009, at 8:53 AM, Mike Frysinger wrote:

> the xfs.org wiki talks about git trees on sgi.com,

Yes, they're still there.

> but some of them are old
> and/or moved (like the xfs-cmds one) ...

xfs-cmds was split into separate repos for xfsprogs, xfsdump,
and dmapi. And that info is on xfs.org. Here is the excerpt
from the following page:

http://www.xfs.org/index.php/Getting_the_latest_source_code

XFS user space tools

     * xfsprogs

$ git clone git://oss.sgi.com/xfs/cmds/xfsprogs

XFS dump

     * xfsdump

$ git clone git://oss.sgi.com/xfs/cmds/xfsdump

XFS tests

     * xfstests

$ git clone git://oss.sgi.com/xfs/cmds/xfstests

DMAPI user space tools

     * dmapi

$ git clone git://oss.sgi.com/xfs/cmds/dmapi


At times though the repos on kernel.org could be ahead of sgi ones.

Felix

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 1038 bytes --]

On Tuesday 24 February 2009 10:14:13 Felix Blyakher wrote:
> On Feb 24, 2009, at 8:53 AM, Mike Frysinger wrote:
> > the xfs.org wiki talks about git trees on sgi.com,
>
> Yes, they're still there.
>
> > but some of them are old
> > and/or moved (like the xfs-cmds one) ...
>
> xfs-cmds was split into separate repos for xfsprogs, xfsdump,
> and dmapi. And that info is on xfs.org.

but acl/attr have not.  distros care about those packages as well.

> Here is the excerpt from the following page:

yes, i was reading the page.  i was also pointing out the broken link to the 
xfs-cmds repo (which is after everything you quoted) and that that repo seems 
to be dead now.  which means there is no up-to-date place for acl/attr on that 
page.

> At times though the repos on kernel.org could be ahead of sgi ones.

well if people are going to try to help in development, the kernel.org trees 
would be good to mention on that page as well with a note as to which tree is 
preferred (sgi.com or kernel.org).
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Tue, Feb 24, 2009 at 10:37:49AM -0500, Mike Frysinger wrote:
> On Tuesday 24 February 2009 10:14:13 Felix Blyakher wrote:
> > On Feb 24, 2009, at 8:53 AM, Mike Frysinger wrote:
> > > the xfs.org wiki talks about git trees on sgi.com,
> >
> > Yes, they're still there.
> >
> > > but some of them are old
> > > and/or moved (like the xfs-cmds one) ...
> >
> > xfs-cmds was split into separate repos for xfsprogs, xfsdump,
> > and dmapi. And that info is on xfs.org.
> 
> but acl/attr have not.  distros care about those packages as well.

Andreas who has done most of the maintaince already is taking these over
formally, so they won't be released with the xfs tools anymore.  I've
put him on Cc so he can say when he expects to clear the backlog.

> > Here is the excerpt from the following page:
> 
> yes, i was reading the page.  i was also pointing out the broken link to the 
> xfs-cmds repo (which is after everything you quoted) and that that repo seems 
> to be dead now.  which means there is no up-to-date place for acl/attr on that 
> page.

Right now the most uptodate acl packages are the on on kernel.org, but
they will move (probably still on kernel.org, but not under fs/xfs)

> > At times though the repos on kernel.org could be ahead of sgi ones.
> 
> well if people are going to try to help in development, the kernel.org trees 
> would be good to mention on that page as well with a note as to which tree is 
> preferred (sgi.com or kernel.org).

I'll update the wikis to bring it uptodate.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Tuesday, 24 February 2009 19:46:24 Christoph Hellwig wrote:
> On Tue, Feb 24, 2009 at 10:37:49AM -0500, Mike Frysinger wrote:
> > but acl/attr have not.  distros care about those packages as well.
>
> Andreas who has done most of the maintaince already is taking these over
> formally, so they won't be released with the xfs tools anymore.  I've
> put him on Cc so he can say when he expects to clear the backlog.

I think I have caught up with the backlog by now in my current trees:

  http://git.kernel.org/?p=linux/kernel/git/agruen/attr.git
  http://git.kernel.org/?p=linux/kernel/git/agruen/acl.git

The repos are based on Christoph's initial git import, with all additional 
fixes added that I'm aware of. Please let me know if anything is missing.

I expect that those repositories will move from where they are right now to 
their permanent new location soon, so please stay tuned ;-)

Thanks,
Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 1521 bytes --]

On Tuesday 24 February 2009 17:22:48 Andreas Gruenbacher wrote:
> On Tuesday, 24 February 2009 19:46:24 Christoph Hellwig wrote:
> > On Tue, Feb 24, 2009 at 10:37:49AM -0500, Mike Frysinger wrote:
> > > but acl/attr have not.  distros care about those packages as well.
> >
> > Andreas who has done most of the maintaince already is taking these over
> > formally, so they won't be released with the xfs tools anymore.  I've
> > put him on Cc so he can say when he expects to clear the backlog.
>
> I think I have caught up with the backlog by now in my current trees:
>
>   http://git.kernel.org/?p=linux/kernel/git/agruen/attr.git
>   http://git.kernel.org/?p=linux/kernel/git/agruen/acl.git
>
> The repos are based on Christoph's initial git import, with all additional
> fixes added that I'm aware of. Please let me know if anything is missing.
>
> I expect that those repositories will move from where they are right now to
> their permanent new location soon, so please stay tuned ;-)

is this mailing list still going to be used for acl/attr ?

here are the patches i have for acl.git:
http://sources.gentoo.org/sys-apps/acl/files/acl-2.2.45-libtool.patch
http://sources.gentoo.org/sys-apps/acl/files/acl-2.2.45-linguas.patch

and for attr.git:
http://sources.gentoo.org/sys-apps/attr/files/attr-2.4.39-gettext.patch
http://sources.gentoo.org/sys-apps/attr/files/attr-2.4.43-linguas.patch

hopefully they should be self explanatory ... otherwise, feel free to ask of 
course
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Wednesday, 25 February 2009 0:45:25 Mike Frysinger wrote:
> is this mailing list still going to be used for acl/attr ?

I would like to keep the discussion here until the packages have found a final 
new location, if SGI won't mind.

> here are the patches i have for acl.git:
> http://sources.gentoo.org/sys-apps/acl/files/acl-2.2.45-libtool.patch

Added.

> http://sources.gentoo.org/sys-apps/acl/files/acl-2.2.45-linguas.patch

Added.

> and for attr.git:
> http://sources.gentoo.org/sys-apps/attr/files/attr-2.4.39-gettext.patch

This functionality already exists (in both the acl and attr packages).

> http://sources.gentoo.org/sys-apps/attr/files/attr-2.4.43-linguas.patch

Added.

Thanks, Mike!

Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

On Wednesday 25 February 2009 19:26:14 Andreas Gruenbacher wrote:
> On Wednesday, 25 February 2009 0:45:25 Mike Frysinger wrote:
> > and for attr.git:
> > http://sources.gentoo.org/sys-apps/attr/files/attr-2.4.39-gettext.patch
>
> This functionality already exists (in both the acl and attr packages).

was this in the last release (2.4.43) ?  either way, can you highlight the 
code you're referring to so there's no confusion on my part ;)
-mike

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Thursday 26 February 2009 02:03:29 Mike Frysinger wrote:
> On Wednesday 25 February 2009 19:26:14 Andreas Gruenbacher wrote:
> > On Wednesday, 25 February 2009 0:45:25 Mike Frysinger wrote:
> > > and for attr.git:
> > > http://sources.gentoo.org/sys-apps/attr/files/attr-2.4.39-gettext.patch
> >
> > This functionality already exists (in both the acl and attr packages).
>
> was this in the last release (2.4.43) ?  either way, can you highlight the
> code you're referring to so there's no confusion on my part ;)

Hmm ... so there code that this patch adds to include/gettext.h already exists 
in include/config.h.in, but ENABLE_GETTEXT isn't being defined anywhere. So 
this part of your patch still seems to be needed, in both the attr and acl 
packages.

When I add it, I get this far:

	$ make aclocal.m4
	$ autoconf
	configure:3493: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

It turns out that aclocal.m4 is created with only the macros in the m4/ 
directory, and AC_PROG_LIBTOOL is not among them; this can be checked with:

	$ aclocal --acdir=m4 --verbose

This would usually be fixed by including the macros in m4/ in addition, but 
then I run into the next problem:

	$ aclocal -I m4
	$ autoconf
	[...]
	configure: error: cannot run /bin/sh ./config.sub

As per one of the libtool info pages,

> In order to use libtool, you need to include the following files with
> your package:
>
> `config.guess'
>      Attempt to guess a canonical system name.
>
> `config.sub'
>      Canonical system name validation subroutine script.
>
> `install-sh'
>      BSD-compatible `install' replacement script.
>
> `ltmain.sh'
>      A generic script implementing basic libtool functionality.

after adding config.guess, config.sub from automake, and ltmain.sh from 
libtool (we already have our own install-sh), the package builds again.

I'm attaching a diff relative to the current repo excluding config.guess, 
config.sub, and ltmain.sh which should be on your systems from automake and 
libtool already.

This is quite insane. Is there a more reasonable way?

Thanks,
Andreas

[-- Attachment #2: libtool-and-gettext-fixes.diff --]
[-- Type: text/x-patch, Size: 1202 bytes --]

diff --git a/.gitignore b/.gitignore
index a4d8b60..6391bdc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -25,3 +25,4 @@ attr-*.tar.gz
 *.o
 /po/attr.pot
 /setfattr/setfattr
+/libtool
diff --git a/Makefile b/Makefile
index 7d2faad..e42a371 100644
--- a/Makefile
+++ b/Makefile
@@ -11,6 +11,7 @@ endif
 
 CONFIGURE = configure include/builddefs include/config.h
 LSRCFILES = configure configure.in aclocal.m4 Makepkgs install-sh exports \
+	config.sub config.guess ltmain.sh \
 	README VERSION
 
 LDIRT = config.log .dep config.status config.cache confdefs.h conftest* \
@@ -63,7 +64,7 @@ include/config.h: include/builddefs
 	fi
 
 aclocal.m4::
-	aclocal --acdir=`pwd`/m4 --output=$@
+	aclocal -I m4
 
 install: default $(addsuffix -install,$(SUBDIRS))
 	$(INSTALL) -m 755 -d $(PKG_DOC_DIR)
diff --git a/m4/package_utilies.m4 b/m4/package_utilies.m4
index 6569e3b..38d623c 100644
--- a/m4/package_utilies.m4
+++ b/m4/package_utilies.m4
@@ -100,6 +100,7 @@ AC_DEFUN([AC_PACKAGE_UTILITIES],
         xgettext=$XGETTEXT
         AC_SUBST(xgettext)
         AC_PACKAGE_NEED_UTILITY($1, "$xgettext", xgettext, gettext)
+	AC_DEFINE([ENABLE_GETTEXT], 1, [enable gettext])
     fi
 
     if test -z "$RPM"; then

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

On Thursday 26 February 2009 07:23:08 Andreas Gruenbacher wrote:
> On Thursday 26 February 2009 02:03:29 Mike Frysinger wrote:
> > On Wednesday 25 February 2009 19:26:14 Andreas Gruenbacher wrote:
> > > On Wednesday, 25 February 2009 0:45:25 Mike Frysinger wrote:
> > > > and for attr.git:
> > > > http://sources.gentoo.org/sys-apps/attr/files/attr-2.4.39-gettext.pat
> > > >ch
> > >
> > > This functionality already exists (in both the acl and attr packages).
> >
> > was this in the last release (2.4.43) ?  either way, can you highlight
> > the code you're referring to so there's no confusion on my part ;)
>
> Hmm ... so there code that this patch adds to include/gettext.h already
> exists in include/config.h.in, but ENABLE_GETTEXT isn't being defined
> anywhere. So this part of your patch still seems to be needed, in both the
> attr and acl packages.
>
> When I add it, I get this far:
>
> 	$ make aclocal.m4
> 	$ autoconf
> 	configure:3493: error: possibly undefined macro: AC_PROG_LIBTOOL
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
>
> It turns out that aclocal.m4 is created with only the macros in the m4/
> directory, and AC_PROG_LIBTOOL is not among them; this can be checked with:
>
> 	$ aclocal --acdir=m4 --verbose
>
> This would usually be fixed by including the macros in m4/ in addition, but
> then I run into the next problem:
>
> 	$ aclocal -I m4
> 	$ autoconf
> 	[...]
> 	configure: error: cannot run /bin/sh ./config.sub
>
> As per one of the libtool info pages,
>
> > In order to use libtool, you need to include the following files with
> > your package:
> >
> > `config.guess'
> >      Attempt to guess a canonical system name.
> >
> > `config.sub'
> >      Canonical system name validation subroutine script.
> >
> > `install-sh'
> >      BSD-compatible `install' replacement script.
> >
> > `ltmain.sh'
> >      A generic script implementing basic libtool functionality.
>
> after adding config.guess, config.sub from automake, and ltmain.sh from
> libtool (we already have our own install-sh), the package builds again.
>
> I'm attaching a diff relative to the current repo excluding config.guess,
> config.sub, and ltmain.sh which should be on your systems from automake and
> libtool already.
>
> This is quite insane. Is there a more reasonable way?

yes.  i dont know why the xfs progs have been packaging these autogenerated 
files by themselves.

- remove aclocal.m4 from git
- run `aclocal -I m4`
- run `libtoolize -c -f`
- run `autoconf`
- copy the remaining files libtool wanted (normally created by automake, but 
acl isnt using automake, so we cant use it to copy the files for us)
-mike

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Thursday, 26 February 2009 16:17:28 Mike Frysinger wrote:
> yes.  i dont know why the xfs progs have been packaging these autogenerated
> files by themselves.
>
> - remove aclocal.m4 from git
> - run `aclocal -I m4`
> - run `libtoolize -c -f`
> - run `autoconf`

You mean this should become the normal build process?

I was actually more thinking along the lines of reducing build dependencies by 
adding a few more generated files like ./configure ...

> - copy the remaining files libtool wanted (normally created by automake,
> but acl isnt using automake, so we cant use it to copy the files for us)

Thanks,
Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

On Thursday 26 February 2009 12:17:02 Andreas Gruenbacher wrote:
> On Thursday, 26 February 2009 16:17:28 Mike Frysinger wrote:
> > yes.  i dont know why the xfs progs have been packaging these
> > autogenerated files by themselves.
> >
> > - remove aclocal.m4 from git
> > - run `aclocal -I m4`
> > - run `libtoolize -c -f`
> > - run `autoconf`
>
> You mean this should become the normal build process?
>
> I was actually more thinking along the lines of reducing build dependencies
> by adding a few more generated files like ./configure ...

no, this is the process for going from live git to a dist tarball.  people who 
download tarballs should never need autotools installed.  people who build 
from live scms should.
-mike

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Tue, Feb 24, 2009 at 11:22:48PM +0100, Andreas Gruenbacher wrote:
> On Tuesday, 24 February 2009 19:46:24 Christoph Hellwig wrote:
> > On Tue, Feb 24, 2009 at 10:37:49AM -0500, Mike Frysinger wrote:
> > > but acl/attr have not.  distros care about those packages as well.
> >
> > Andreas who has done most of the maintaince already is taking these over
> > formally, so they won't be released with the xfs tools anymore.  I've
> > put him on Cc so he can say when he expects to clear the backlog.
> 
> I think I have caught up with the backlog by now in my current trees:
> 
>   http://git.kernel.org/?p=linux/kernel/git/agruen/attr.git
>   http://git.kernel.org/?p=linux/kernel/git/agruen/acl.git
> 
> The repos are based on Christoph's initial git import, with all additional 
> fixes added that I'm aware of. Please let me know if anything is missing.

Do you plan to take over nfs4acl, too?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Greg Banks]

Andreas Gruenbacher wrote:
> On Thursday, 26 February 2009 16:17:28 Mike Frysinger wrote:
>   
>> yes.  i dont know why the xfs progs have been packaging these autogenerated
>> files by themselves.
>>
>> - remove aclocal.m4 from git
>> - run `aclocal -I m4`
>> - run `libtoolize -c -f`
>> - run `autoconf`
>>     
>
>   

Some packages provide a shell script called autogen.sh which automates
all those tedious autotools steps.  The Gnome autogen.sh is fairly
general and does things like check for autotools versions and work out
dynamically which tools to run.

http://svn.gnome.org/viewvc/gnome-common/trunk/autogen.sh?revision=3902&view=markup
http://svn.gnome.org/viewvc/gnome-common/trunk/macros2/gnome-autogen.sh?revision=3913&view=markup

You don't need all that of course, you could get away with a 5-line
shell script.  As long as you call it "autogen.sh" people should know
what to do.

> You mean this should become the normal build process?
>
> I was actually more thinking along the lines of reducing build dependencies by 
> adding a few more generated files like ./configure ...
>
>   
Not in a version control system.  Otherwise developers who do run
autoconf, using a different version of autoconf from you, will get an
enormous spurious diff in the configure script which they have to decide
whether to ignore or not.

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Friday, 27 February 2009 8:22:59 Greg Banks wrote:
> Andreas Gruenbacher wrote:
> > On Thursday, 26 February 2009 16:17:28 Mike Frysinger wrote:
> >> yes.  i dont know why the xfs progs have been packaging these
> >> autogenerated files by themselves.
> >>
> >> - remove aclocal.m4 from git
> >> - run `aclocal -I m4`
> >> - run `libtoolize -c -f`
> >> - run `autoconf`
>
> Some packages provide a shell script called autogen.sh which automates
> all those tedious autotools steps.  The Gnome autogen.sh is fairly
> general and does things like check for autotools versions and work out
> dynamically which tools to run.
>
> http://svn.gnome.org/viewvc/gnome-common/trunk/autogen.sh?revision=3902&vie
>w=markup
> http://svn.gnome.org/viewvc/gnome-common/trunk/macros2/gnome-autogen.sh?rev
>ision=3913&view=markup
>
> You don't need all that of course, you could get away with a 5-line
> shell script.  As long as you call it "autogen.sh" people should know
> what to do.
>
> > You mean this should become the normal build process?
> >
> > I was actually more thinking along the lines of reducing build
> > dependencies by adding a few more generated files like ./configure ...
>
> Not in a version control system.  Otherwise developers who do run
> autoconf, using a different version of autoconf from you, will get an
> enormous spurious diff in the configure script which they have to decide
> whether to ignore or not.

Of course, the classic way is to keep all the generated files out of the 
repository. On the other hand, if we added all the generated files to the 
repository, all that would be needed would be creating a new release would be 
creating a tag and making a tarball. Have a look at cgit: if configured that 
way, the web interface offers to download any tagged version as a tarball. 
Those tarballs are generated on the fly (e.g., 
http://git.savannah.gnu.org/cgit/).

Jumping between different versions of the auto* tools would become quite ugly, 
and we would have to avoid jumping between versions. So maybe that's more 
trouble than it would be worth.

Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Thursday, 26 February 2009 16:17:28 Mike Frysinger wrote:
> [...] i dont know why the xfs progs have been packaging these autogenerated
> files by themselves.
>
> - remove aclocal.m4 from git
> - run `aclocal -I m4`
> - run `libtoolize -c -f`
> - run `autoconf`

Okay, I've done that now in the configure Makefile target. This is an 
improvement we definitely want, independent of whether or not we end up 
shipping generated files.

Thanks,
Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Friday, 27 February 2009 0:03:00 Christoph Hellwig wrote:
> Do you plan to take over nfs4acl, too?

I can sure copy the repository over from you if that is any help. How that 
project will proceed is still unclear though, so don't expect a lot to happen 
there anytime soon.

Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Eric Sandeen]

Andreas Gruenbacher wrote:
> On Friday, 27 February 2009 0:03:00 Christoph Hellwig wrote:
>> Do you plan to take over nfs4acl, too?
> 
> I can sure copy the repository over from you if that is any help. How that 
> project will proceed is still unclear though, so don't expect a lot to happen 
> there anytime soon.
> 
> Andreas

I'd check in w/ Greg on that too, maybe?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Greg Banks]

Andreas Gruenbacher wrote:
> On Friday, 27 February 2009 8:22:59 Greg Banks wrote:
>   
>> Andreas Gruenbacher wrote:
>>     
>>> On Thursday, 26 February 2009 16:17:28 Mike Frysinger wrote:
>>>       
>>>> yes.  i dont know why the xfs progs have been packaging these
>>>> autogenerated files by themselves.
>>>>
>>>> - remove aclocal.m4 from git
>>>> - run `aclocal -I m4`
>>>> - run `libtoolize -c -f`
>>>> - run `autoconf`
>>>>         
>> Some packages provide a shell script called autogen.sh which automates
>> all those tedious autotools steps.  The Gnome autogen.sh is fairly
>> general and does things like check for autotools versions and work out
>> dynamically which tools to run.
>>
>> http://svn.gnome.org/viewvc/gnome-common/trunk/autogen.sh?revision=3902&vie
>> w=markup
>> http://svn.gnome.org/viewvc/gnome-common/trunk/macros2/gnome-autogen.sh?rev
>> ision=3913&view=markup
>>
>> You don't need all that of course, you could get away with a 5-line
>> shell script.  As long as you call it "autogen.sh" people should know
>> what to do.
>>
>>     
>>> You mean this should become the normal build process?
>>>
>>> I was actually more thinking along the lines of reducing build
>>> dependencies by adding a few more generated files like ./configure ...
>>>       
>> Not in a version control system.  Otherwise developers who do run
>> autoconf, using a different version of autoconf from you, will get an
>> enormous spurious diff in the configure script which they have to decide
>> whether to ignore or not.
>>     
>
> Of course, the classic way is to keep all the generated files out of the 
> repository. On the other hand, if we added all the generated files to the 
> repository, all that would be needed would be creating a new release would be 
> creating a tag and making a tarball. 
If the point here is to reduce the workload and potential errors
involved in making a release, you could add a release: target to the
Makefile to do the release procedure.  That target only needs to work
for the maintainer, so it's relatively easy.  You could do the stored
version bump, the tagging, the autotools futzing, and release tarball
building in there.

> Have a look at cgit: if configured that 
> way, the web interface offers to download any tagged version as a tarball. 
> Those tarballs are generated on the fly (e.g., 
> http://git.savannah.gnu.org/cgit/).
>   
Oh, now I see where the idea of checking in generated files comes from :-)
> Jumping between different versions of the auto* tools would become quite ugly, 
>   
Absolutely, you want to avoid that.  But conversely you can't rely on
everybody who ever needs to change configure.ac having exactly the same
version of autoconf as the maintainer.

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Greg Banks]

Eric Sandeen wrote:
> Andreas Gruenbacher wrote:
>   
>> On Friday, 27 February 2009 0:03:00 Christoph Hellwig wrote:
>>     
>>> Do you plan to take over nfs4acl, too?
>>>       
>> I can sure copy the repository over from you if that is any help. How that 
>> project will proceed is still unclear though, so don't expect a lot to happen 
>> there anytime soon.
>>
>> Andreas
>>     
>
> I'd check in w/ Greg on that too, maybe?
>
>
>   
I think the best thing for nfs4acl is for there to be repo owned by
Andreas and adjacent to the attr and acl ones.

I'd also like eventually to see a sensible and unified nfs4acl kernel
repo so we can fix up the mess that is the current  crop of nfs4acl
kernel trees on oss.sgi.com.  For various reasons I'd prefer to see that
on kernel.org or linux-nfs.org rather than oss.sgi.com.  However I doubt
I'll have any chance to do anything on that in the next few weeks.

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 558 bytes --]

On Saturday 28 February 2009 20:31:01 Greg Banks wrote:
> Andreas Gruenbacher wrote:
> > Jumping between different versions of the auto* tools would become quite
> > ugly,
>
> Absolutely, you want to avoid that.  But conversely you can't rely on
> everybody who ever needs to change configure.ac having exactly the same
> version of autoconf as the maintainer.

that isnt to say we should attempt to support every random version out there.  
if people want to make with autotools, it's reasonable to require them to have 
recent versions.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Saturday, 28 February 2009 23:27:28 Eric Sandeen wrote:
> Andreas Gruenbacher wrote:
> > On Friday, 27 February 2009 0:03:00 Christoph Hellwig wrote:
> >> Do you plan to take over nfs4acl, too?
> >
> > I can sure copy the repository over from you if that is any help. How
> > that project will proceed is still unclear though, so don't expect a lot
> > to happen there anytime soon.
> >
> > Andreas
>
> I'd check in w/ Greg on that too, maybe?

Yes, makes sense. I've copied Christoph's tree over and set up permissions; 
you should have access now.

Greg doesn't have a kernel.org account yet, so I can't give him access at the 
moment.

  git://git.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git
  ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git

Would you like write access to the attr.git and acl.git trees as well?

Thanks,
Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Sun, Mar 01, 2009 at 12:31:01PM +1100, Greg Banks wrote:
> If the point here is to reduce the workload and potential errors
> involved in making a release, you could add a release: target to the
> Makefile to do the release procedure.  That target only needs to work
> for the maintainer, so it's relatively easy.  You could do the stored
> version bump, the tagging, the autotools futzing, and release tarball
> building in there.

The xfs tools (and acl/attr which use the same buildsystem) have a
Makepkgs script that's supposed to do this with some help from the
built system.

I'm not sure we should add generating the tags and updating doc/CHANGES
to it, but everything else is automated iff we actually use it. 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Sun, Mar 01, 2009 at 06:23:09PM +0100, Andreas Gruenbacher wrote:
> Yes, makes sense. I've copied Christoph's tree over and set up permissions; 
> you should have access now.
> 
> Greg doesn't have a kernel.org account yet, so I can't give him access at the 
> moment.
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git
> 
> Would you like write access to the attr.git and acl.git trees as well?

Greg or me?  Don't think I want to do too much on it.  I'll just bounce
you whatever build system updates seem like fitting for acl/attr too.
Still a few I need to send you.

But Nathan Scott might want it as he wants to keep the debian packaging
in the upstream git, and I suspect acl/attr aren't different from the
xfs tools in that respect.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Fri, Feb 27, 2009 at 06:35:30PM +0100, Andreas Gruenbacher wrote:
> Okay, I've done that now in the configure Makefile target. This is an 
> improvement we definitely want, independent of whether or not we end up 
> shipping generated files.

I've tried to port the patch you checked into xfsprogs (see below for
the diff), but it fails to build for me.  Any idea what might have
gone wrong?

diff --git a/Makefile b/Makefile
index 133e496..4b61e41 100644
--- a/Makefile
+++ b/Makefile
@@ -12,8 +12,9 @@ endif
 CONFIGURE = configure include/builddefs include/platform_defs.h
 LSRCFILES = configure configure.in Makepkgs aclocal.m4 install-sh README VERSION
 
-LDIRT = config.log .dep config.status config.cache confdefs.h conftest* \
-	Logs/* built .census install.* install-dev.* *.gz
+LDIRT = config.log config.status config.cache config.guess config.sub \
+	confdefs.h ltmain.sh libtool built .census \
+	Logs/* conftest* install.* install-dev.* *.dep *.gz
 
 LIB_SUBDIRS = libxfs libxlog libxcmd libhandle libdisk
 TOOL_SUBDIRS = copy db estimate fsck fsr growfs io logprint mkfs quota \
@@ -21,7 +22,7 @@ TOOL_SUBDIRS = copy db estimate fsck fsr growfs io logprint mkfs quota \
 
 SUBDIRS = include $(LIB_SUBDIRS) $(TOOL_SUBDIRS)
 
-default: include/builddefs include/platform_defs.h
+default: configure include/builddefs include/platform_defs.h
 ifeq ($(HAVE_BUILDDEFS), no)
 	$(MAKE) -C . $@
 else
@@ -46,6 +47,8 @@ clean:	# if configure hasn't run, nothing to clean
 endif
 
 configure include/builddefs:
+	libtoolize -c -f
+	aclocal -I m4
 	autoconf
 	./configure \
 		--prefix=/ \
@@ -68,9 +71,6 @@ include/platform_defs.h: include/builddefs
 		$(MAKE) $(AM_MAKEFLAGS) include/builddefs; \
 	fi
 
-aclocal.m4::
-	aclocal --acdir=`pwd`/m4 --output=$@
-
 install: default $(addsuffix -install,$(SUBDIRS))
 	$(INSTALL) -m 755 -d $(PKG_DOC_DIR)
 	$(INSTALL) -m 644 README $(PKG_DOC_DIR)
diff --git a/configure.in b/configure.in
index 4e4e50c..531d7d0 100644
--- a/configure.in
+++ b/configure.in
@@ -1,6 +1,9 @@
 AC_INIT(include/libxfs.h)
+AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_HEADER(include/platform_defs.h)
 
+AC_PROG_LIBTOOL
+
 AC_ARG_ENABLE(shared,
 [ --enable-shared=[yes/no] Enable use of shared libraries [default=yes]],,
 	enable_shared=yes)

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Wednesday, 4 March 2009 18:27:27 Christoph Hellwig wrote:
> I've tried to port the patch you checked into xfsprogs (see below for
> the diff), but it fails to build for me.  Any idea what might have
> gone wrong?

git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git is missing the following 
commit from ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/acl.git:

  commit 8de7788c29d2656f8d52d98327a80e4dfd1e3898
  Author: Barry Naujok <bnaujok@sgi.com>
  Date:   Tue Jan 23 14:51:14 2007 +0000

    Fix cross-compile issues with libtool and compiler.

    This is equivalent to commit de7b3f6 from Barry Naujok <bnaujok@sgi.com>
    in the acl package, and part of the Gentoo package, as pointed out by
    Mike Frysinger <vapier@gentoo.org>.

    Signed-off-by: Andreas Gruenbacher <agruen@suse.de>

While looking into this, I noticed that the attr and acl packages were calling 
AC_PROG_LIBTOOL both in configure.in and m4/package_utilies.m4. I have 
removed the redundant call from m4/package_utilies.m4 now.

Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Sunday 08 March 2009 14:09:28 Andreas Gruenbacher wrote:
> On Wednesday, 4 March 2009 18:27:27 Christoph Hellwig wrote:
> > I've tried to port the patch you checked into xfsprogs (see below for
> > the diff), but it fails to build for me.  Any idea what might have
> > gone wrong?
>
> git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git is missing the
> following commit from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/acl.git:
>
>   commit 8de7788c29d2656f8d52d98327a80e4dfd1e3898
>   Author: Barry Naujok <bnaujok@sgi.com>
>   Date:   Tue Jan 23 14:51:14 2007 +0000
>
>     Fix cross-compile issues with libtool and compiler.
>
>     This is equivalent to commit de7b3f6 from Barry Naujok
> <bnaujok@sgi.com> in the acl package, and part of the Gentoo package, as
> pointed out by Mike Frysinger <vapier@gentoo.org>.
>
>     Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
>
> While looking into this, I noticed that the attr and acl packages were
> calling AC_PROG_LIBTOOL both in configure.in and m4/package_utilies.m4. I
> have removed the redundant call from m4/package_utilies.m4 now.

As it turns out, I was running into more trouble with libtoolize from libtool 
2.2.6. See this commit in attr.git:

  commit 604290f79a199eb0c73a0cd05a473e1801a00673
  Author: Andreas Gruenbacher <agruen@suse.de>
  Date:   Tue Mar 10 17:00:35 2009 +0100

    More libtoolize fixes

    Recent versions of libtool behave slightly differently, which causes some
    breakage in how libtoolize was used here.  Make sure that libtoolize adds
    the auxiliary files (config.guess and config.sub).

    Move install-sh into include/ so that libtoolize does not destroy it.

    Split up the ``make clean'' and ``make distclean'' targets: the former
    removes all files generated during a build.  The latter removes all
    files generated by libtoolize, autoconf, and configure as well.

    Signed-off-by: Andreas Gruenbacher <agruen@suse.de>

With these changes, the build/*.src.tar.gz tarball should now build properly 
without depending on the version of libtool on the system with:

	./configure
	make
	make install

(The acl.git repository has the equivalent changes.)

Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Sun, Mar 08, 2009 at 02:09:28PM +0100, Andreas Gruenbacher wrote:
> On Wednesday, 4 March 2009 18:27:27 Christoph Hellwig wrote:
> > I've tried to port the patch you checked into xfsprogs (see below for
> > the diff), but it fails to build for me.  Any idea what might have
> > gone wrong?
> 
> git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git is missing the following 
> commit from ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/acl.git:
> 
>   commit 8de7788c29d2656f8d52d98327a80e4dfd1e3898
>   Author: Barry Naujok <bnaujok@sgi.com>
>   Date:   Tue Jan 23 14:51:14 2007 +0000
> 
>     Fix cross-compile issues with libtool and compiler.
> 
>     This is equivalent to commit de7b3f6 from Barry Naujok <bnaujok@sgi.com>
>     in the acl package, and part of the Gentoo package, as pointed out by
>     Mike Frysinger <vapier@gentoo.org>.
> 
>     Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
> 
> While looking into this, I noticed that the attr and acl packages were calling 

Thank, I've pushed this patch to the xfsprogs, xfsdump and dmapi -dev
repositories.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Tue, Mar 10, 2009 at 05:41:06PM +0100, Andreas Gruenbacher wrote:
> As it turns out, I was running into more trouble with libtoolize from libtool 
> 2.2.6. See this commit in attr.git:
> 
>   commit 604290f79a199eb0c73a0cd05a473e1801a00673
>   Author: Andreas Gruenbacher <agruen@suse.de>
>   Date:   Tue Mar 10 17:00:35 2009 +0100
> 
>     More libtoolize fixes

That patch breaks the commit for me:

hch@brick:~/work/attr$ make
libtoolize -c -i -f
libtoolize: unrecognized option `-i'
Try `libtoolize --help' for more information.
make: *** [include/builddefs] Error 1


This is on debian -testing with libtool 1.5.26

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 807 bytes --]

On Monday 16 March 2009 03:05:50 Christoph Hellwig wrote:
> On Tue, Mar 10, 2009 at 05:41:06PM +0100, Andreas Gruenbacher wrote:
> > As it turns out, I was running into more trouble with libtoolize from
> > libtool 2.2.6. See this commit in attr.git:
> >
> >   commit 604290f79a199eb0c73a0cd05a473e1801a00673
> >   Author: Andreas Gruenbacher <agruen@suse.de>
> >   Date:   Tue Mar 10 17:00:35 2009 +0100
> >
> >     More libtoolize fixes
>
> That patch breaks the commit for me:
>
> hch@brick:~/work/attr$ make
> libtoolize -c -i -f
> libtoolize: unrecognized option `-i'
> Try `libtoolize --help' for more information.
> make: *** [include/builddefs] Error 1

-i is new to libtool-2

usually what i do is something like:
args=
libtoolize -n --install 2>/dev/null && args="-i"
libtoolize -c -f $args
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Monday, 16 March 2009 8:31:48 Mike Frysinger wrote:
> usually what i do is something like:
> args=
> libtoolize -n --install 2>/dev/null && args="-i"
> libtoolize -c -f $args

Sigh, the usual GNU utility problem. I've added a compatibility fix to attr 
and acl now. Thanks!

Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Mon, Mar 16, 2009 at 10:53:32AM +0100, Andreas Gruenbacher wrote:
> On Monday, 16 March 2009 8:31:48 Mike Frysinger wrote:
> > usually what i do is something like:
> > args=
> > libtoolize -n --install 2>/dev/null && args="-i"
> > libtoolize -c -f $args
> 
> Sigh, the usual GNU utility problem. I've added a compatibility fix to attr 
> and acl now. Thanks!

Ok.  Can anyone review the cumulated autotools/libtool patch for
xfsprogs below?


Subject: Automake and libtool fixes
From: Andreas Gruenbacher <agruen@suse.de>

Remove aclocal.m4 from the repository and generate it when needed.
Move the AC_PROG_LIBTOOL autoconf macro and use libtoolize according to
the libtool info pages.

Make sure that libtoolize adds the auxiliary files (config.guess and
config.sub).

Move install-sh into include/ so that libtoolize does not destroy it.

Split up the ``make clean'' and ``make distclean'' targets: the former
removes all files generated during a build.  The latter removes all
files generated by libtoolize, autoconf, and configure as well.


Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>


Index: xfsprogs-dev/Makefile
===================================================================
--- xfsprogs-dev.orig/Makefile	2009-03-16 07:57:07.891007993 +0100
+++ xfsprogs-dev/Makefile	2009-03-16 21:58:18.036977931 +0100
@@ -9,11 +9,18 @@ ifeq ($(HAVE_BUILDDEFS), yes)
 include $(TOPDIR)/include/builddefs
 endif
 
-CONFIGURE = configure include/builddefs include/platform_defs.h
-LSRCFILES = configure configure.in Makepkgs aclocal.m4 install-sh README VERSION
+CONFIGURE = \
+	aclocal.m4 \
+	configure config.guess config.sub \
+	ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 \
+	m4/ltversion.m4 m4/lt~obsolete.m4 \
+	include/builddefs include/platform_defs.h
+LSRCFILES = \
+	configure.in Makepkgs install-sh README VERSION \
+	configure aclocal.m4
 
-LDIRT = config.log .dep config.status config.cache confdefs.h conftest* \
-	Logs/* built .census install.* install-dev.* *.gz
+LDIRT = config.log config.status config.cache confdefs.h built .census \
+	Logs/* conftest* install.* install-dev.* *.dep *.gz
 
 LIB_SUBDIRS = libxfs libxlog libxcmd libhandle libdisk
 TOOL_SUBDIRS = copy db estimate fsck fsr growfs io logprint mkfs quota \
@@ -21,7 +28,7 @@ TOOL_SUBDIRS = copy db estimate fsck fsr
 
 SUBDIRS = include $(LIB_SUBDIRS) $(TOOL_SUBDIRS)
 
-default: include/builddefs include/platform_defs.h
+default: configure include/builddefs include/platform_defs.h
 ifeq ($(HAVE_BUILDDEFS), no)
 	$(MAKE) -C . $@
 else
@@ -45,7 +52,15 @@ else
 clean:	# if configure hasn't run, nothing to clean
 endif
 
+# Recent versions of libtool require the -i option for copying auxiliary
+# files (config.sub, config.guess, install-sh, ltmain.sh), while older
+# versions will copy those files anyway, and don't understand -i.
+LIBTOOLIZE_INSTALL = `libtoolize -n -i >/dev/null 2>/dev/null && echo -i`
+
 configure include/builddefs:
+	libtoolize -c $(LIBTOOLIZE_INSTALL) -f
+	cp include/install-sh .
+	aclocal -I m4
 	autoconf
 	./configure \
 		--prefix=/ \
@@ -68,9 +83,6 @@ include/platform_defs.h: include/buildde
 		$(MAKE) $(AM_MAKEFLAGS) include/builddefs; \
 	fi
 
-aclocal.m4::
-	aclocal --acdir=`pwd`/m4 --output=$@
-
 install: default $(addsuffix -install,$(SUBDIRS))
 	$(INSTALL) -m 755 -d $(PKG_DOC_DIR)
 	$(INSTALL) -m 644 README $(PKG_DOC_DIR)
@@ -90,4 +102,5 @@ install-qa: install $(addsuffix -install
 
 realclean distclean: clean
 	rm -f $(LDIRT) $(CONFIGURE)
+	rm -f include/builddefs include/config.h install-sh libtool
 	rm -rf autom4te.cache Logs
Index: xfsprogs-dev/configure.in
===================================================================
--- xfsprogs-dev.orig/configure.in	2009-03-16 07:57:07.898984077 +0100
+++ xfsprogs-dev/configure.in	2009-03-16 21:58:18.036977931 +0100
@@ -1,6 +1,10 @@
 AC_INIT(include/libxfs.h)
+AC_CONFIG_AUX_DIR([.])
+AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_HEADER(include/platform_defs.h)
 
+AC_PROG_LIBTOOL
+
 AC_ARG_ENABLE(shared,
 [ --enable-shared=[yes/no] Enable use of shared libraries [default=yes]],,
 	enable_shared=yes)
Index: xfsprogs-dev/m4/package_utilies.m4
===================================================================
--- xfsprogs-dev.orig/m4/package_utilies.m4	2009-03-16 07:57:07.903978218 +0100
+++ xfsprogs-dev/m4/package_utilies.m4	2009-03-16 07:57:09.538978690 +0100
@@ -32,8 +32,6 @@ AC_DEFUN([AC_PACKAGE_UTILITIES],
     AC_SUBST(make)
     AC_PACKAGE_NEED_UTILITY($1, "$make", make, [GNU make])
 
-    AC_PROG_LIBTOOL
-
     if test -z "$TAR"; then
         AC_PATH_PROG(TAR, tar,, /usr/freeware/bin:/bin:/usr/local/bin:/usr/bin)
     fi
Index: xfsprogs-dev/include/Makefile
===================================================================
--- xfsprogs-dev.orig/include/Makefile	2009-03-16 21:58:09.403978018 +0100
+++ xfsprogs-dev/include/Makefile	2009-03-16 21:58:18.036977931 +0100
@@ -36,8 +36,8 @@ HFILES += $(PKG_PLATFORM).h
 PHFILES = darwin.h freebsd.h irix.h linux.h
 DKHFILES = volume.h fstyp.h dvh.h
 LSRCFILES = $(shell echo $(PHFILES) | sed -e "s/$(PKG_PLATFORM).h//g")
-LSRCFILES += platform_defs.h.in builddefs.in buildmacros buildrules $(DKHFILES)
-LSRCFILES += command.h input.h path.h project.h unaligned.h
+LSRCFILES += platform_defs.h.in builddefs.in buildmacros buildrules install-sh
+LSRCFILES += $(DKHFILES) command.h input.h path.h project.h unaligned.h
 LDIRT = xfs disk
 
 default install: xfs disk
Index: xfsprogs-dev/include/install-sh
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ xfsprogs-dev/include/install-sh	2009-03-16 21:58:18.037978687 +0100
@@ -0,0 +1,349 @@
+#! /bin/sh
+#
+# Copyright (c) 2000-2001 Silicon Graphics, Inc.  All Rights Reserved.
+#
+# This script emulates bsd install and also recognises
+# two environment variables, with the following semantics :-
+#
+# $DIST_MANIFEST - if set, the name of the file to append manifest
+#                  information in the following format:
+#                  File     :  f mode owner group src target
+#                  Directory:  d mode owner group target
+#                  Symlink  :  l linkval target
+#
+# $DIST_ROOT     - if set, prepend to target
+#
+# The sematics of all combinations of these two variables
+# are as follows:
+#
+# $DIST_MANIFEST?  $DIST_ROOT? |   Copy?  Append Manifest?
+# -----------------------------+--------------------------
+#       not set       not set  |    yes        no
+#       not set       set      |    yes        no
+#       set           not set  |    no         yes
+#       set           set      |    yes        yes
+#
+_usage() {
+    echo "Usage: $prog [-o owner] [-g group] [-m mode] -d directory"
+    echo "or     $prog [-D] [-o owner] [-g group] [-m mode] file directory/file"
+    echo "or     $prog [-o owner] [-g group] [-m mode] file [file ...] directory"
+    echo "or     $prog -S file target  (creates \"target\" symlink)"
+    echo "or     $prog -T lt_arg [-o owner] [-g group] [-m mode] libtool.lai directory"
+    echo ""
+    echo "The \$DIST_MANIFEST and \$DIST_ROOT environment variables affect the"
+    echo "behaviour of this command - see comments in the script."
+    echo "The -D flag is only available for the second usage, and causes"
+    echo "the target directory to be created before installing the file."
+    echo ""
+    exit 1
+}
+
+_chown ()
+{
+    _st=255
+    if [ $# -eq 3 ] ; then
+	chown $1:$2 $3
+	_st=$?
+	if [ $_st -ne 0 ] ; then
+	    if [ $REAL_UID != '0' ] ; then
+		if [ ! -f $DIST_ROOT/.chown.quiet ] ; then
+		    echo '==============================================='
+		    echo Ownership of files under ${DIST_ROOT:-/}
+		    echo cannot be changed
+		    echo '==============================================='
+		    if [ -n "$DIST_ROOT" ] ; then
+			touch $DIST_ROOT/.chown.quiet
+		    fi
+		fi
+	       _st=0
+	    fi     
+	fi
+    fi
+
+    return $_st
+}
+
+
+_manifest ()
+{ 
+    echo $* | sed -e 's/\/\//\//g' >>${DIST_MANIFEST:-/dev/null}
+}
+
+prog=`basename $0`
+HERE=`pwd`
+dflag=false
+Dflag=false
+Sflag=false
+Tflag=false
+DIRMODE=755
+FILEMODE=644
+OWNER=`id -u`
+GROUP=`id -g`
+REAL_UID=$OWNER
+
+# default is to install and don't append manifest
+INSTALL=true
+MANIFEST=:
+
+[ -n "$DIST_MANIFEST" -a -z "$DIST_ROOT" ] && INSTALL=false
+[ -n "$DIST_MANIFEST" ] && MANIFEST="_manifest"
+
+[ $# -eq 0 ] && _usage
+
+if $INSTALL
+then
+    CP=cp; LN=ln; MKDIR=mkdir; CHMOD=chmod; CHOWN=_chown
+else
+    CP=true; LN=true; MKDIR=true; CHMOD=true; CHOWN=true
+fi
+
+[ -n "$DIST_ROOT" -a $REAL_UID -ne 0 ] && CHOWN=true
+
+while getopts "Dcm:d:S:o:g:T:" c $*
+do
+   case $c in
+   c)
+	;;
+   g)
+	GROUP=$OPTARG
+	;;
+   o)
+	OWNER=$OPTARG
+	;;
+   m)
+	DIRMODE=`expr $OPTARG`
+	FILEMODE=$DIRMODE
+	;;
+   D) 
+	Dflag=true
+	;;
+   S) 
+	symlink=$OPTARG
+	Sflag=true
+	;;
+   d) 
+	dir=$DIST_ROOT/$OPTARG
+	dflag=true
+	;;
+   T)
+	lt_install=$OPTARG
+	Tflag=true
+	;;
+   *)
+   	_usage
+	;;
+   esac
+done
+
+shift `expr $OPTIND - 1`
+
+status=0
+if $dflag
+then
+    #
+    # first usage
+    #
+    $MKDIR -p $dir 
+    status=$?
+    if [ $status -eq 0 ]
+    then
+	$CHMOD $DIRMODE $dir
+	status=$?
+    fi
+    if [ $status -eq 0 ]
+    then
+	$CHOWN $OWNER $GROUP $dir
+	status=$?
+    fi
+    $MANIFEST d $DIRMODE $OWNER $GROUP ${dir#$DIST_ROOT}
+elif $Sflag
+then
+    #
+    # fourth usage (symlink)
+    #
+    if [ $# -ne 1 ]
+    then
+    	_usage
+    else
+    	target=$DIST_ROOT/$1
+    fi
+    $LN -s -f $symlink $target
+    status=$?
+    $MANIFEST l $symlink ${target#$DIST_ROOT} 
+elif $Tflag
+then
+    #
+    # -T (install libs built by libtool)
+    #
+    if [ $# -ne 2 ]
+    then
+	_usage
+    else
+	libtool_lai=$1
+	# source the libtool variables
+	if [ ! -f $libtool_lai ]
+	then
+		echo "$prog: Unable to find libtool library file $libtool_lai"
+		exit 2
+	fi
+	. ./$libtool_lai
+	target=$DIST_ROOT/$2
+    fi
+    case $lt_install in
+    so_dot_version)
+	# Loop until we find libfoo.so.x.y.z, then break out.
+	for solib in $library_names
+	do
+		# does it have enough parts?  libfoo.so.x.y.z == 5
+		cnt=`echo "$solib" | sed -e 's/\./ /g' | wc -w`
+		if [ $cnt -eq 5 ]
+		then
+			install_name=$target/$solib
+			$CP $solib $install_name
+			status=$?
+			$MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$solib ${install_name#$DIST_ROOT}
+			break
+		fi
+	done
+	;;
+
+    so_*)
+	case $lt_install in
+	so_dot_current)
+		# ln -s libfoo.so.x.y.z to libfoo.so.x
+		from_parts=5  # libfoo.so.x.y.z
+		to_parts=3    # libfoo.so.x
+		;;
+	so_base)
+		# ln -s libfoo.so.x to libfoo.so
+		from_parts=3  # libfoo.so.x
+		to_parts=2    # libfoo.so
+		;;
+	*)
+		echo "$prog: -T $lt_install invalid"
+		exit 2
+		;;
+	esac
+
+	# Loop until we find the names, then break out.
+	for solib in $library_names
+	do
+		# does it have enough parts?
+		cnt=`echo "$solib" | sed -e 's/\./ /g' | wc -w`
+		if [ $cnt -eq $from_parts ]
+		then
+			from_name=$solib
+		elif [ $cnt -eq $to_parts ]
+		then
+			to_name=$solib
+		fi
+
+		if [ -n "$from_name" ] && [ -n "$to_name" ]
+		then
+			install_name=$target/$to_name
+			$LN -s -f $from_name $install_name
+			status=$?
+			$MANIFEST l $from_name ${install_name#$DIST_ROOT}
+			break
+		fi
+	done
+	;;
+    old_lib)
+	install_name=$target/$old_library
+	$CP $old_library $install_name
+	status=$?
+	$MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$old_library ${install_name#$DIST_ROOT}
+	;;
+    *)
+	echo "$prog: -T $lt_install invalid"
+	exit 2
+	;;
+    esac
+
+    case $lt_install in
+    old_lib|so_dot_version)
+	if [ $status -eq 0 ]
+	then
+		$CHMOD $FILEMODE $install_name
+		$CHOWN $OWNER $GROUP $install_name
+	fi
+	;;
+    esac
+
+else
+    list=""
+    dir=""
+    if [ $# -eq 2 ]
+    then
+	#
+	# second usage
+	#
+	f=$1
+	dir=$DIST_ROOT/$2
+	if $Dflag
+	then
+	    mkdir -p `dirname $dir`
+	fi
+	$CP $f $dir
+	status=$?
+	if [ $status -eq 0 ]
+	then 
+	    if [ -f $dir/$f ]
+	    then
+		$CHMOD $FILEMODE $dir/$f
+		status=$?
+		if [ $status -eq 0 ]
+		then
+		    $CHOWN $OWNER $GROUP $dir/$f
+		    status=$?
+		fi
+		$MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$f ${dir#$DIST_ROOT}/$f
+	    else
+		$CHMOD $FILEMODE $dir
+		status=$?
+		if [ $status -eq 0 ]
+		then
+		    $CHOWN $OWNER $GROUP $dir
+		    status=$?
+		fi
+		$MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$dir ${dir#$DIST_ROOT}
+	    fi
+	fi
+    else
+	#
+	# third usage
+	#
+	n=1
+	while [ $# -gt 0 ]
+	do
+	    if [ $# -gt 1 ]
+	    then
+		list="$list $1"
+	    else
+		dir=$DIST_ROOT/$1
+	    fi
+	    shift
+	done
+
+	# echo DIR=$dir list=\"$list\"
+	for f in $list
+	do
+	    $CP $f $dir
+	    status=$?
+	    if [ $status -eq 0 ]
+	    then
+		$CHMOD $FILEMODE $dir/$f
+		status=$?
+		if [ $status -eq 0 ]
+		then
+		    $CHOWN $OWNER $GROUP $dir/$f
+		    status=$?
+		fi
+		$MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$f ${dir#$DIST_ROOT}/$f
+	    fi
+	    [ $status -ne 0 ] && break
+	done
+    fi
+fi
+
+exit $status

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

> +	ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 \
> +	m4/ltversion.m4 m4/lt~obsolete.m4 \

Btw, where do these m4 files come from?  Is this another libtool
version dependency?  I can't find them anywhere for either acl/attr
or the patched xfsprogs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Andreas Gruenbacher]

On Tuesday, 24 March 2009 14:12:49 Christoph Hellwig wrote:
> > +	ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 \
> > +	m4/ltversion.m4 m4/lt~obsolete.m4 \
>
> Btw, where do these m4 files come from?

>From libtool via libtoolize. The AC_PROG_LIBTOOL macro pulls them in AFAICT.

> Is this another libtool version dependency?

It would seem so but the build system simply ignores files in the file list 
that don't exist. This is all rather ugly, but at least the result works...

Andreas 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Tue, Mar 24, 2009 at 07:18:39PM +0100, Andreas Gruenbacher wrote:
> It would seem so but the build system simply ignores files in the file list 
> that don't exist. This is all rather ugly, but at least the result works...

Oh well.  I've now pushed these patches to xfsprogs, xfsdump and dmapi
as authored by you and reviewed by me as they were straight-forward
ports.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

I did some make dist and build the tarball tests with
acl,attr,xfsprogs & co.

We still run libtoolize, aclocal and autoconf when building a clean
tree.  I wonder if we should just get rid of the whole configure target
and require a manual ./configure like most tools?

Nathan, any comments on that from the Debian perspective?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]

On Friday 27 March 2009 12:02:04 Christoph Hellwig wrote:
> I did some make dist and build the tarball tests with
> acl,attr,xfsprogs & co.
>
> We still run libtoolize, aclocal and autoconf when building a clean
> tree.  I wonder if we should just get rid of the whole configure target
> and require a manual ./configure like most tools?

`make dist` should produce a tarball that, when unpacked, people can run:
./configure && make && make install
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [patch] fix parallel build failures in xfsprogs-3.0.0

[Christoph Hellwig]

On Fri, Mar 27, 2009 at 12:30:59PM -0400, Mike Frysinger wrote:
> On Friday 27 March 2009 12:02:04 Christoph Hellwig wrote:
> > I did some make dist and build the tarball tests with
> > acl,attr,xfsprogs & co.
> >
> > We still run libtoolize, aclocal and autoconf when building a clean
> > tree.  I wonder if we should just get rid of the whole configure target
> > and require a manual ./configure like most tools?
> 
> `make dist` should produce a tarball that, when unpacked, people can run:
> ./configure && make && make install

Yes.  The added complication is that the various xfs-cmds derived tools
also run ./configure from a default target make which complicates the
build system.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs