All of lore.kernel.org
 help / color / mirror / Atom feed
* [Ocfs2-devel] Updated Patch for 2.6 Make system
@ 2004-03-02 16:29 John L. Villalovos
  2004-03-02 17:47 ` Manish Singh
  0 siblings, 1 reply; 6+ messages in thread
From: John L. Villalovos @ 2004-03-02 16:29 UTC (permalink / raw)
  To: ocfs2-devel

Fixes an error from the previous patch where I forgot to do NPTL :(

This now compiles with SVN revision 748.

John

Index: configure.in
===================================================================
--- configure.in	(revision 747)
+++ configure.in	(working copy)
@@ -83,6 +83,13 @@
    AC_MSG_ERROR(GCC is required)
  fi

+AC_ARG_ENABLE(kernel-2_6, AC_HELP_STRING([--enable-kernel-2_6], [(BROKEN!) Enable building on Linux kernel version 2.6.x (default=no)]),enable_kernel26=yes,enable_kernel26=no)
+OCFS_KERNEL_2_6=
+if test "x$enable_kernel26" = "xyes"; then
+  OCFS_KERNEL_2_6=yes
+fi
+AC_SUBST(OCFS_KERNEL_2_6)
+
  AC_ARG_ENABLE(debug, [  --enable-debug=[yes/no]         Turn on debugging [default=yes]],,enable_debug=yes)
  OCFS_DEBUG=
  if test "x$enable_debug" = "xyes"; then
@@ -178,6 +185,13 @@
  case "$kversion" in
    2.4.*)
      ;;
+  2.6.*)
+    if test "x$enable_kernel26" = "xyes"; then
+      AC_MSG_NOTICE([Support for kernel version 2.6 is BROKEN at this time!  Your system WILL hang.])
+    else
+      AC_MSG_ERROR([Support for kernel version 2.6 is BROKEN (Your system WILL hang!) at this time.  You must use --enable-kernel-2_6 to get past this point.])
+    fi
+    ;;
    *)
      AC_MSG_ERROR([This module only supports kernel version 2.4.x])
      ;;
@@ -304,6 +318,9 @@
  GCCINC=$gccdir
  AC_SUBST(GCCINC)

+OCFS_BUILD_DIR=`pwd`
+AC_SUBST(OCFS_BUILD_DIR)
+
  AC_OUTPUT([Config.make
  vendor/redhat/ocfs2-2.4.9-e.spec
  vendor/redhat/ocfs2-2.4.18-e.spec
@@ -314,4 +331,5 @@
  vendor/unitedlinux/ocfs2-2.4.21-107.spec
  vendor/unitedlinux/ocfs2-2.4.21-111.spec
  vendor/unitedlinux/ocfs2-2.4.21-138.spec
+src/Makefile-2.6
  ])
Index: Config.make.in
===================================================================
--- Config.make.in	(revision 747)
+++ Config.make.in	(working copy)
@@ -58,5 +58,6 @@
  OCFS_MEMDEBUG = @OCFS_MEMDEBUG@
  OCFS_TRACE = @OCFS_TRACE@
  OCFS_PROCESSOR = @OCFS_PROCESSOR@
+OCFS_KERNEL_2_6 = @OCFS_KERNEL_2_6@

  USE_JOURNAL_CREATE_REPLACEMENT = @USE_JOURNAL_CREATE_REPLACEMENT@
Index: src/Makefile
===================================================================
--- src/Makefile	(revision 747)
+++ src/Makefile	(working copy)
@@ -1,3 +1,11 @@
+# See if we are being included by the 2.6 kernel build system.
+ifneq ($(KERNELRELEASE),)
+# We are being included by the 2.6 kernel build system.  So we will include the
+# 2.6.x Makefile and skip everything else.
+include $(obj)/Makefile-2.6
+else
+# Normal build that is being called locally
+
  TOPDIR = ..

  include $(TOPDIR)/Preamble.make
@@ -2,2 +10,7 @@

+# Preliminary 2.6.x kernel support.  See if we are building for the 2.6.x
+# kernel
+ifndef OCFS_KERNEL_2_6
+# Building for a 2.4.x kernel
+
  WARNINGS = -Wall -Wstrict-prototypes -Wno-format
@@ -196,4 +209,11 @@
  dist-subdircreate:
  	$(TOPDIR)/mkinstalldirs $(DIST_DIR)/inc

+
+else # OCFS_KERNEL_2_6
+# Building for a 2.6.x kernel
+include Makefile-2.6
+endif # OCFS_KERNEL_2_6
+
  include $(TOPDIR)/Postamble.make
+endif # ifneq ($(KERNELRELEASE),)
--- /dev/null	2004-02-23 13:02:56.000000000 -0800
+++ src/Makefile-2.6.in	2004-03-02 14:17:21.207201128 -0800
@@ -0,0 +1,74 @@
+# The 2.6.x kernel makefile
+
+# Global parameter so we know where our stuff is
+OCFS_SRC_DIR	:= @OCFS_BUILD_DIR@/src
+
+# This Makefile has two ways through it.  They are:
+#   1.	We are being included by the local Makefile to do a 2.6 kernel build.
+#	In this method we will call the kernel make system to build our module.
+#	This will cause the kernel make system to call back into our makefile
+#	(2nd way).
+#
+#   2.	We are being included by the kernel make system.  So in this method we
+#	just setup the variables that the make system wants and then the kernel
+#	make system will take care of the build.
+
+ifeq ($(KERNELRELEASE),)
+# 1st method.  Local Makefile is including us.  We will now call the kernel
+# make system to do the build.
+
+KDIR	:= $(KERNELDIR)
+
+all:
+	$(MAKE) -C $(KDIR) V=1 SUBDIRS=$(OCFS_SRC_DIR) modules
+
+else
+# 2nd method.  The kernel make system is including us.  We need to setup the
+# various parameters for the kernel make system and then it will take care of
+# building us.
+
+EXTRA_CFLAGS += -D__ILP32__ -I$(OCFS_SRC_DIR)/inc \
+		-DALLOW_NO_HANDLE_SYNCING -DOCFS_PARANOID_ABORTS \
+		-Wno-format
+
+# FIXME: Need to figure out how to use the stuff from Postamble.make.  In
+# particular the MD5 and Version strings
+EXTRA_CFLAGS +=	-DOCFS_BUILD_DATE=\"y\" -DOCFS_BUILD_MD5=\"z\" \
+		-DOCFS_BUILD_VERSION=\"x\"
+
+# FIXME: Probably should not be doing this
+EXTRA_CFLAGS +=	-Werror
+
+# Defines
+HAVE_NPTL = @HAVE_NPTL@
+OCFS_DEBUG = @OCFS_DEBUG@
+OCFS_LARGEIO = @OCFS_LARGEIO@
+OCFS_AIO = @OCFS_AIO@
+OCFS_MEMDEBUG = @OCFS_MEMDEBUG@
+OCFS_TRACE = @OCFS_TRACE@
+OCFS_PROCESSOR = @OCFS_PROCESSOR@
+OCFS_KERNEL_2_6 = @OCFS_KERNEL_2_6@
+
+# Setup all the extra parameters that might be needed by the build.
+# FIXME: Not sure if we have all the parameters here.
+ifdef OCFS_DEBUG
+EXTRA_CFLAGS += -DDEBUG
+endif
+
+ifdef OCFS_TRACE
+EXTRA_CFLAGS += -DTRACE
+endif
+
+ifdef HAVE_NPTL
+EXTRA_CFLAGS += -DHAVE_NPTL
+endif
+
+# Kernel Module file to produce
+obj-m += ocfs2.o
+
+# list of object files that are used to create our module
+ocfs2-objs := alloc.o divdi3.o hash.o ioctl.o oin.o super.o ver.o \
+              bitmap.o dlm.o heartbeat.o journal.o osb.o symlink.o volcfg.o \
+              dcache.o extmap.o inode.o namei.o proc.o sysfile.o vote.o \
+              dir.o file.o io.o nm.o sem.o util.o
+endif

-------------- next part --------------
Index: configure.in
===================================================================
--- configure.in	(revision 747)
+++ configure.in	(working copy)
@@ -83,6 +83,13 @@
   AC_MSG_ERROR(GCC is required)
 fi
 
+AC_ARG_ENABLE(kernel-2_6, AC_HELP_STRING([--enable-kernel-2_6], [(BROKEN!) Enable building on Linux kernel version 2.6.x (default=no)]),enable_kernel26=yes,enable_kernel26=no)
+OCFS_KERNEL_2_6=
+if test "x$enable_kernel26" = "xyes"; then
+  OCFS_KERNEL_2_6=yes
+fi
+AC_SUBST(OCFS_KERNEL_2_6)
+
 AC_ARG_ENABLE(debug, [  --enable-debug=[yes/no]         Turn on debugging [default=yes]],,enable_debug=yes)
 OCFS_DEBUG=
 if test "x$enable_debug" = "xyes"; then
@@ -178,6 +185,13 @@
 case "$kversion" in
   2.4.*)
     ;;
+  2.6.*)
+    if test "x$enable_kernel26" = "xyes"; then
+      AC_MSG_NOTICE([Support for kernel version 2.6 is BROKEN at this time!  Your system WILL hang.])
+    else
+      AC_MSG_ERROR([Support for kernel version 2.6 is BROKEN (Your system WILL hang!) at this time.  You must use --enable-kernel-2_6 to get past this point.])
+    fi
+    ;;
   *)
     AC_MSG_ERROR([This module only supports kernel version 2.4.x])
     ;;
@@ -304,6 +318,9 @@
 GCCINC=$gccdir
 AC_SUBST(GCCINC)
 
+OCFS_BUILD_DIR=`pwd`
+AC_SUBST(OCFS_BUILD_DIR)
+
 AC_OUTPUT([Config.make
 vendor/redhat/ocfs2-2.4.9-e.spec
 vendor/redhat/ocfs2-2.4.18-e.spec
@@ -314,4 +331,5 @@
 vendor/unitedlinux/ocfs2-2.4.21-107.spec
 vendor/unitedlinux/ocfs2-2.4.21-111.spec
 vendor/unitedlinux/ocfs2-2.4.21-138.spec
+src/Makefile-2.6
 ])
Index: Config.make.in
===================================================================
--- Config.make.in	(revision 747)
+++ Config.make.in	(working copy)
@@ -58,5 +58,6 @@
 OCFS_MEMDEBUG = @OCFS_MEMDEBUG@
 OCFS_TRACE = @OCFS_TRACE@
 OCFS_PROCESSOR = @OCFS_PROCESSOR@
+OCFS_KERNEL_2_6 = @OCFS_KERNEL_2_6@
 
 USE_JOURNAL_CREATE_REPLACEMENT = @USE_JOURNAL_CREATE_REPLACEMENT@
Index: src/Makefile
===================================================================
--- src/Makefile	(revision 747)
+++ src/Makefile	(working copy)
@@ -1,3 +1,11 @@
+# See if we are being included by the 2.6 kernel build system.
+ifneq ($(KERNELRELEASE),)
+# We are being included by the 2.6 kernel build system.  So we will include the
+# 2.6.x Makefile and skip everything else.
+include $(obj)/Makefile-2.6
+else
+# Normal build that is being called locally
+
 TOPDIR = ..
 
 include $(TOPDIR)/Preamble.make
@@ -2,2 +10,7 @@
 
+# Preliminary 2.6.x kernel support.  See if we are building for the 2.6.x
+# kernel
+ifndef OCFS_KERNEL_2_6
+# Building for a 2.4.x kernel
+
 WARNINGS = -Wall -Wstrict-prototypes -Wno-format
@@ -196,4 +209,11 @@
 dist-subdircreate:
 	$(TOPDIR)/mkinstalldirs $(DIST_DIR)/inc
 
+
+else # OCFS_KERNEL_2_6
+# Building for a 2.6.x kernel
+include Makefile-2.6
+endif # OCFS_KERNEL_2_6
+
 include $(TOPDIR)/Postamble.make
+endif # ifneq ($(KERNELRELEASE),)
--- /dev/null	2004-02-23 13:02:56.000000000 -0800
+++ src/Makefile-2.6.in	2004-03-02 14:17:21.207201128 -0800
@@ -0,0 +1,74 @@
+# The 2.6.x kernel makefile
+
+# Global parameter so we know where our stuff is
+OCFS_SRC_DIR	:= @OCFS_BUILD_DIR@/src
+
+# This Makefile has two ways through it.  They are:
+#   1.	We are being included by the local Makefile to do a 2.6 kernel build.
+#	In this method we will call the kernel make system to build our module.
+#	This will cause the kernel make system to call back into our makefile
+#	(2nd way).
+#
+#   2.	We are being included by the kernel make system.  So in this method we
+#	just setup the variables that the make system wants and then the kernel
+#	make system will take care of the build.
+
+ifeq ($(KERNELRELEASE),)
+# 1st method.  Local Makefile is including us.  We will now call the kernel
+# make system to do the build.
+
+KDIR	:= $(KERNELDIR)
+
+all:
+	$(MAKE) -C $(KDIR) V=1 SUBDIRS=$(OCFS_SRC_DIR) modules
+
+else
+# 2nd method.  The kernel make system is including us.  We need to setup the
+# various parameters for the kernel make system and then it will take care of
+# building us.
+
+EXTRA_CFLAGS += -D__ILP32__ -I$(OCFS_SRC_DIR)/inc \
+		-DALLOW_NO_HANDLE_SYNCING -DOCFS_PARANOID_ABORTS \
+		-Wno-format
+
+# FIXME: Need to figure out how to use the stuff from Postamble.make.  In
+# particular the MD5 and Version strings
+EXTRA_CFLAGS +=	-DOCFS_BUILD_DATE=\"y\" -DOCFS_BUILD_MD5=\"z\" \
+		-DOCFS_BUILD_VERSION=\"x\"
+
+# FIXME: Probably should not be doing this
+EXTRA_CFLAGS +=	-Werror
+
+# Defines
+HAVE_NPTL = @HAVE_NPTL@
+OCFS_DEBUG = @OCFS_DEBUG@
+OCFS_LARGEIO = @OCFS_LARGEIO@
+OCFS_AIO = @OCFS_AIO@
+OCFS_MEMDEBUG = @OCFS_MEMDEBUG@
+OCFS_TRACE = @OCFS_TRACE@
+OCFS_PROCESSOR = @OCFS_PROCESSOR@
+OCFS_KERNEL_2_6 = @OCFS_KERNEL_2_6@
+
+# Setup all the extra parameters that might be needed by the build.
+# FIXME: Not sure if we have all the parameters here.
+ifdef OCFS_DEBUG
+EXTRA_CFLAGS += -DDEBUG
+endif
+
+ifdef OCFS_TRACE
+EXTRA_CFLAGS += -DTRACE
+endif
+
+ifdef HAVE_NPTL
+EXTRA_CFLAGS += -DHAVE_NPTL
+endif
+
+# Kernel Module file to produce
+obj-m += ocfs2.o
+
+# list of object files that are used to create our module
+ocfs2-objs := alloc.o divdi3.o hash.o ioctl.o oin.o super.o ver.o \
+              bitmap.o dlm.o heartbeat.o journal.o osb.o symlink.o volcfg.o \
+              dcache.o extmap.o inode.o namei.o proc.o sysfile.o vote.o \
+              dir.o file.o io.o nm.o sem.o util.o
+endif

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Ocfs2-devel] Updated Patch for 2.6 Make system
  2004-03-02 16:29 [Ocfs2-devel] Updated Patch for 2.6 Make system John L. Villalovos
@ 2004-03-02 17:47 ` Manish Singh
  0 siblings, 0 replies; 6+ messages in thread
