[Buildroot] Makefile.autotools.in problems

[Buildroot] Makefile.autotools.in problems

[Daniel Laird]

I have a problem with the Makefile.autotools.in when it does the patch
target.

The target creates a NAMEVER string (pkg_name-version).  It then checks to
see if it has any version specific files.  i.e pango-1.19.3.*.patch.
If it has is applies them and exits. (appies no generic patches)

The problem is that if I bounce the version to 1.22.0.  It does the check
and decides there are no version specific patches.  It then applies all
patches in the directory regardless.

This is only a problem as I have not deleted patches associated with an old
version.  
However I wanted to raise the issue in case it was originally planned that
you could have multiple patches in the directory for different versions and
it would apply only those patches that match.

Perhaps we could have a PKG_STRICT_PATCH variable.  That if set to true
would only apply patches that match the version string, if not set it would
apply all patches.

Any ideas, opinions?
Cheers
Dan


-- 
View this message in context: http://www.nabble.com/Makefile.autotools.in-problems-tp18377517p18377517.html
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] Makefile.autotools.in problems

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Laird <daniel.j.laird@nxp.com> writes:

Hi,

 Daniel> This is only a problem as I have not deleted patches
 Daniel> associated with an old version.  However I wanted to raise
 Daniel> the issue in case it was originally planned that you could
 Daniel> have multiple patches in the directory for different versions
 Daniel> and it would apply only those patches that match.

Yes, the Makefile.autotools.in is kinda half baked still.

 Daniel> Perhaps we could have a PKG_STRICT_PATCH variable.  That if
 Daniel> set to true would only apply patches that match the version
 Daniel> string, if not set it would apply all patches.

That or put the patches in version specific sub directories like
openembedded does.

-- 
Bye, Peter Korsgaard

[Buildroot] Makefile.autotools.in problems

[Ulf Samuelsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Korsgaard skrev:
>>>>>> "Daniel" == Daniel Laird <daniel.j.laird@nxp.com> writes:
> 
> Hi,
> 
>  Daniel> This is only a problem as I have not deleted patches
>  Daniel> associated with an old version.  However I wanted to raise
>  Daniel> the issue in case it was originally planned that you could
>  Daniel> have multiple patches in the directory for different versions
>  Daniel> and it would apply only those patches that match.
> 
> Yes, the Makefile.autotools.in is kinda half baked still.
> 
>  Daniel> Perhaps we could have a PKG_STRICT_PATCH variable.  That if
>  Daniel> set to true would only apply patches that match the version
>  Daniel> string, if not set it would apply all patches.
> 
> That or put the patches in version specific sub directories like
> openembedded does.
> 
I vote for the latter.

BR
ulf Samuelsson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIdg8/AyRRH5cXxqwRAmzjAJ4p57bU6fsdPWkpfyFHhzdTw587agCeIAkn
4JGH6fXyR/gHE24lpqg5kEM=
=EBnh
-----END PGP SIGNATURE-----

[Buildroot] Makefile.autotools.in problems

[Daniel Laird]

I have searched for all packages that use the AUTOTOOLS system and then
looked at those that have patches as well.  The list is below:

ace_of_penguins/ace_of_penguins.mk:$(eval $(call
AUTOTARGETS,package,ace_of_penguins))
beecrypt/beecrypt.mk:$(eval $(call AUTOTARGETS,package,beecrypt))
blackbox/blackbox.mk:$(eval $(call AUTOTARGETS,package,blackbox))
docker/docker.mk:$(eval $(call AUTOTARGETS,package,docker))
festival/festival/festival.mk:$(eval $(call
AUTOTARGETS,package/festival,festival))
festival/speech-tools/speech-tools.mk:$(eval $(call
AUTOTARGETS,package/festival,speech-tools))
fltk/fltk.mk:$(eval $(call AUTOTARGETS,package,fltk))
gamin/gamin.mk:$(eval $(call AUTOTARGETS,package,gamin))
gnuchess/gnuchess.mk:$(eval $(call AUTOTARGETS,package,gnuchess))
gqview/gqview.mk:$(eval $(call AUTOTARGETS,package,gqview))
ifplugd/ifplugd.mk:$(eval $(call AUTOTARGETS,package,ifplugd))
libglib2/libglib2.mk:$(eval $(call AUTOTARGETS,package,libglib2))
libgtk2/libgtk2.mk:$(eval $(call AUTOTARGETS,package,libgtk2))
lite/lite.mk:$(eval $(call AUTOTARGETS,package,lite))
lxdoom/lxdoom.mk:$(eval $(call AUTOTARGETS,package,lxdoom))
magiccube4d/magiccube4d.mk:$(eval $(call AUTOTARGETS,package,magiccube4d))
midori/midori.mk:$(eval $(call AUTOTARGETS,package,midori))
ng-spice-rework/ng-spice-rework.mk:$(eval $(call
AUTOTARGETS,package,ng-spice-rework))
pango/pango.mk:$(eval $(call AUTOTARGETS,package,pango))
popt/popt.mk:$(eval $(call AUTOTARGETS,package,popt))
rpm/rpm.mk:$(eval $(call AUTOTARGETS,package,rpm))
rubix/rubix.mk:$(eval $(call AUTOTARGETS,package,rubix))
screen/screen.mk:$(eval $(call AUTOTARGETS,package,screen))
sylpheed/sylpheed.mk:$(eval $(call AUTOTARGETS,package,sylpheed))
vice/vice.mk:$(eval $(call AUTOTARGETS,package,vice))
webkit/webkit.mk:$(eval $(call AUTOTARGETS,package,webkit))
x11r7/pixman/pixman.mk:$(eval $(call AUTOTARGETS,package/x11r7,pixman))
x11r7/xapp_xauth/xapp_xauth.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xapp_xauth))
x11r7/xapp_xrandr/xapp_xrandr.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xapp_xrandr))
x11r7/xdriver_xf86-input-evdev/xdriver_xf86-input-evdev.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-input-evdev))
x11r7/xdriver_xf86-input-synaptics/xdriver_xf86-input-synaptics.mk:$(eval
$(call AUTOTARGETS,package/x11r7,xdriver_xf86-input-synaptics))
x11r7/xdriver_xf86-video-ati/xdriver_xf86-video-ati.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-ati))
x11r7/xdriver_xf86-video-cyrix/xdriver_xf86-video-cyrix.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-cyrix))
x11r7/xdriver_xf86-video-glint/xdriver_xf86-video-glint.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-glint))
x11r7/xdriver_xf86-video-i810/xdriver_xf86-video-i810.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-i810))
x11r7/xdriver_xf86-video-imstt/xdriver_xf86-video-imstt.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-imstt))
x11r7/xdriver_xf86-video-intel/xdriver_xf86-video-intel.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-intel))
x11r7/xdriver_xf86-video-mga/xdriver_xf86-video-mga.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-mga))
x11r7/xdriver_xf86-video-newport/xdriver_xf86-video-newport.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-newport))
x11r7/xdriver_xf86-video-savage/xdriver_xf86-video-savage.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-savage))
x11r7/xdriver_xf86-video-sis/xdriver_xf86-video-sis.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-sis))
x11r7/xdriver_xf86-video-sunffb/xdriver_xf86-video-sunffb.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-sunffb))
x11r7/xdriver_xf86-video-tdfx/xdriver_xf86-video-tdfx.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-tdfx))
x11r7/xdriver_xf86-video-tga/xdriver_xf86-video-tga.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-tga))
x11r7/xdriver_xf86-video-vesa/xdriver_xf86-video-vesa.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-vesa))
x11r7/xdriver_xf86-video-via/xdriver_xf86-video-via.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xdriver_xf86-video-via))
x11r7/xfont_encodings/xfont_encodings.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xfont_encodings))
x11r7/xlib_liblbxutil/xlib_liblbxutil.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xlib_liblbxutil))
x11r7/xlib_libX11/xlib_libX11.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xlib_libX11))x11r7/xlib_libXfontcache/xlib_libXfontcache.mk:$(eval
$(call AUTOTARGETS,package/x11r7,xlib_libXfontcache))
x11r7/xlib_libXfont/xlib_libXfont.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xlib_libXfont))x11r7/xlib_libXt/xlib_libXt.mk:$(eval
$(call AUTOTARGETS,package/x11r7,xlib_libXt))
x11r7/xserver_xorg-server/xserver_xorg-server.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xserver_xorg-server))
x11r7/xutil_util-macros/xutil_util-macros.mk:$(eval $(call
AUTOTARGETS,package/x11r7,xutil_util-macros))
xboard/xboard.mk:$(eval $(call AUTOTARGETS,package,xboard))
xpdf/xpdf.mk:$(eval $(call AUTOTARGETS,package,xpdf))
xvkbd/xvkbd.mk:$(eval $(call AUTOTARGETS,package,xvkbd))