From: Manish Singh @ 2004-03-02 17:47 UTC (permalink / raw)
  To: ocfs2-devel

On Tue, Mar 02, 2004 at 02:29:27PM -0800, John L. Villalovos wrote:
> Fixes an error from the previous patch where I forgot to do NPTL :(
> 
> This now compiles with SVN revision 748.

I just committed a modified version of the configure.in and Config.make.in
changes.

> Index: configure.in
> ===================================================================
> --- configure.in	(revision 747)
> +++ configure.in	(working copy)
> @@ -83,6 +83,13 @@
>    AC_MSG_ERROR(GCC is required)
>  fi
> 
> +AC_ARG_ENABLE(kernel-2_6, AC_HELP_STRING([--enable-kernel-2_6], [(BROKEN!) 
> Enable building on Linux kernel version 2.6.x 
> (default=no)]),enable_kernel26=yes,enable_kernel26=no)
> +OCFS_KERNEL_2_6=
> +if test "x$enable_kernel26" = "xyes"; then
> +  OCFS_KERNEL_2_6=yes
> +fi
> +AC_SUBST(OCFS_KERNEL_2_6)

I got rid of the _'s. configure's never use _ in switches. Also, we can't
use AC_HELP_STRING since we still need to support AS 2.1, which ships with
ancient autoconf 2.13.

> +      AC_MSG_NOTICE([Support for kernel version 2.6 is BROKEN at this 
> time!  Your system WILL hang.])

Used AC_MSG_WARN instead of AC_MSG_NOTICE for the same reason.

> @@ -314,4 +331,5 @@
>  vendor/unitedlinux/ocfs2-2.4.21-107.spec
>  vendor/unitedlinux/ocfs2-2.4.21-111.spec
>  vendor/unitedlinux/ocfs2-2.4.21-138.spec
> +src/Makefile-2.6

In makebo philosophy, Makefiles should never be generated from .in's. You
should be able to include Config.make for what you need.

What I'd like to see is having one Makefile that does everything, with the
defines, cflags, and object files defined only once. Keeping this in sync
across multiple files is a maintainence headache.

-Manish

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Ocfs2-devel] Updated Patch for 2.6 Make system
@ 2004-03-02 18:01 Villalovos, John L
  2004-03-02 19:51 ` Manish Singh
  0 siblings, 1 reply; 6+ messages in thread
From: Villalovos, John L @ 2004-03-02 18:01 UTC (permalink / raw)
  To: ocfs2-devel

> On Tue, Mar 02, 2004 at 02:29:27PM -0800, John L. Villalovos wrote:
> > Fixes an error from the previous patch where I forgot to do NPTL :(
> > 
> > This now compiles with SVN revision 748.
> 
> I just committed a modified version of the configure.in and 
> Config.make.in
> changes.

Sounds good.

> I got rid of the _'s. configure's never use _ in switches. 
> Also, we can't
> use AC_HELP_STRING since we still need to support AS 2.1, 
> which ships with
> ancient autoconf 2.13.

Makes sense.  Though would it make sense to distribute your generated
configure script in the future?  I thought the purpose of configure was
that you could use it to create a configure script that is distributed
in the tarball and the people don't need to have autoconf on their end.
This way we wouldn't have to worry about which version of autoconf is on
a system.

> > @@ -314,4 +331,5 @@
> >  vendor/unitedlinux/ocfs2-2.4.21-107.spec
> >  vendor/unitedlinux/ocfs2-2.4.21-111.spec
> >  vendor/unitedlinux/ocfs2-2.4.21-138.spec
> > +src/Makefile-2.6
> 
> In makebo philosophy, Makefiles should never be generated 
> from .in's. You
> should be able to include Config.make for what you need.

What is "makebo philosophy"?  I'm not familiar with that but I am
somewhat new to autoconf and automake.

From reading the documentation on autoconf and automake it appears that
a lot of times they use a template file to create a makefile.  Usually
it is Makefile.am though.

> What I'd like to see is having one Makefile that does 
> everything, with the
> defines, cflags, and object files defined only once. Keeping 
> this in sync
> across multiple files is a maintainence headache.

I agree.  I did it this way to minimize the impact to the current
Makefile system and figured we could work on integrating them in the
future.  I still need to figure out if there is a better way of doing
the build for the 2.6.x. kernel so that it isn't as convulted.

John

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Ocfs2-devel] Updated Patch for 2.6 Make system
  2004-03-02 18:01 Villalovos, John L
@ 2004-03-02 19:51 ` Manish Singh
  0 siblings, 0 replies; 6+ messages in thread
From: Manish Singh @ 2004-03-02 19:51 UTC (permalink / raw)
  To: ocfs2-devel

On Tue, Mar 02, 2004 at 04:01:33PM -0800, Villalovos, John L wrote:
> > On Tue, Mar 02, 2004 at 02:29:27PM -0800, John L. Villalovos wrote:
> > I got rid of the _'s. configure's never use _ in switches. 
> > Also, we can't
> > use AC_HELP_STRING since we still need to support AS 2.1, 
> > which ships with
> > ancient autoconf 2.13.
> 
> Makes sense.  Though would it make sense to distribute your generated
> configure script in the future?  I thought the purpose of configure was
> that you could use it to create a configure script that is distributed
> in the tarball and the people don't need to have autoconf on their end.
> This way we wouldn't have to worry about which version of autoconf is on
> a system.

That's true for released tarballs, but not for svn checkouts. It's not
really proper to have generated files in source control, since different
installations can produce different output, which leads to merge confusion.
 
> > > @@ -314,4 +331,5 @@
> > >  vendor/unitedlinux/ocfs2-2.4.21-107.spec
> > >  vendor/unitedlinux/ocfs2-2.4.21-111.spec
> > >  vendor/unitedlinux/ocfs2-2.4.21-138.spec
> > > +src/Makefile-2.6
> > 
> > In makebo philosophy, Makefiles should never be generated 
> > from .in's. You
> > should be able to include Config.make for what you need.
> 
> What is "makebo philosophy"?  I'm not familiar with that but I am
> somewhat new to autoconf and automake.