These packages are the ones whose patches would have to be moved into
patch-$(VERSION) directories.
The Autotools.in could then do if -d PKG_NAME/patch-$(VERSION) then apply
those patches.
The question is should it apply a patch that is in the toplevel (i.e
package/pango/generic.patch.  If the patch applies across multiple versions?
Or should we be strict and apply patches in the top level if no version
specific patches.  If a directory called patch-$(VERSION) only apply those
patches?
I prefer the latter option

Cheers
Dan



Ulf Samuelsson-4 wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Peter Korsgaard skrev:
>>>>>>> "Daniel" == Daniel Laird <daniel.j.laird@nxp.com> writes:
>> 
>> Hi,
>> 
>>  Daniel> This is only a problem as I have not deleted patches
>>  Daniel> associated with an old version.  However I wanted to raise
>>  Daniel> the issue in case it was originally planned that you could
>>  Daniel> have multiple patches in the directory for different versions
>>  Daniel> and it would apply only those patches that match.
>> 
>> Yes, the Makefile.autotools.in is kinda half baked still.
>> 
>>  Daniel> Perhaps we could have a PKG_STRICT_PATCH variable.  That if
>>  Daniel> set to true would only apply patches that match the version
>>  Daniel> string, if not set it would apply all patches.
>> 
>> That or put the patches in version specific sub directories like
>> openembedded does.
>> 
> I vote for the latter.
> 
> BR
> ulf Samuelsson
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
> 
> iD8DBQFIdg8/AyRRH5cXxqwRAmzjAJ4p57bU6fsdPWkpfyFHhzdTw587agCeIAkn
> 4JGH6fXyR/gHE24lpqg5kEM=
> =EBnh
> -----END PGP SIGNATURE-----
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 
> 

-- 
View this message in context: http://www.nabble.com/Makefile.autotools.in-problems-tp18377517p18398681.html
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] Makefile.autotools.in problems

[Bernhard Fischer]

On Thu, Jul 10, 2008 at 09:47:01AM +0200, Peter Korsgaard wrote:
>>>>>> "Daniel" == Daniel Laird <daniel.j.laird@nxp.com> writes:
>
>Hi,
>
> Daniel> This is only a problem as I have not deleted patches
> Daniel> associated with an old version.  However I wanted to raise
> Daniel> the issue in case it was originally planned that you could
> Daniel> have multiple patches in the directory for different versions
> Daniel> and it would apply only those patches that match.
>
>Yes, the Makefile.autotools.in is kinda half baked still.
>
> Daniel> Perhaps we could have a PKG_STRICT_PATCH variable.  That if
> Daniel> set to true would only apply patches that match the version
> Daniel> string, if not set it would apply all patches.
>
>That or put the patches in version specific sub directories like
>openembedded does.

What's the point in keeping patches for multiple versions again?