makebo what we're using instead of automake. 

http://oss.oracle.com/projects/makebo/ (yes, the project info is spartan)

makebo is intended to be an automake/libtool replacement, since the many
of the latters' design decisions result in a system that's more complex
than it has to be.

> From reading the documentation on autoconf and automake it appears that
> a lot of times they use a template file to create a makefile.  Usually
> it is Makefile.am though.

Yeah, that's what automake does. I don't like that, since it makes
configure take an age, and results in hugely bloated Makefiles. include
is much nicer.

> > What I'd like to see is having one Makefile that does 
> > everything, with the
> > defines, cflags, and object files defined only once. Keeping 
> > this in sync
> > across multiple files is a maintainence headache.
> 
> I agree.  I did it this way to minimize the impact to the current
> Makefile system and figured we could work on integrating them in the
> future.  I still need to figure out if there is a better way of doing
> the build for the 2.6.x. kernel so that it isn't as convulted.

Well, reexecing make against the kernel's build stuff is the right
approach I think. Use of the "export" directive in GNU make might be
useful.

-Manish

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Ocfs2-devel] Updated Patch for 2.6 Make system
@ 2004-03-03 10:57 Villalovos, John L
  2004-03-03 17:15 ` Manish Singh
  0 siblings, 1 reply; 6+ messages in thread
From: Villalovos, John L @ 2004-03-03 10:57 UTC (permalink / raw)
  To: ocfs2-devel

> > Makes sense.  Though would it make sense to distribute your 
> generated
> > configure script in the future?  I thought the purpose of 
> configure was
> > that you could use it to create a configure script that is 
> distributed
> > in the tarball and the people don't need to have autoconf 
> on their end.
> > This way we wouldn't have to worry about which version of 
> autoconf is on
> > a system.
> 
> That's true for released tarballs, but not for svn checkouts. It's not
> really proper to have generated files in source control, 
> since different
> installations can produce different output, which leads to 
> merge confusion.

I agree but you should NOT have to support older versions of autoconf
because when you generate the tarball you will create the configure
script for them.

But if the goal is to support AS 2.1 in the mode where they can check
the code out and run autoconf then you would need to support the older
versions.  And I suppose if you are doing your development on AS 2.1
then you would probably want that.

> > What is "makebo philosophy"?  I'm not familiar with that but I am
> > somewhat new to autoconf and automake.
> 
> makebo what we're using instead of automake. 
> 
> http://oss.oracle.com/projects/makebo/ (yes, the project info is
spartan)

> makebo is intended to be an automake/libtool replacement, since the
many
> of the latters' design decisions result in a system that's more
complex
> than it has to be.

Thanks I will take a look at that :)

>> > What I'd like to see is having one Makefile that does 
>> > everything, with the
>> > defines, cflags, and object files defined only once. Keeping 
>> > this in sync
>> > across multiple files is a maintainence headache.
>> 
>> I agree.  I did it this way to minimize the impact to the current
>> Makefile system and figured we could work on integrating them in the
>> future.  I still need to figure out if there is a better way of doing
>> the build for the 2.6.x. kernel so that it isn't as convulted.
>
>Well, reexecing make against the kernel's build stuff is the right
>approach I think. Use of the "export" directive in GNU make might be
>useful.

Okay.  I will try to integrate the stuff in.  The only hard part I had
before is that when the Kernel includes the makefile I can NOT figure
out where I am so I had a hard time including Config.make,
Pre/post-amble.make.  If I can figure that out then it can work but
otherwise I'm not sure how to do it.

John

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Ocfs2-devel] Updated Patch for 2.6 Make system
  2004-03-03 10:57 Villalovos, John L
@ 2004-03-03 17:15 ` Manish Singh
  0 siblings, 0 replies; 6+ messages in thread
From: Manish Singh @ 2004-03-03 17:15 UTC (permalink / raw)
  To: ocfs2-devel

On Wed, Mar 03, 2004 at 08:54:23AM -0800, Villalovos, John L wrote:
> > > Makes sense.  Though would it make sense to distribute your 
> > generated
> > > configure script in the future?  I thought the purpose of 
> > configure was
> > > that you could use it to create a configure script that is 
> > distributed
> > > in the tarball and the people don't need to have autoconf 
> > on their end.
> > > This way we wouldn't have to worry about which version of 
> > autoconf is on
> > > a system.
> > 
> > That's true for released tarballs, but not for svn checkouts. It's not
> > really proper to have generated files in source control, 
> > since different
> > installations can produce different output, which leads to 
> > merge confusion.
> 
> I agree but you should NOT have to support older versions of autoconf
> because when you generate the tarball you will create the configure
> script for them.

That's what I meant with "That's true for released tarballs".

> But if the goal is to support AS 2.1 in the mode where they can check
> the code out and run autoconf then you would need to support the older
> versions.  And I suppose if you are doing your development on AS 2.1
> then you would probably want that.

That's precisely the goal.

-Manish

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-03-03 17:15 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-02 16:29 [Ocfs2-devel] Updated Patch for 2.6 Make system John L. Villalovos
2004-03-02 17:47 ` Manish Singh
  -- strict thread matches above, loose matches on Subject: below --
2004-03-02 18:01 Villalovos, John L
2004-03-02 19:51 ` Manish Singh
2004-03-03 10:57 Villalovos, John L
2004-03-03 17:15 ` Manish Singh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.