We usually "svn mv" affected patches (or should anyway). There really
are very, very few packages where it makes sense to keep multiple
versions. Except toolchain/* only the kernel comes to mind, the rest
should just have exactly 1 version, but that one should build and work
fine.

[Buildroot] Makefile.autotools.in problems

[Daniel Laird]

Bernhard Fischer-6 wrote:
> 
> On Thu, Jul 10, 2008 at 09:47:01AM +0200, Peter Korsgaard wrote:
>>>>>>> "Daniel" == Daniel Laird <daniel.j.laird@nxp.com> writes:
>>
>>Hi,
>>
>> Daniel> This is only a problem as I have not deleted patches
>> Daniel> associated with an old version.  However I wanted to raise
>> Daniel> the issue in case it was originally planned that you could
>> Daniel> have multiple patches in the directory for different versions
>> Daniel> and it would apply only those patches that match.
>>
>>Yes, the Makefile.autotools.in is kinda half baked still.
>>
>> Daniel> Perhaps we could have a PKG_STRICT_PATCH variable.  That if
>> Daniel> set to true would only apply patches that match the version
>> Daniel> string, if not set it would apply all patches.
>>
>>That or put the patches in version specific sub directories like
>>openembedded does.
> 
> What's the point in keeping patches for multiple versions again?
> 
> We usually "svn mv" affected patches (or should anyway). There really
> are very, very few packages where it makes sense to keep multiple
> versions. Except toolchain/* only the kernel comes to mind, the rest
> should just have exactly 1 version, but that one should build and work
> fine.
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 
> 
The reason for this is making it more flexible and also more stable.
For example the current buildroot uses pango 1.19.3 I am testing locally an
upgrade to 1.21.3.
To do this we overlay buildroot with local modifications and build.
The problem is that the 1.19.3 patches get applied to the 1.21.3 code which
fail.
I cannot easily test all packages that use pango and check they work as well
as previously.
I could however create a patch-VERSION dir and put the 1.19.3 patches into
it.
I could then do the same with 1.21.3.
I think this is more flexible, more suitable to production environments and
is not that much extra maintenance.  
I like to be as close to buildroot mainline as possible to get as much
help/support as possible.  But some changes just do not work and as such the
ability to go back to previously working versions more easily is desirable.
I believe it is also similar to OpenEmbedded
-- 
View this message in context: http://www.nabble.com/Makefile.autotools.in-problems-tp18377517p18399520.html
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] Makefile.autotools.in problems

[Daniel Laird]

I have been playing:
I decided to have a directory called patches-$(VERSION)
I then modified Makefile.autotools.in with the following:
 # Retrieve and unpack the archive
 $(BUILD_DIR)/%/.stamp_extracted:
@@ -160,16 +170,12 @@
 	$(if $($(PKG)_PATCH),toolchain/patch-kernel.sh $(@D) $(DL_DIR)
$($(PKG)_PATCH))
 	$(Q)( \
 	if test -d $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME); then \
-	  if test -d
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/patches-$($(PKG)_VERSION); then \
-	    toolchain/patch-kernel.sh $(@D)
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/patches-$($(PKG)_VERSION)/ \*.patch
\*.patch.$(ARCH) || exit 1; \
+	  if test "$(wildcard
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER)*.patch*)"; then \
+	    toolchain/patch-kernel.sh $(@D) $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)
$(NAMEVER)\*.patch $(NAMEVER)\*.patch.$(ARCH) || exit 1; \
 	  else \
-	    if test "$(wildcard
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER)*.patch*)"; then \
-	      toolchain/patch-kernel.sh $(@D) $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)
$(NAMEVER)\*.patch $(NAMEVER)\*.patch.$(ARCH) || exit 1; \
-	    else \
-	      toolchain/patch-kernel.sh $(@D) $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)
$($(PKG)_NAME)\*.patch $($(PKG)_NAME)\*.patch.$(ARCH) || exit 1; \
-	      if test -d package/$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER);
then \
-	        toolchain/patch-kernel.sh $(@D)
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH) ||
exit 1; \
-	      fi; \
+	    toolchain/patch-kernel.sh $(@D) $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)
$($(PKG)_NAME)\*.patch $($(PKG)_NAME)\*.patch.$(ARCH) || exit 1; \
+	    if test -d package/$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER);
then \
+	      toolchain/patch-kernel.sh $(@D)
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH) ||
exit 1; \
 	    fi; \
 	  fi; \
 	fi; \
@@ -233,7 +239,7 @@
 $(BUILD_DIR)/%/.stamp_target_installed:
 	$(call MESSAGE,"Installing to target")
 	$($(PKG)_MAKE_ENV) $(MAKE) $($(PKG)_INSTALL_TARGET_OPT) -C
$(@D)/$($(PKG)_SUBDIR)
-	$(if $(BR2_HAVE_MANPAGES),,for d in man; do \
+	$(if $(BR2_HAVE_MANPAGES),,for d in man share/man; do \
 		rm -rf $(TARGET_DIR)/$$d $(TARGET_DIR)/usr/$$d; \
 	done)
 	$(if $(BR2_HAVE_INFOPAGES),,for d in info share/info; do \

Any thoughts?
Dan


Daniel Laird wrote:
> 
> 
> 
> Bernhard Fischer-6 wrote:
>> 
>> On Thu, Jul 10, 2008 at 09:47:01AM +0200, Peter Korsgaard wrote:
>>>>>>>> "Daniel" == Daniel Laird <daniel.j.laird@nxp.com> writes:
>>>
>>>Hi,
>>>
>>> Daniel> This is only a problem as I have not deleted patches
>>> Daniel> associated with an old version.  However I wanted to raise
>>> Daniel> the issue in case it was originally planned that you could
>>> Daniel> have multiple patches in the directory for different versions
>>> Daniel> and it would apply only those patches that match.
>>>
>>>Yes, the Makefile.autotools.in is kinda half baked still.
>>>
>>> Daniel> Perhaps we could have a PKG_STRICT_PATCH variable.  That if
>>> Daniel> set to true would only apply patches that match the version
>>> Daniel> string, if not set it would apply all patches.
>>>
>>>That or put the patches in version specific sub directories like
>>>openembedded does.
>> 
>> What's the point in keeping patches for multiple versions again?
>> 
>> We usually "svn mv" affected patches (or should anyway). There really
>> are very, very few packages where it makes sense to keep multiple
>> versions. Except toolchain/* only the kernel comes to mind, the rest
>> should just have exactly 1 version, but that one should build and work
>> fine.
>> _______________________________________________
>> buildroot mailing list
>> buildroot at uclibc.org
>> http://busybox.net/mailman/listinfo/buildroot
>> 
>> 
> The reason for this is making it more flexible and also more stable.
> For example the current buildroot uses pango 1.19.3 I am testing locally
> an upgrade to 1.21.3.
> To do this we overlay buildroot with local modifications and build.
> The problem is that the 1.19.3 patches get applied to the 1.21.3 code
> which fail.
> I cannot easily test all packages that use pango and check they work as
> well as previously.
> I could however create a patch-VERSION dir and put the 1.19.3 patches into
> it.
> I could then do the same with 1.21.3.
> I think this is more flexible, more suitable to production environments
> and is not that much extra maintenance.  
> I like to be as close to buildroot mainline as possible to get as much
> help/support as possible.  But some changes just do not work and as such
> the ability to go back to previously working versions more easily is
> desirable.
> I believe it is also similar to OpenEmbedded
> 

-- 
View this message in context: http://www.nabble.com/Makefile.autotools.in-problems-tp18377517p18402911.html
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] Makefile.autotools.in problems

[Daniel Laird]

Oops, wrong patch :-( 
Heres the correct patch:
diff -urN buildroot-20080708.orig/buildroot/package/Makefile.autotools.in
buildroot-20080708/buildroot/package/Makefile.autotools.in
--- buildroot-20080708.orig/buildroot/package/Makefile.autotools.in
2008-07-08 13:47:19.000000000 +0100
+++ buildroot-20080708/buildroot/package/Makefile.autotools.in	2008-07-11
13:39:36.000000000 +0100
@@ -170,12 +170,16 @@
 	$(if $($(PKG)_PATCH),toolchain/patch-kernel.sh $(@D) $(DL_DIR)
$($(PKG)_PATCH))
 	$(Q)( \
 	if test -d $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME); then \
+	  if test -d
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/patches-$($(PKG)_VERSION); then \
+	    toolchain/patch-kernel.sh $(@D)
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/patches-$($(PKG)_VERSION)/ \*.patch
\*.patch.$(ARCH) || exit 1; \
+	  else \
 	  if test "$(wildcard
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER)*.patch*)"; then \
 	    toolchain/patch-kernel.sh $(@D) $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)
$(NAMEVER)\*.patch $(NAMEVER)\*.patch.$(ARCH) || exit 1; \
 	  else \
 	    toolchain/patch-kernel.sh $(@D) $($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)
$($(PKG)_NAME)\*.patch $($(PKG)_NAME)\*.patch.$(ARCH) || exit 1; \
 	    if test -d package/$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER);
then \
 	      toolchain/patch-kernel.sh $(@D)
$($(PKG)_DIR_PREFIX)/$($(PKG)_NAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH) ||
exit 1; \
+	      fi; \
 	    fi; \
 	  fi; \
 	fi; \

Any thoughts?
-- 
View this message in context: http://www.nabble.com/Makefile.autotools.in-problems-tp18377517p18402988.html
Sent from the BuildRoot mailing list archive at Nabble.com.