* [Buildroot] What is the proper procedure to commit a patch?
@ 2007-07-06 12:35 Ulf Samuelsson
2007-07-06 15:26 ` Bernhard Fischer
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Ulf Samuelsson @ 2007-07-06 12:35 UTC (permalink / raw)
To: buildroot
Now, when I have access, I would like to understand the proper
procedure to add patches.
After checking out and applying a patch, I can do:
svn commit -F <file>
with <file> containing a log message.
or
svn commit -m "log message"
I tried a real simple patch first and after the commit,
the svn server automatically sent out a mail with the change,
adding the log message.
The patches I'd like to add are mainly:
* BSP patch ,discussed and approved by Eric.
* moving package/customize to topdir and rename "local", also discussed before
* Support for AT91 boot monitors
Dataflashboot
AT91-Bootstrap
U-boot
Generate U-Boot initialization scripts
* Add AVR32 support.
* A few extra packages.
* Update mtdutils (which is really old)
* Clean up the linux support (move into a separate dir in package)
* Bump versions on a number of packages which has disappeared from their download location.
(dash, rmp, l2tp, mpfr,mrouted, openntpd, portage, pppd,udev)
* Add TARGET_CFLAGS to all packages not having this
Would like to know if they lack TARGET_CFLAGS for a reason.
(acpid,berkleydb, hdparm, iostat,ltp-testsuite,memtester,netkitbase,
procps, python, sysklogd, tinyx,udhcp)
* Introduce concept of distributions (did not do any work there yet though)
--------------
Both the version bump and TARGET_CFLAGS lists are a month old, so
maybe the svn already is updated.
Is it OK to bump version if something disappears from internet, or do we need a review.
Sometimes you find new versions of a package, Is it OK to bump the version
without previous review by peers?
Anything else to think about (except golden rule: do not break the build)?
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group mailto:avr32 at atmel.com
http://www.avrfreaks.net/; http://avr32linux.org/
http://www.at91.com/ ; ftp://at91dist:distrib at 81.80.104.162/
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] What is the proper procedure to commit a patch? 2007-07-06 12:35 [Buildroot] What is the proper procedure to commit a patch? Ulf Samuelsson @ 2007-07-06 15:26 ` Bernhard Fischer 2007-07-06 15:36 ` Ulf Samuelsson 2007-07-06 15:55 ` Steven J. Hill 2007-07-07 10:21 ` [Buildroot] What is the proper procedure to commit a patch? Bernhard Fischer 2 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-06 15:26 UTC (permalink / raw) To: buildroot On Fri, Jul 06, 2007 at 02:35:32PM +0200, Ulf Samuelsson wrote: >Now, when I have access, I would like to understand the proper >procedure to add patches. > >After checking out and applying a patch, I can do: - apply - test - check (svn diff) - commit (svn ci this/file that/file; or everything svn ci). You're prompted for a message (my distry spawns $EDITOR, like usual). > >svn commit -F <file> >with <file> containing a log message. >or >svn commit -m "log message" > >I tried a real simple patch first and after the commit, >the svn server automatically sent out a mail with the change, >adding the log message. > >The patches I'd like to add are mainly: >* BSP patch ,discussed and approved by Eric. >* moving package/customize to topdir and rename "local", also discussed before >* Support for AT91 boot monitors > Dataflashboot > AT91-Bootstrap > U-boot > Generate U-Boot initialization scripts >* Add AVR32 support. >* A few extra packages. >* Update mtdutils (which is really old) >* Clean up the linux support (move into a separate dir in package) I object to this. Can we please have _one_ linux.mk If we cannot have it, then please explain to me why you think we should duplicate this all over the place. (see buildroot/target/device/mips/* for an example on how you can use The One linux.mk). A sane thing to do is to $ svn rm $(find ./ -name linux.mk) and _not_ to add to the lot of cruft. As said, please elaborate. >* Bump versions on a number of packages which has disappeared from their download location. > (dash, rmp, l2tp, mpfr,mrouted, openntpd, portage, pppd,udev) >* Add TARGET_CFLAGS to all packages not having this > Would like to know if they lack TARGET_CFLAGS for a reason. > (acpid,berkleydb, hdparm, iostat,ltp-testsuite,memtester,netkitbase, > procps, python, sysklogd, tinyx,udhcp) Packages that do not use autoconf'ed configure scripts should IMO also use $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(THAT_DIR) whatever where possible. This approach makes maintenance way simpler since you do not have to touch gazillions of files if you choose to add another var. >* Introduce concept of distributions (did not do any work there yet though) >-------------- > Both the version bump and TARGET_CFLAGS lists are a month old, so > maybe the svn already is updated. > > Is it OK to bump version if something disappears from internet, or do we need a review. > Sometimes you find new versions of a package, Is it OK to bump the version > without previous review by peers? Check that the package does what it is supposed to do, i.e. actually use the piece of updated software for a few days, ideally interactively for daily use. > > Anything else to think about (except golden rule: do not break the build)? Yeah, try not to break stuff too badly. Don't introduce complexity without real, apparent benefit. If you want to add complexity (like your BSP stuff), then discuss it (like e.g. i did with the sysroot stuff, or, at least i warned for a long time, got no feedback and it's obviously correct and useful). I still don't like the concept and implementation of that BSP stuff, fwiw. hope at least some hunks from the above helps; cheers, ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-06 15:26 ` Bernhard Fischer @ 2007-07-06 15:36 ` Ulf Samuelsson 2007-07-07 10:12 ` Bernhard Fischer 0 siblings, 1 reply; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-06 15:36 UTC (permalink / raw) To: buildroot >>The patches I'd like to add are mainly: >>* BSP patch ,discussed and approved by Eric. >>* moving package/customize to topdir and rename "local", also discussed before >>* Support for AT91 boot monitors >> Dataflashboot >> AT91-Bootstrap >> U-boot >> Generate U-Boot initialization scripts >>* Add AVR32 support. >>* A few extra packages. >>* Update mtdutils (which is really old) >>* Clean up the linux support (move into a separate dir in package) > > I object to this. Can we please have _one_ linux.mk > If we cannot have it, then please explain to me why you think we should > duplicate this all over the place. > (see buildroot/target/device/mips/* for an example on how you can use > The One linux.mk). > A sane thing to do is to > $ svn rm $(find ./ -name linux.mk) > and _not_ to add to the lot of cruft. As said, please elaborate. > I think you misunderstood. Now we have package/linux.mk and we have Linux configuration spread out. What I want to do is to move "package/linux.mk" to "package/linux/linux.mk" and then remove the distributed linux configuration to "package/linux/Config.in" Best Regards Ulf Samuelsson ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-06 15:36 ` Ulf Samuelsson @ 2007-07-07 10:12 ` Bernhard Fischer 2007-07-07 11:16 ` Ulf Samuelsson 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-07 10:12 UTC (permalink / raw) To: buildroot On Fri, Jul 06, 2007 at 05:36:58PM +0200, Ulf Samuelsson wrote: > >>>The patches I'd like to add are mainly: >>>* BSP patch ,discussed and approved by Eric. >>>* moving package/customize to topdir and rename "local", also discussed before >>>* Support for AT91 boot monitors >>> Dataflashboot >>> AT91-Bootstrap >>> U-boot >>> Generate U-Boot initialization scripts >>>* Add AVR32 support. >>>* A few extra packages. >>>* Update mtdutils (which is really old) >>>* Clean up the linux support (move into a separate dir in package) >> >> I object to this. Can we please have _one_ linux.mk >> If we cannot have it, then please explain to me why you think we should >> duplicate this all over the place. >> (see buildroot/target/device/mips/* for an example on how you can use >> The One linux.mk). >> A sane thing to do is to >> $ svn rm $(find ./ -name linux.mk) >> and _not_ to add to the lot of cruft. As said, please elaborate. >> > >I think you misunderstood. >Now we have package/linux.mk and we have Linux configuration spread out. > >What I want to do is to move "package/linux.mk" to "package/linux/linux.mk" What's that good for? Just curious, this is just cosmetics. >and then remove the distributed linux configuration to "package/linux/Config.in" Which "distributed linux configuration" do you mean? ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-07 10:12 ` Bernhard Fischer @ 2007-07-07 11:16 ` Ulf Samuelsson 2007-07-07 12:35 ` Bernhard Fischer 0 siblings, 1 reply; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-07 11:16 UTC (permalink / raw) To: buildroot >>Now we have package/linux.mk and we have Linux configuration spread out. >> >>What I want to do is to move "package/linux.mk" to "package/linux/linux.mk" > > What's that good for? Just curious, this is just cosmetics. > >>and then remove the distributed linux configuration to "package/linux/Config.in" > > Which "distributed linux configuration" do you mean? > I'd like to have the configuration and makefile in the same directory. Now the configuration is in a different directory. The current linux.mk is much less flexible than the one I use. Once we have the linux in a good place, then I will submit my proposals to the mailing list. Best Regards Ulf Samuelsson ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-07 11:16 ` Ulf Samuelsson @ 2007-07-07 12:35 ` Bernhard Fischer 2007-07-07 13:46 ` Ulf Samuelsson 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-07 12:35 UTC (permalink / raw) To: buildroot On Sat, Jul 07, 2007 at 01:16:13PM +0200, Ulf Samuelsson wrote: >>>Now we have package/linux.mk and we have Linux configuration spread out. >>> >>>What I want to do is to move "package/linux.mk" to "package/linux/linux.mk" >> >> What's that good for? Just curious, this is just cosmetics. >> >>>and then remove the distributed linux configuration to "package/linux/Config.in" >> >> Which "distributed linux configuration" do you mean? >> > >I'd like to have the configuration and makefile in the same directory. I don't like to have it in the same directory. >Now the configuration is in a different directory. Yes, and that's a feature. You (or the board) can easily set BR2_PACKAGE_LINUX_KCONFIG to anything you want. It was added for exactly this purpose. > >The current linux.mk is much less flexible than the one I use. You keep saying this, ISTR. What does not work currently as opposed to "yours"? Did you try to use the currently existing one, recently? >Once we have the linux in a good place, then I will submit >my proposals to the mailing list. ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-07 12:35 ` Bernhard Fischer @ 2007-07-07 13:46 ` Ulf Samuelsson 0 siblings, 0 replies; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-07 13:46 UTC (permalink / raw) To: buildroot ----- Original Message ----- From: "Bernhard Fischer" <rep.dot.nop@gmail.com> To: "Ulf Samuelsson" <ulf@atmel.com> Cc: <buildroot@uclibc.org> Sent: Saturday, July 07, 2007 2:35 PM Subject: Re: [Buildroot] What is the proper procedure to commit a patch? > On Sat, Jul 07, 2007 at 01:16:13PM +0200, Ulf Samuelsson wrote: >>>>Now we have package/linux.mk and we have Linux configuration spread out. >>>> >>>>What I want to do is to move "package/linux.mk" to "package/linux/linux.mk" >>> >>> What's that good for? Just curious, this is just cosmetics. >>> >>>>and then remove the distributed linux configuration to "package/linux/Config.in" >>> >>> Which "distributed linux configuration" do you mean? >>> >> >>I'd like to have the configuration and makefile in the same directory. > > I don't like to have it in the same directory. > >>Now the configuration is in a different directory. > > Yes, and that's a feature. You (or the board) can easily set > BR2_PACKAGE_LINUX_KCONFIG to anything you want. It was added for exactly > this purpose. > Again a misunderstading unfortunately. I am talking about the way buildroot configures linux in target/device/Config.in etc. I am not talking about the file which will be copied to the linux .config. So I would like to have: target/linux/Makefile.in target/linux/Config.in instead of target/linux.mk target/device/Config.in (which contains a lot of other stuff) >> >>The current linux.mk is much less flexible than the one I use. > > You keep saying this, ISTR. > What does not work currently as opposed to "yours"? > Did you try to use the currently existing one, recently? > My current tree is about 5 weeks old, and if improvements have been made, then the less the change... >>Once we have the linux in a good place, then I will submit >>my proposals to the mailing list. Best Regards Ulf Samuelsson ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-06 12:35 [Buildroot] What is the proper procedure to commit a patch? Ulf Samuelsson 2007-07-06 15:26 ` Bernhard Fischer @ 2007-07-06 15:55 ` Steven J. Hill 2007-07-06 21:10 ` Ulf Samuelsson 2007-07-07 10:06 ` [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) Ulf Samuelsson 2007-07-07 10:21 ` [Buildroot] What is the proper procedure to commit a patch? Bernhard Fischer 2 siblings, 2 replies; 25+ messages in thread From: Steven J. Hill @ 2007-07-06 15:55 UTC (permalink / raw) To: buildroot On Fri, Jul 06, 2007 at 02:35:32PM +0200, Ulf Samuelsson wrote: > Now, when I have access, I would like to understand the proper > procedure to add patches. > I echo all of Bernard's input. > * Update mtdutils (which is really old) > Please do not check in changes to this until running the patch by me. This package is critical for a lot of embedded systems and has been working well up to this point and there are no bugs in the bug tracker. > * Bump versions on a number of packages which has disappeared from their > download location. > (dash, rmp, l2tp, mpfr,mrouted, openntpd, portage, pppd,udev) > * Add TARGET_CFLAGS to all packages not having this > Would like to know if they lack TARGET_CFLAGS for a reason. > (acpid,berkleydb, hdparm, iostat,ltp-testsuite,memtester,netkitbase, > procps, python, sysklogd, tinyx,udhcp) > Again, please do not check in changes for the udev package either without letting me see the patch. This package is working well in production systems and bumping version just for the sake of getting latest and greatest is unnecessary unless bugs are being fixed. If the URL has changed to get to the source, then go ahead and check in a fix. I have not downloaded the current udev source in a while. Secondly, after I finish my next set of check-ins, TARGET_CFLAGS is NOT to be used in any package build files. It will automatically be used as shown in 'package/Makefile.in' as part of the CC, CPP, and CXX tools. This leaves the individual packages the ability to specify their own CFLAGS during their builds. Same things goes for the TARGET_LDFLAGS variable. It should not be used in package build files either. I have already checked those changes in. I also plan on doing an audit of the use of TARGET_CC which annoys the heck out of me. I plan on removing usage of that too. Cheers. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-06 15:55 ` Steven J. Hill @ 2007-07-06 21:10 ` Ulf Samuelsson 2007-07-07 10:06 ` [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) Ulf Samuelsson 1 sibling, 0 replies; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-06 21:10 UTC (permalink / raw) To: buildroot > On Fri, Jul 06, 2007 at 02:35:32PM +0200, Ulf Samuelsson wrote: >> Now, when I have access, I would like to understand the proper >> procedure to add patches. >> > I echo all of Bernard's input. > >> * Update mtdutils (which is really old) >> > Please do not check in changes to this until running the patch by > me. This package is critical for a lot of embedded systems and has > been working well up to this point and there are no bugs in the > bug tracker. This patch is actually done in such a way that the user can select to user a newer mtd, but the default is the original mtd, so it should not break anything. >> * Bump versions on a number of packages which has disappeared from their >> download location. >> (dash, rmp, l2tp, mpfr,mrouted, openntpd, portage, pppd,udev) >> * Add TARGET_CFLAGS to all packages not having this >> Would like to know if they lack TARGET_CFLAGS for a reason. >> (acpid,berkleydb, hdparm, iostat,ltp-testsuite,memtester,netkitbase, >> procps, python, sysklogd, tinyx,udhcp) >> > Again, please do not check in changes for the udev package either > without letting me see the patch. This package is working well in > production systems and bumping version just for the sake of getting > latest and greatest is unnecessary unless bugs are being fixed. If > the URL has changed to get to the source, then go ahead and check > in a fix. I have not downloaded the current udev source in a while. > It is broken since the download fails and moving to a new version will be one possible way of solving the problem. Another possible way is to have a backup repository if the original tarball is removed. This would need a $(WGET) script which knows several locations. I think the most important thing we should add to buildroot is the concept of distributions. I.E: allowing everyone can decide to "freeze" a certain package version but also select to use the latest version. I hope this would handle your needs as well as others. > Secondly, after I finish my next set of check-ins, TARGET_CFLAGS is > NOT to be used in any package build files. It will automatically be > used as shown in 'package/Makefile.in' as part of the CC, CPP, and > CXX tools. This leaves the individual packages the ability to specify > their own CFLAGS during their builds. Same things goes for the > TARGET_LDFLAGS variable. It should not be used in package build files > either. I have already checked those changes in. I also plan on doing > an audit of the use of TARGET_CC which annoys the heck out of me. I > plan on removing usage of that too. > No problems for my part. I would like that all packages are treated alike, and if someone differs then there should be a known reason why they differ. This is not the case at the moment. I sent in this suggestion about one year ago, and it was rejected without a good explanation, and over time most of the packages has been updated to use TARGET_CFLAGS. > Cheers. > > -Steve Best Regards Ulf Samuelsson ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-06 15:55 ` Steven J. Hill 2007-07-06 21:10 ` Ulf Samuelsson @ 2007-07-07 10:06 ` Ulf Samuelsson 2007-07-07 13:01 ` Bernhard Fischer 1 sibling, 1 reply; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-07 10:06 UTC (permalink / raw) To: buildroot >> * Update mtdutils (which is really old) >> > Please do not check in changes to this until running the patch by > me. This package is critical for a lot of embedded systems and has > been working well up to this point and there are no bugs in the > bug tracker. > Before looking at introducing my new version (as an option) I tried rebuilding the current svn and ran into a problem with mtd. When building for arm, the target mtdutils are built using the *host* compiler and stored in $(TARGET_DIR)/usr/sbin. When the arm-linux-uclibc-strip is invoked on "$(TARGET_DIR)/usr/sbin/flash_erase" compiled by gcc (not arm-linux-uclibc-gcc), the make fails. I think someone got it wrong in the "package/mtd/mtd.mk" which says $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc which should be: $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc I am using Gnu Make 3.81 on OpenSuSE 10.2 Looks to be a number of the packages that suffer from this problem. * argus * distcc * flex * kexec * l2tp * libevent * libusb * microcom * nano * netcat * procps * qte * qtopia4 * quagga * rsync * samba * thttpd * tinyx * usbutils * wget Anyone only using the x86 architecture, maybe would not see this problem. Anyone using something else will suffer. Suggest we apply the patch below to the packages above. Index: package/mtd/mtd.mk =================================================================== --- package/mtd/mtd.mk (revision 19014) +++ package/mtd/mtd.mk (arbetskopia) @@ -115,7 +115,7 @@ MTD_BUILD_TARGETS := $(addprefix $(MTD_DIR)/util/, $(MTD_TARGETS_y)) $(MTD_BUILD_TARGETS): $(MTD_DIR)/.unpacked - $(TARGET_CONFIGURE_OPTS) $(MAKE) CFLAGS="-I$(MTD_DIR)/include -I$(LINUX_HEADERS_DIR)/include" LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util + $(MAKE) $(TARGET_CONFIGURE_OPTS) CFLAGS="-I$(MTD_DIR)/include -I$(LINUX_HEADERS_DIR)/include" LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util MTD_TARGETS := $(addprefix $(TARGET_DIR)/usr/sbin/, $(MTD_TARGETS_y)) Best Regards Ulf Samuelsson ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-07 10:06 ` [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) Ulf Samuelsson @ 2007-07-07 13:01 ` Bernhard Fischer 2007-07-07 16:06 ` Ulf Samuelsson 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-07 13:01 UTC (permalink / raw) To: buildroot On Sat, Jul 07, 2007 at 12:06:09PM +0200, Ulf Samuelsson wrote: >>> * Update mtdutils (which is really old) >>> >> Please do not check in changes to this until running the patch by >> me. This package is critical for a lot of embedded systems and has >> been working well up to this point and there are no bugs in the >> bug tracker. >> > >Before looking at introducing my new version (as an option) >I tried rebuilding the current svn and ran into a problem with mtd. > >When building for arm, the target mtdutils are built using the *host* compiler >and stored in $(TARGET_DIR)/usr/sbin. > >When the arm-linux-uclibc-strip is invoked on >"$(TARGET_DIR)/usr/sbin/flash_erase" >compiled by gcc (not arm-linux-uclibc-gcc), the make fails. > >I think someone got it wrong in the "package/mtd/mtd.mk" which says > > $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc > >which should be: > > $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc yes, the latter is correct. Steven, please repair or elaborate. Also, not using the user's CFLAGS sound a little bit odd to me, given that after your change a package will *not* use the proper flags anymore. Think about a package that has CFLAGS = -O2 -fother-bloat in it's makefile. Now you changed it to be compiled as myarch-linux-uclibc-gcc -Os $USERFLAGS -O2 -fother-bloat which will end using -O2 rather than the correct -Os Previously we were overriding the package imposed default CFLAGS, which is the proper thing to do, IMO. What was the rational behind your change? TIA for elaborating.. ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-07 13:01 ` Bernhard Fischer @ 2007-07-07 16:06 ` Ulf Samuelsson 2007-07-07 17:29 ` Bernhard Fischer 0 siblings, 1 reply; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-07 16:06 UTC (permalink / raw) To: buildroot > >I think someone got it wrong in the "package/mtd/mtd.mk" which says > > > > $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc > > > >which should be: > > > > $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc > > yes, the latter is correct. Steven, please repair or elaborate. > Here are a set of patches to change the position of TARGET_CONFIGURE_OPTS. Please review and apply if you agree. Index: package/l2tp/l2tp.mk =================================================================== --- package/l2tp/l2tp.mk (revision 19021) +++ package/l2tp/l2tp.mk (arbetskopia) @@ -33,7 +33,7 @@ touch $(L2TP_DIR)/.unpacked $(L2TP_DIR)/$(L2TP_BINARY): $(L2TP_DIR)/.unpacked - $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(L2TP_DIR) CC=$(TARGET_CC) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(L2TP_DIR) CC=$(TARGET_CC) \ DFLAGS= \ OSFLAGS="-DLINUX -UUSE_KERNEL $(TARGET_CFLAGS) -USANITY" Index: package/mtd/mtd.mk =================================================================== --- package/mtd/mtd.mk (revision 19021) +++ package/mtd/mtd.mk (arbetskopia) @@ -115,7 +115,10 @@ MTD_BUILD_TARGETS := $(addprefix $(MTD_DIR)/util/, $(MTD_TARGETS_y)) $(MTD_BUILD_TARGETS): $(MTD_DIR)/.unpacked - $(TARGET_CONFIGURE_OPTS) $(MAKE) CFLAGS="-I$(MTD_DIR)/include -I $(LINUX_HEADERS_DIR)/include" LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util + $(MAKE) $(TARGET_CONFIGURE_OPTS) \ + CFLAGS="-I$(MTD_DIR)/include \ + -I$(LINUX_HEADERS_DIR)/include" \ + LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util MTD_TARGETS := $(addprefix $(TARGET_DIR)/usr/sbin/, $(MTD_TARGETS_y)) Index: package/qte/qte.mk =================================================================== --- package/qte/qte.mk (revision 19021) +++ package/qte/qte.mk (arbetskopia) @@ -222,18 +222,18 @@ $(QTE_QTE_LIB): $(QTE_QTE_DIR)/src-mt.mk export QTDIR=$(QTE_QTE_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ - $(TARGET_CONFIGURE_OPTS) $(MAKE) $(TARGET_CC) -C $(QTE_QTE_DIR) src-mt - $(TARGET_CONFIGURE_OPTS) $(MAKE) $(TARGET_CC) DESTDIR= $(TARGET_DIR)/lib -C $(QTE_QTE_DIR) src-mt + $(MAKE) $(TARGET_CONFIGURE_OPTS) $(TARGET_CC) -C $(QTE_QTE_DIR) src-mt + $(MAKE) $(TARGET_CONFIGURE_OPTS) $(TARGET_CC) DESTDIR= $(TARGET_DIR)/lib -C $(QTE_QTE_DIR) src-mt # ... and make sure it actually built... grrr... make deep-deep-deep makefile recursion for this habit test -f $@ $(QTE_QTOPIA_FILE): $(QTE_QTOPIA_DIR)/.configured export QTDIR=$(QTE_QT3_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) $(QTE_QTOPIA_IFILE): $(QTE_QTOPIA_FILE) export QTDIR=$(QTE_QT3_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) install PREFIX=$(TARGET_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) install PREFIX=$(TARGET_DIR) qte:: $(QTE_QTE_LIB) Index: package/kexec/kexec.mk =================================================================== --- package/kexec/kexec.mk (revision 19021) +++ package/kexec/kexec.mk (arbetskopia) @@ -53,7 +53,7 @@ touch $@ $(KEXEC_DIR)/objdir-$(GNU_TARGET_NAME)/build/sbin/$(KEXEC_BINARY): $(KEXEC_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(KEXEC_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(KEXEC_DIR) touch -c $@ $(TARGET_DIR)/$(KEXEC_TARGET_BINARY): $(KEXEC_DIR)/objdir-$(GNU_TARGET_NAME)/build/sbin/$(KEXEC_BINARY) Index: package/usbutils/usbutils.mk =================================================================== --- package/usbutils/usbutils.mk (revision 19021) +++ package/usbutils/usbutils.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(USBUTILS_DIR)/.configured $(USBUTILS_DIR)/$(USBUTILS_BINARY): $(USBUTILS_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(USBUTILS_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(USBUTILS_DIR) $(TARGET_DIR)/$(USBUTILS_TARGET_BINARY): $(USBUTILS_DIR)/$(USBUTILS_BINARY) $(MAKE) -C $(USBUTILS_DIR) DESTDIR=$(TARGET_DIR) install Index: package/netcat/netcat.mk =================================================================== --- package/netcat/netcat.mk (revision 19021) +++ package/netcat/netcat.mk (arbetskopia) @@ -35,7 +35,7 @@ $(NETCAT_DIR)/$(NETCAT_BINARY): $(NETCAT_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(NETCAT_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(NETCAT_DIR) $(TARGET_DIR)/$(NETCAT_TARGET_BINARY): $(NETCAT_DIR)/$(NETCAT_BINARY) install -D $(NETCAT_DIR)/$(NETCAT_BINARY) $(TARGET_DIR)/$(NETCAT_TARGET_BINARY) Index: package/tinyx/tinyx.mk =================================================================== --- package/tinyx/tinyx.mk (revision 19021) +++ package/tinyx/tinyx.mk (arbetskopia) @@ -85,7 +85,7 @@ rm -f $(TINYX_BINX)/Xfbdev #make World CROSSCOMPILEFLAGS="CROSSCOMPILEDIR=<cross compiler dir>"; #( cd $(TINYX_DIR) ; $(MAKE) World CROSSCOMPILEFLAGS="CROSSCOMPILEDIR= $(STAGING_DIR)/bin" ) - #( cd $(TINYX_DIR) ; $(TARGET_CONFIGURE_OPTS) $(MAKE) World ) + #( cd $(TINYX_DIR) ; $(MAKE) $(TARGET_CONFIGURE_OPTS) World ) # #mv $(TINYX_DIR)/Makefile $(TINYX_DIR)/Makefile.xxxx #echo "AS=$(TARGET_CROSS)as" > $(TINYX_DIR)/Makefile Index: package/rsync/rsync.mk =================================================================== --- package/rsync/rsync.mk (revision 19021) +++ package/rsync/rsync.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(RSYNC_DIR)/.configured $(RSYNC_DIR)/$(RSYNC_BINARY): $(RSYNC_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(RSYNC_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(RSYNC_DIR) $(TARGET_DIR)/$(RSYNC_TARGET_BINARY): $(RSYNC_DIR)/$(RSYNC_BINARY) install -D $(RSYNC_DIR)/$(RSYNC_BINARY) $(TARGET_DIR)/$(RSYNC_TARGET_BINARY) Index: package/samba/samba.mk =================================================================== --- package/samba/samba.mk (revision 19021) +++ package/samba/samba.mk (arbetskopia) @@ -46,7 +46,7 @@ touch $(SAMBA_DIR)/.configured $(SAMBA_DIR)/$(SAMBA_BINARY): $(SAMBA_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(SAMBA_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(SAMBA_DIR) SAMBA_TARGETS_ := SAMBA_TARGETS_y := @@ -79,7 +79,7 @@ SAMBA_TARGETS_$(BR2_PACKAGE_SAMBA_WBINFO) += usr/bin/wbinfo $(TARGET_DIR)/$(SAMBA_TARGET_BINARY): $(SAMBA_DIR)/$(SAMBA_BINARY) - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) \ prefix="${TARGET_DIR}/usr" \ BASEDIR="${TARGET_DIR}/usr" \ SBINDIR="${TARGET_DIR}/usr/sbin" \ Index: package/flex/flex.mk =================================================================== --- package/flex/flex.mk (revision 19021) +++ package/flex/flex.mk (arbetskopia) @@ -58,7 +58,7 @@ touch $@ $(FLEX_DIR)/$(FLEX_BINARY): $(FLEX_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(FLEX_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(FLEX_DIR) $(TARGET_DIR)/$(FLEX_TARGET_BINARY): $(FLEX_DIR)/$(FLEX_BINARY) $(MAKE1) \ Index: package/quagga/quagga.mk =================================================================== --- package/quagga/quagga.mk (revision 19021) +++ package/quagga/quagga.mk (arbetskopia) @@ -152,7 +152,7 @@ touch $@ $(QUAGGA_BINARY): $(QUAGGA_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QUAGGA_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(QUAGGA_DIR) $(TARGET_DIR)/usr/sbin/$(QUAGGA_TARGET_BINARY): $(QUAGGA_BINARY) $(MAKE) DESTDIR=$(TARGET_DIR) -C $(QUAGGA_DIR) install Index: package/thttpd/thttpd.mk =================================================================== --- package/thttpd/thttpd.mk (revision 19021) +++ package/thttpd/thttpd.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(THTTPD_DIR)/.configured $(THTTPD_DIR)/$(THTTPD_BINARY): $(THTTPD_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(THTTPD_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(THTTPD_DIR) $(TARGET_DIR)/$(THTTPD_TARGET_BINARY): $(THTTPD_DIR)/$(THTTPD_BINARY) install -D $(THTTPD_DIR)/$(THTTPD_BINARY) $(TARGET_DIR)/$(THTTPD_TARGET_BINARY) Index: package/libevent/libevent.mk =================================================================== --- package/libevent/libevent.mk (revision 19021) +++ package/libevent/libevent.mk (arbetskopia) @@ -37,7 +37,7 @@ touch $@ $(LIBEVENT_DIR)/$(LIBEVENT_BINARY): $(LIBEVENT_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(LIBEVENT_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(LIBEVENT_DIR) $(STAGING_DIR)/$(LIBEVENT_TARGET_BINARY): $(LIBEVENT_DIR)/$(LIBEVENT_BINARY) $(MAKE) -C $(LIBEVENT_DIR) DESTDIR=$(STAGING_DIR) install Index: package/microcom/microcom.mk =================================================================== --- package/microcom/microcom.mk (revision 19021) +++ package/microcom/microcom.mk (arbetskopia) @@ -51,7 +51,7 @@ $(CFLAGS_WHOLE_PROGRAM) -o $@ $(wildcard $(MICROCOM_DIR)/*.c); \ ) else - $(TARGET_CONFIGURE_OPTS) CFLAGS="$(TARGET_CFLAGS)" $(MAKE) -C $(MICROCOM_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CFLAGS="$(TARGET_CFLAGS)" -C $(MICROCOM_DIR) endif $(STRIP) -s $@ Index: package/wget/wget.mk =================================================================== --- package/wget/wget.mk (revision 19021) +++ package/wget/wget.mk (arbetskopia) @@ -36,7 +36,7 @@ touch $(WGET_DIR)/.configured $(WGET_DIR)/$(WGET_BINARY): $(WGET_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(WGET_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(WGET_DIR) $(TARGET_DIR)/$(WGET_TARGET_BINARY): $(WGET_DIR)/$(WGET_BINARY) install -D $(WGET_DIR)/$(WGET_BINARY) $(TARGET_DIR)/$(WGET_TARGET_BINARY) Index: package/argus/argus.mk =================================================================== --- package/argus/argus.mk (revision 19021) +++ package/argus/argus.mk (arbetskopia) @@ -45,7 +45,7 @@ touch $@ $(ARGUS_DIR)/$(ARGUS_BINARY): $(ARGUS_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(ARGUS_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(ARGUS_DIR) $(TARGET_DIR)/$(ARGUS_TARGET_BINARY): $(ARGUS_DIR)/$(ARGUS_BINARY) cp -dpf $(ARGUS_DIR)/$(ARGUS_BINARY) $@ Index: package/libusb/libusb.mk =================================================================== --- package/libusb/libusb.mk (revision 19021) +++ package/libusb/libusb.mk (arbetskopia) @@ -36,7 +36,7 @@ touch $(LIBUSB_DIR)/.configured $(STAGING_DIR)/$(LIBUSB_BINARY): $(LIBUSB_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(LIBUSB_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(LIBUSB_DIR) $(MAKE) -C $(LIBUSB_DIR) DESTDIR=$(STAGING_DIR) install $(TARGET_DIR)/$(LIBUSB_BINARY): $(STAGING_DIR)/$(LIBUSB_BINARY) Index: package/qtopia4/qtopia4.mk =================================================================== --- package/qtopia4/qtopia4.mk (revision 19021) +++ package/qtopia4/qtopia4.mk (arbetskopia) @@ -161,7 +161,7 @@ touch $(QTOPIA4_TARGET_DIR)/.configured $(QTOPIA4_TARGET_DIR)/lib/libQtCore.so.$(QTOPIA4_VER): $(QTOPIA4_TARGET_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) \ -C $(QTOPIA4_TARGET_DIR) sub-src $(STAGING_DIR)/usr/lib/libQtCore.so.$(QTOPIA4_VER): $(QTOPIA4_TARGET_DIR)/lib/libQtCore.so.$(QTOPIA4_VER) Index: package/nano/nano.mk =================================================================== --- package/nano/nano.mk (revision 19021) +++ package/nano/nano.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(NANO_DIR)/.configured $(NANO_DIR)/$(NANO_BINARY): $(NANO_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(NANO_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(NANO_DIR) $(TARGET_DIR)/$(NANO_TARGET_BINARY): $(NANO_DIR)/$(NANO_BINARY) install -D $(NANO_DIR)/$(NANO_BINARY) $(TARGET_DIR)/$(NANO_TARGET_BINARY) Index: package/procps/procps.mk =================================================================== --- package/procps/procps.mk (revision 19021) +++ package/procps/procps.mk (arbetskopia) @@ -22,7 +22,7 @@ $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(PROCPS_DIR) $(TARGET_DIR)/$(PROCPS_TARGET_BINARY): $(PROCPS_DIR)/$(PROCPS_BINARY) - $(TARGET_CONFIGURE_OPTS) $(MAKE) DESTDIR=$(TARGET_DIR) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) DESTDIR=$(TARGET_DIR) \ install='install -D' -C $(PROCPS_DIR) lib64=/lib \ ldconfig='/bin/true' install rm -Rf $(TARGET_DIR)/usr/share/man Index: package/distcc/distcc.mk =================================================================== --- package/distcc/distcc.mk (revision 19021) +++ package/distcc/distcc.mk (arbetskopia) @@ -45,7 +45,7 @@ touch $(DISTCC_DIR)/.configured $(DISTCC_DIR)/$(DISTCC_BINARY): $(DISTCC_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(DISTCC_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(DISTCC_DIR) $(TARGET_DIR)/$(DISTCC_TARGET_BINARY): $(DISTCC_DIR)/$(DISTCC_BINARY) install -D $(DISTCC_DIR)/$(DISTCC_BINARY)d $(TARGET_DIR)/$(DISTCC_TARGET_BINARY)d Best Regards, Ulf Samuelsson ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-07 16:06 ` Ulf Samuelsson @ 2007-07-07 17:29 ` Bernhard Fischer 2007-07-07 19:37 ` Ulf Samuelsson 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-07 17:29 UTC (permalink / raw) To: buildroot On Sat, Jul 07, 2007 at 06:06:23PM +0200, Ulf Samuelsson wrote: >> >I think someone got it wrong in the "package/mtd/mtd.mk" which says >> > >> > $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc >> > >> >which should be: >> > >> > $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc >> >> yes, the latter is correct. Steven, please repair or elaborate. >> > >Here are a set of patches to change the position of >TARGET_CONFIGURE_OPTS. >Please review and apply if you agree. > > > >Index: package/l2tp/l2tp.mk >=================================================================== >--- package/l2tp/l2tp.mk (revision 19021) >+++ package/l2tp/l2tp.mk (arbetskopia) >@@ -33,7 +33,7 @@ > touch $(L2TP_DIR)/.unpacked > > $(L2TP_DIR)/$(L2TP_BINARY): $(L2TP_DIR)/.unpacked >- $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(L2TP_DIR) CC=$(TARGET_CC) \ >+ $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(L2TP_DIR) CC=$(TARGET_CC) \ passing CC is superfluous > DFLAGS= \ > OSFLAGS="-DLINUX -UUSE_KERNEL $(TARGET_CFLAGS) -USANITY" > >Index: package/mtd/mtd.mk >=================================================================== >--- package/mtd/mtd.mk (revision 19021) >+++ package/mtd/mtd.mk (arbetskopia) >@@ -115,7 +115,10 @@ > MTD_BUILD_TARGETS := $(addprefix $(MTD_DIR)/util/, $(MTD_TARGETS_y)) > > $(MTD_BUILD_TARGETS): $(MTD_DIR)/.unpacked >- $(TARGET_CONFIGURE_OPTS) $(MAKE) CFLAGS="-I$(MTD_DIR)/include -I >$(LINUX_HEADERS_DIR)/include" LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util >+ $(MAKE) $(TARGET_CONFIGURE_OPTS) \ >+ CFLAGS="-I$(MTD_DIR)/include \ >+ -I$(LINUX_HEADERS_DIR)/include" \ >+ LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util > > MTD_TARGETS := $(addprefix $(TARGET_DIR)/usr/sbin/, $(MTD_TARGETS_y)) > >Index: package/qte/qte.mk >=================================================================== >--- package/qte/qte.mk (revision 19021) >+++ package/qte/qte.mk (arbetskopia) >@@ -222,18 +222,18 @@ > > $(QTE_QTE_LIB): $(QTE_QTE_DIR)/src-mt.mk > export QTDIR=$(QTE_QTE_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export >PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ >- $(TARGET_CONFIGURE_OPTS) $(MAKE) $(TARGET_CC) -C $(QTE_QTE_DIR) src-mt >- $(TARGET_CONFIGURE_OPTS) $(MAKE) $(TARGET_CC) DESTDIR= >$(TARGET_DIR)/lib -C $(QTE_QTE_DIR) src-mt >+ $(MAKE) $(TARGET_CONFIGURE_OPTS) $(TARGET_CC) -C $(QTE_QTE_DIR) src-mt >+ $(MAKE) $(TARGET_CONFIGURE_OPTS) $(TARGET_CC) DESTDIR= passing TARGET_CC is superfluous >$(TARGET_DIR)/lib -C $(QTE_QTE_DIR) src-mt > # ... and make sure it actually built... grrr... make deep-deep-deep >makefile recursion for this habit > test -f $@ > > $(QTE_QTOPIA_FILE): $(QTE_QTOPIA_DIR)/.configured > export QTDIR=$(QTE_QT3_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export >PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ >- $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) >+ $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) superfluous CC > > $(QTE_QTOPIA_IFILE): $(QTE_QTOPIA_FILE) > export QTDIR=$(QTE_QT3_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export >PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ >- $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) >install PREFIX=$(TARGET_DIR) >+ $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) >install PREFIX=$(TARGET_DIR) superfluous CC > > > qte:: $(QTE_QTE_LIB) >Index: package/kexec/kexec.mk >=================================================================== >--- package/kexec/kexec.mk (revision 19021) >+++ package/kexec/kexec.mk (arbetskopia) >@@ -53,7 +53,7 @@ > touch $@ > > $(KEXEC_DIR)/objdir-$(GNU_TARGET_NAME)/build/sbin/$(KEXEC_BINARY): >$(KEXEC_DIR)/.configured >- $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(KEXEC_DIR) >+ $(MAKE) $(TARGET_CONFIGURE_OPTS) CC=$(TARGET_CC) -C $(KEXEC_DIR) superfluous CC [snip.. you get the idea] ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-07 17:29 ` Bernhard Fischer @ 2007-07-07 19:37 ` Ulf Samuelsson 2007-07-07 21:16 ` Bernhard Fischer 0 siblings, 1 reply; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-07 19:37 UTC (permalink / raw) To: buildroot l?r 2007-07-07 klockan 19:29 +0200 skrev Bernhard Fischer: > On Sat, Jul 07, 2007 at 06:06:23PM +0200, Ulf Samuelsson wrote: > >> >I think someone got it wrong in the "package/mtd/mtd.mk" which says > >> > > >> > $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc > >> > > >> >which should be: > >> > > >> > $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc > >> > >> yes, the latter is correct. Steven, please repair or elaborate. > >> > > > >Here are a set of patches to change the position of > >TARGET_CONFIGURE_OPTS. > >Please review and apply if you agree. > > > > Here we go again! Index: package/l2tp/l2tp.mk =================================================================== --- package/l2tp/l2tp.mk (revision 19021) +++ package/l2tp/l2tp.mk (arbetskopia) @@ -33,7 +33,7 @@ touch $(L2TP_DIR)/.unpacked $(L2TP_DIR)/$(L2TP_BINARY): $(L2TP_DIR)/.unpacked - $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(L2TP_DIR) CC=$(TARGET_CC) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(L2TP_DIR) \ DFLAGS= \ OSFLAGS="-DLINUX -UUSE_KERNEL $(TARGET_CFLAGS) -USANITY" Index: package/mtd/mtd.mk =================================================================== --- package/mtd/mtd.mk (revision 19021) +++ package/mtd/mtd.mk (arbetskopia) @@ -115,7 +115,10 @@ MTD_BUILD_TARGETS := $(addprefix $(MTD_DIR)/util/, $(MTD_TARGETS_y)) $(MTD_BUILD_TARGETS): $(MTD_DIR)/.unpacked - $(TARGET_CONFIGURE_OPTS) $(MAKE) CFLAGS="-I$(MTD_DIR)/include -I $(LINUX_HEADERS_DIR)/include" LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util + $(MAKE) $(TARGET_CONFIGURE_OPTS) \ + CFLAGS="-I$(MTD_DIR)/include \ + -I$(LINUX_HEADERS_DIR)/include" \ + LINUXDIR=$(LINUX_DIR) -C $(MTD_DIR)/util MTD_TARGETS := $(addprefix $(TARGET_DIR)/usr/sbin/, $(MTD_TARGETS_y)) Index: package/qte/qte.mk =================================================================== --- package/qte/qte.mk (revision 19021) +++ package/qte/qte.mk (arbetskopia) @@ -222,18 +222,18 @@ $(QTE_QTE_LIB): $(QTE_QTE_DIR)/src-mt.mk export QTDIR=$(QTE_QTE_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ - $(TARGET_CONFIGURE_OPTS) $(MAKE) $(TARGET_CC) -C $(QTE_QTE_DIR) src-mt - $(TARGET_CONFIGURE_OPTS) $(MAKE) $(TARGET_CC) DESTDIR= $(TARGET_DIR)/lib -C $(QTE_QTE_DIR) src-mt + $(MAKE) $(TARGET_CONFIGURE_OPTS) $(TARGET_CC) -C $(QTE_QTE_DIR) src-mt + $(MAKE) $(TARGET_CONFIGURE_OPTS) $(TARGET_CC) DESTDIR= $(TARGET_DIR)/lib -C $(QTE_QTE_DIR) src-mt # ... and make sure it actually built... grrr... make deep-deep-deep makefile recursion for this habit test -f $@ $(QTE_QTOPIA_FILE): $(QTE_QTOPIA_DIR)/.configured export QTDIR=$(QTE_QT3_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(QTE_QTOPIA_DIR) $(QTE_QTOPIA_IFILE): $(QTE_QTOPIA_FILE) export QTDIR=$(QTE_QT3_DIR); export QPEDIR=$(QTE_QTOPIA_DIR); export PATH=$(STAGING_DIR)/bin:$$QTDIR/bin:$$PATH; \ - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QTE_QTOPIA_DIR) install PREFIX=$(TARGET_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(QTE_QTOPIA_DIR) install PREFIX= $(TARGET_DIR) qte:: $(QTE_QTE_LIB) Index: package/kexec/kexec.mk =================================================================== --- package/kexec/kexec.mk (revision 19021) +++ package/kexec/kexec.mk (arbetskopia) @@ -53,7 +53,7 @@ touch $@ $(KEXEC_DIR)/objdir-$(GNU_TARGET_NAME)/build/sbin/$(KEXEC_BINARY): $(KEXEC_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(KEXEC_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(KEXEC_DIR) touch -c $@ $(TARGET_DIR)/$(KEXEC_TARGET_BINARY): $(KEXEC_DIR)/objdir-$(GNU_TARGET_NAME)/build/sbin/$(KEXEC_BINARY) Index: package/usbutils/usbutils.mk =================================================================== --- package/usbutils/usbutils.mk (revision 19021) +++ package/usbutils/usbutils.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(USBUTILS_DIR)/.configured $(USBUTILS_DIR)/$(USBUTILS_BINARY): $(USBUTILS_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(USBUTILS_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(USBUTILS_DIR) $(TARGET_DIR)/$(USBUTILS_TARGET_BINARY): $(USBUTILS_DIR)/$(USBUTILS_BINARY) $(MAKE) -C $(USBUTILS_DIR) DESTDIR=$(TARGET_DIR) install Index: package/netcat/netcat.mk =================================================================== --- package/netcat/netcat.mk (revision 19021) +++ package/netcat/netcat.mk (arbetskopia) @@ -35,7 +35,7 @@ $(NETCAT_DIR)/$(NETCAT_BINARY): $(NETCAT_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(NETCAT_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(NETCAT_DIR) $(TARGET_DIR)/$(NETCAT_TARGET_BINARY): $(NETCAT_DIR)/$(NETCAT_BINARY) install -D $(NETCAT_DIR)/$(NETCAT_BINARY) $(TARGET_DIR)/$(NETCAT_TARGET_BINARY) Index: package/tinyx/tinyx.mk =================================================================== --- package/tinyx/tinyx.mk (revision 19021) +++ package/tinyx/tinyx.mk (arbetskopia) @@ -85,7 +85,7 @@ rm -f $(TINYX_BINX)/Xfbdev #make World CROSSCOMPILEFLAGS="CROSSCOMPILEDIR=<cross compiler dir>"; #( cd $(TINYX_DIR) ; $(MAKE) World CROSSCOMPILEFLAGS="CROSSCOMPILEDIR= $(STAGING_DIR)/bin" ) - #( cd $(TINYX_DIR) ; $(TARGET_CONFIGURE_OPTS) $(MAKE) World ) + #( cd $(TINYX_DIR) ; $(MAKE) $(TARGET_CONFIGURE_OPTS) World ) # #mv $(TINYX_DIR)/Makefile $(TINYX_DIR)/Makefile.xxxx #echo "AS=$(TARGET_CROSS)as" > $(TINYX_DIR)/Makefile Index: package/rsync/rsync.mk =================================================================== --- package/rsync/rsync.mk (revision 19021) +++ package/rsync/rsync.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(RSYNC_DIR)/.configured $(RSYNC_DIR)/$(RSYNC_BINARY): $(RSYNC_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(RSYNC_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(RSYNC_DIR) $(TARGET_DIR)/$(RSYNC_TARGET_BINARY): $(RSYNC_DIR)/$(RSYNC_BINARY) install -D $(RSYNC_DIR)/$(RSYNC_BINARY) $(TARGET_DIR)/$(RSYNC_TARGET_BINARY) Index: package/samba/samba.mk =================================================================== --- package/samba/samba.mk (revision 19021) +++ package/samba/samba.mk (arbetskopia) @@ -46,7 +46,7 @@ touch $(SAMBA_DIR)/.configured $(SAMBA_DIR)/$(SAMBA_BINARY): $(SAMBA_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(SAMBA_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(SAMBA_DIR) SAMBA_TARGETS_ := SAMBA_TARGETS_y := @@ -79,7 +79,7 @@ SAMBA_TARGETS_$(BR2_PACKAGE_SAMBA_WBINFO) += usr/bin/wbinfo $(TARGET_DIR)/$(SAMBA_TARGET_BINARY): $(SAMBA_DIR)/$(SAMBA_BINARY) - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) \ prefix="${TARGET_DIR}/usr" \ BASEDIR="${TARGET_DIR}/usr" \ SBINDIR="${TARGET_DIR}/usr/sbin" \ Index: package/flex/flex.mk =================================================================== --- package/flex/flex.mk (revision 19021) +++ package/flex/flex.mk (arbetskopia) @@ -58,7 +58,7 @@ touch $@ $(FLEX_DIR)/$(FLEX_BINARY): $(FLEX_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(FLEX_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(FLEX_DIR) $(TARGET_DIR)/$(FLEX_TARGET_BINARY): $(FLEX_DIR)/$(FLEX_BINARY) $(MAKE1) \ Index: package/quagga/quagga.mk =================================================================== --- package/quagga/quagga.mk (revision 19021) +++ package/quagga/quagga.mk (arbetskopia) @@ -152,7 +152,7 @@ touch $@ $(QUAGGA_BINARY): $(QUAGGA_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(QUAGGA_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(QUAGGA_DIR) $(TARGET_DIR)/usr/sbin/$(QUAGGA_TARGET_BINARY): $(QUAGGA_BINARY) $(MAKE) DESTDIR=$(TARGET_DIR) -C $(QUAGGA_DIR) install Index: package/thttpd/thttpd.mk =================================================================== --- package/thttpd/thttpd.mk (revision 19021) +++ package/thttpd/thttpd.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(THTTPD_DIR)/.configured $(THTTPD_DIR)/$(THTTPD_BINARY): $(THTTPD_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(THTTPD_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(THTTPD_DIR) $(TARGET_DIR)/$(THTTPD_TARGET_BINARY): $(THTTPD_DIR)/$(THTTPD_BINARY) install -D $(THTTPD_DIR)/$(THTTPD_BINARY) $(TARGET_DIR)/$(THTTPD_TARGET_BINARY) Index: package/libevent/libevent.mk =================================================================== --- package/libevent/libevent.mk (revision 19021) +++ package/libevent/libevent.mk (arbetskopia) @@ -37,7 +37,7 @@ touch $@ $(LIBEVENT_DIR)/$(LIBEVENT_BINARY): $(LIBEVENT_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(LIBEVENT_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(LIBEVENT_DIR) $(STAGING_DIR)/$(LIBEVENT_TARGET_BINARY): $(LIBEVENT_DIR)/$(LIBEVENT_BINARY) $(MAKE) -C $(LIBEVENT_DIR) DESTDIR=$(STAGING_DIR) install Index: package/microcom/microcom.mk =================================================================== --- package/microcom/microcom.mk (revision 19021) +++ package/microcom/microcom.mk (arbetskopia) @@ -51,7 +51,7 @@ $(CFLAGS_WHOLE_PROGRAM) -o $@ $(wildcard $(MICROCOM_DIR)/*.c); \ ) else - $(TARGET_CONFIGURE_OPTS) CFLAGS="$(TARGET_CFLAGS)" $(MAKE) -C $(MICROCOM_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) CFLAGS="$(TARGET_CFLAGS)" -C $(MICROCOM_DIR) endif $(STRIP) -s $@ Index: package/wget/wget.mk =================================================================== --- package/wget/wget.mk (revision 19021) +++ package/wget/wget.mk (arbetskopia) @@ -36,7 +36,7 @@ touch $(WGET_DIR)/.configured $(WGET_DIR)/$(WGET_BINARY): $(WGET_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(WGET_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(WGET_DIR) $(TARGET_DIR)/$(WGET_TARGET_BINARY): $(WGET_DIR)/$(WGET_BINARY) install -D $(WGET_DIR)/$(WGET_BINARY) $(TARGET_DIR)/$(WGET_TARGET_BINARY) Index: package/argus/argus.mk =================================================================== --- package/argus/argus.mk (revision 19021) +++ package/argus/argus.mk (arbetskopia) @@ -45,7 +45,7 @@ touch $@ $(ARGUS_DIR)/$(ARGUS_BINARY): $(ARGUS_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(ARGUS_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(ARGUS_DIR) $(TARGET_DIR)/$(ARGUS_TARGET_BINARY): $(ARGUS_DIR)/$(ARGUS_BINARY) cp -dpf $(ARGUS_DIR)/$(ARGUS_BINARY) $@ Index: package/libusb/libusb.mk =================================================================== --- package/libusb/libusb.mk (revision 19021) +++ package/libusb/libusb.mk (arbetskopia) @@ -36,7 +36,7 @@ touch $(LIBUSB_DIR)/.configured $(STAGING_DIR)/$(LIBUSB_BINARY): $(LIBUSB_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(LIBUSB_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(LIBUSB_DIR) $(MAKE) -C $(LIBUSB_DIR) DESTDIR=$(STAGING_DIR) install $(TARGET_DIR)/$(LIBUSB_BINARY): $(STAGING_DIR)/$(LIBUSB_BINARY) Index: package/qtopia4/qtopia4.mk =================================================================== --- package/qtopia4/qtopia4.mk (revision 19021) +++ package/qtopia4/qtopia4.mk (arbetskopia) @@ -161,7 +161,7 @@ touch $(QTOPIA4_TARGET_DIR)/.configured $(QTOPIA4_TARGET_DIR)/lib/libQtCore.so.$(QTOPIA4_VER): $(QTOPIA4_TARGET_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) \ -C $(QTOPIA4_TARGET_DIR) sub-src $(STAGING_DIR)/usr/lib/libQtCore.so.$(QTOPIA4_VER): $(QTOPIA4_TARGET_DIR)/lib/libQtCore.so.$(QTOPIA4_VER) Index: package/nano/nano.mk =================================================================== --- package/nano/nano.mk (revision 19021) +++ package/nano/nano.mk (arbetskopia) @@ -35,7 +35,7 @@ touch $(NANO_DIR)/.configured $(NANO_DIR)/$(NANO_BINARY): $(NANO_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(NANO_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(NANO_DIR) $(TARGET_DIR)/$(NANO_TARGET_BINARY): $(NANO_DIR)/$(NANO_BINARY) install -D $(NANO_DIR)/$(NANO_BINARY) $(TARGET_DIR)/$(NANO_TARGET_BINARY) Index: package/procps/procps.mk =================================================================== --- package/procps/procps.mk (revision 19021) +++ package/procps/procps.mk (arbetskopia) @@ -22,7 +22,7 @@ $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(PROCPS_DIR) $(TARGET_DIR)/$(PROCPS_TARGET_BINARY): $(PROCPS_DIR)/$(PROCPS_BINARY) - $(TARGET_CONFIGURE_OPTS) $(MAKE) DESTDIR=$(TARGET_DIR) \ + $(MAKE) $(TARGET_CONFIGURE_OPTS) DESTDIR=$(TARGET_DIR) \ install='install -D' -C $(PROCPS_DIR) lib64=/lib \ ldconfig='/bin/true' install rm -Rf $(TARGET_DIR)/usr/share/man Index: package/distcc/distcc.mk =================================================================== --- package/distcc/distcc.mk (revision 19021) +++ package/distcc/distcc.mk (arbetskopia) @@ -45,7 +45,7 @@ touch $(DISTCC_DIR)/.configured $(DISTCC_DIR)/$(DISTCC_BINARY): $(DISTCC_DIR)/.configured - $(TARGET_CONFIGURE_OPTS) $(MAKE) CC=$(TARGET_CC) -C $(DISTCC_DIR) + $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(DISTCC_DIR) $(TARGET_DIR)/$(DISTCC_TARGET_BINARY): $(DISTCC_DIR)/$(DISTCC_BINARY) install -D $(DISTCC_DIR)/$(DISTCC_BINARY)d $(TARGET_DIR)/$(DISTCC_TARGET_BINARY)d Best Regards Ulf Samuelsson -------------- next part -------------- A non-text attachment was scrubbed... Name: TARGET_CONFIGURE_OPTS-2.patch Type: text/x-patch Size: 12722 bytes Desc: not available Url : http://busybox.net/lists/buildroot/attachments/20070707/53ca13af/attachment-0001.bin ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-07 19:37 ` Ulf Samuelsson @ 2007-07-07 21:16 ` Bernhard Fischer 2007-07-07 22:49 ` Ulf Samuelsson 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-07 21:16 UTC (permalink / raw) To: buildroot On Sat, Jul 07, 2007 at 09:37:05PM +0200, Ulf Samuelsson wrote: >l?r 2007-07-07 klockan 19:29 +0200 skrev Bernhard Fischer: >> On Sat, Jul 07, 2007 at 06:06:23PM +0200, Ulf Samuelsson wrote: >> >> >I think someone got it wrong in the "package/mtd/mtd.mk" which says >> >> > >> >> > $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc >> >> > >> >> >which should be: >> >> > >> >> > $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc >> >> >> >> yes, the latter is correct. Steven, please repair or elaborate. >> >> >> > >> >Here are a set of patches to change the position of >> >TARGET_CONFIGURE_OPTS. >> >Please review and apply if you agree. >> > >> > > >Here we go again! I just replied to this, didn't i? Ulf, two minor points. 1) Version your patches, please. This mail had an TARGET_CONFIGURE_OPTS-2.patch and the one i just replied to had the same version? At least the patch had the same name.. 2) don't send patches both inline and as an attachment, it's inconvenient (and redundant IMHO). (The 'CFT,PATCH' style from earlier today works for the majority of clients) ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-07 21:16 ` Bernhard Fischer @ 2007-07-07 22:49 ` Ulf Samuelsson 2007-07-09 8:25 ` Bernhard Fischer 0 siblings, 1 reply; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-07 22:49 UTC (permalink / raw) To: buildroot > On Sat, Jul 07, 2007 at 09:37:05PM +0200, Ulf Samuelsson wrote: >>l?r 2007-07-07 klockan 19:29 +0200 skrev Bernhard Fischer: >>> On Sat, Jul 07, 2007 at 06:06:23PM +0200, Ulf Samuelsson wrote: >>> >> >I think someone got it wrong in the "package/mtd/mtd.mk" which says >>> >> > >>> >> > $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc >>> >> > >>> >> >which should be: >>> >> > >>> >> > $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc >>> >> >>> >> yes, the latter is correct. Steven, please repair or elaborate. >>> >> >>> > >>> >Here are a set of patches to change the position of >>> >TARGET_CONFIGURE_OPTS. >>> >Please review and apply if you agree. >>> > >>> > >> Stephen, can you pls review the mtd part of this patch ASAP, since this breaks the build for ARM (and possibly all non-x86). Pls commit (or ack my commit) if OK. Best Regards Ulf Samuelsson ulf at atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57 Technical support when I am not available: AT90 AVR Applications Group: mailto:avr at atmel.com AT91 ARM Applications Group: mailto:at91support at atmel.com AVR32 Applications Group mailto:avr32 at atmel.com http://www.avrfreaks.net/; http://avr32linux.org/ http://www.at91.com/ ; ftp://at91dist:distrib at 81.80.104.162/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-07 22:49 ` Ulf Samuelsson @ 2007-07-09 8:25 ` Bernhard Fischer 2007-07-09 9:21 ` Bernhard Fischer 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-09 8:25 UTC (permalink / raw) To: buildroot On Sun, Jul 08, 2007 at 12:49:20AM +0200, Ulf Samuelsson wrote: >> On Sat, Jul 07, 2007 at 09:37:05PM +0200, Ulf Samuelsson wrote: >>>l?r 2007-07-07 klockan 19:29 +0200 skrev Bernhard Fischer: >>>> On Sat, Jul 07, 2007 at 06:06:23PM +0200, Ulf Samuelsson wrote: >>>> >> >I think someone got it wrong in the "package/mtd/mtd.mk" which says >>>> >> > >>>> >> > $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc >>>> >> > >>>> >> >which should be: >>>> >> > >>>> >> > $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc >>>> >> >>>> >> yes, the latter is correct. Steven, please repair or elaborate. >>>> >> >>>> > >>>> >Here are a set of patches to change the position of >>>> >TARGET_CONFIGURE_OPTS. >>>> >Please review and apply if you agree. >>>> > >>>> > >>> > >Stephen, can you pls review the mtd part of this patch ASAP, >since this breaks the build for ARM (and possibly all non-x86). >Pls commit (or ack my commit) if OK. I've applied this now and will fix the other breakage due to not passing CFLAGS any longer, thus building with package-imposed incorrect flags. ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-09 8:25 ` Bernhard Fischer @ 2007-07-09 9:21 ` Bernhard Fischer 2007-07-09 12:20 ` Steven J. Hill 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-09 9:21 UTC (permalink / raw) To: buildroot On Mon, Jul 09, 2007 at 10:25:50AM +0200, Bernhard Fischer wrote: >On Sun, Jul 08, 2007 at 12:49:20AM +0200, Ulf Samuelsson wrote: >>> On Sat, Jul 07, 2007 at 09:37:05PM +0200, Ulf Samuelsson wrote: >>Stephen, can you pls review the mtd part of this patch ASAP, >>since this breaks the build for ARM (and possibly all non-x86). >>Pls commit (or ack my commit) if OK. > >I've applied this now and will fix the other breakage due to not passing >CFLAGS any longer, thus building with package-imposed incorrect flags. Steven, This hunk of yours is really broken: TARGET_CONFIGURE_OPTS=... \ CC="$(TARGET_CROSS)gcc $(TARGET_CFLAGS)" \ GCC="$(TARGET_CROSS)gcc $(TARGET_CFLAGS)" \ CXX="$(TARGET_CROSS)g++ $(TARGET_CFLAGS)" \ CPP="$(TARGET_CROSS)cpp $(TARGET_CFLAGS)" \ 1) These are the compilers and not compiler plus flags. 2) CFLAGS are wrong as CXXFLAGS 3) since your change we end up using the default flags from the packages, which more often than not default to -O2. Let me refer you to options.c of gcc (or the respective docs for the gory details). I am going to revert this change for now. What were you trying to do/solve? ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-09 9:21 ` Bernhard Fischer @ 2007-07-09 12:20 ` Steven J. Hill 2007-07-09 13:41 ` Julien Letessier 0 siblings, 1 reply; 25+ messages in thread From: Steven J. Hill @ 2007-07-09 12:20 UTC (permalink / raw) To: buildroot > This hunk of yours is really broken: > TARGET_CONFIGURE_OPTS=... \ > CC="$(TARGET_CROSS)gcc $(TARGET_CFLAGS)" \ > GCC="$(TARGET_CROSS)gcc $(TARGET_CFLAGS)" \ > CXX="$(TARGET_CROSS)g++ $(TARGET_CFLAGS)" \ > CPP="$(TARGET_CROSS)cpp $(TARGET_CFLAGS)" \ > > 1) These are the compilers and not compiler plus flags. > See comment below about packages breaking. > 2) CFLAGS are wrong as CXXFLAGS > So when compiling C++ code, and if I want the -Os and other options, how do you suggest we pass them. > 3) since your change we end up using the default flags from the > packages, which more often than not default to -O2. Let me refer you to > options.c of gcc (or the respective docs for the gory details). > Thanks, I am able to read code. > I am going to revert this change for now. What were you trying to > do/solve? > A number of packages break unless the above is done. By overriding CFLAGS in the top-level makefile, CFLAGS in packages themselves get overridden and fail to build. Essentially if you do not like the method above, then a bunch of packages will need to be changed in order to work properly with CFLAGS be specified at the very top. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-09 12:20 ` Steven J. Hill @ 2007-07-09 13:41 ` Julien Letessier 2007-07-09 13:08 ` Ulf Samuelsson 2007-07-09 16:33 ` Bernhard Fischer 0 siblings, 2 replies; 25+ messages in thread From: Julien Letessier @ 2007-07-09 13:41 UTC (permalink / raw) To: buildroot I'm following the discussion and would like to make a point: all of this is irrelevant for packages that use the GNU auto* tools properly (i.e. a whole lot of packages). Their configure script uses the TARGET_CONFIGURE_OPTS to generate correct makefiles, and no flags should thereafter be passed to $(MAKE) directly (or they'll break). So IMO, $(MAKE) -C $(FOO_DIR) $(TARGET_CONFIGURE_OPTS) will almost always break such a package. Even packages that just $(MAKE) -C $(FOO_DIR) CC=$(TARGET_CC) break more often than not. The whole discussion is only relevant for packages (like openssh) that do *not* use the GNU build system. Again, IMHO, such packages should be fixed using patches instead of trying to coerce buildroot into building them with a common method, e.g. by changing CC = gcc CFLAGS = -g -O2 -I./whatever in such packages into CC = $(TARGET_CC) CFLAGS = $(TARGET_CFLAGS) -I./whatever using a patch, on a case-by-case basis. Again, I feel that packages that require this are scarse. My 2/100 euros. -- ju 2007/7/9, Steven J. Hill <sjhill@realitydiluted.com>: > > > This hunk of yours is really broken: > > TARGET_CONFIGURE_OPTS=... \ > > CC="$(TARGET_CROSS)gcc $(TARGET_CFLAGS)" \ > > GCC="$(TARGET_CROSS)gcc $(TARGET_CFLAGS)" \ > > CXX="$(TARGET_CROSS)g++ $(TARGET_CFLAGS)" \ > > CPP="$(TARGET_CROSS)cpp $(TARGET_CFLAGS)" \ > > > > 1) These are the compilers and not compiler plus flags. > > > See comment below about packages breaking. > > > 2) CFLAGS are wrong as CXXFLAGS > > > So when compiling C++ code, and if I want the -Os and other options, > how do you suggest we pass them. > > > 3) since your change we end up using the default flags from the > > packages, which more often than not default to -O2. Let me refer you to > > options.c of gcc (or the respective docs for the gory details). > > > Thanks, I am able to read code. > > > I am going to revert this change for now. What were you trying to > > do/solve? > > > A number of packages break unless the above is done. By overriding > CFLAGS in the top-level makefile, CFLAGS in packages themselves get > overridden and fail to build. Essentially if you do not like the > method above, then a bunch of packages will need to be changed in > order to work properly with CFLAGS be specified at the very top. > > -Steve > _______________________________________________ > buildroot mailing list > buildroot at uclibc.org > http://busybox.net/mailman/listinfo/buildroot > -- Julien Letessier <julien.letessier@technosens.fr> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/buildroot/attachments/20070709/16e56ae1/attachment.htm ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-09 13:41 ` Julien Letessier @ 2007-07-09 13:08 ` Ulf Samuelsson 2007-07-09 16:33 ` Bernhard Fischer 1 sibling, 0 replies; 25+ messages in thread From: Ulf Samuelsson @ 2007-07-09 13:08 UTC (permalink / raw) To: buildroot m?n 2007-07-09 klockan 15:41 +0200 skrev Julien Letessier: > I'm following the discussion and would like to make a point: > all of this is irrelevant for packages that use the GNU auto* tools > properly (i.e. a whole lot of packages). > > Their configure script uses the TARGET_CONFIGURE_OPTS to generate > correct makefiles, and no flags should thereafter be passed to $(MAKE) > directly (or they'll break). > So IMO, > $(MAKE) -C $(FOO_DIR) $(TARGET_CONFIGURE_OPTS) > will almost always break such a package. Even packages that just > $(MAKE) -C $(FOO_DIR) CC=$(TARGET_CC) > break more often than not. The question I asked, where I did not get an answer was: Is there any case where $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(FOO_DIR) is correct but $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(FOO_DIR) is not. I know that there are cases (mtd) when the other way around is definitely incorrect. Best Regards Ulf Samuelsson ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-09 13:41 ` Julien Letessier 2007-07-09 13:08 ` Ulf Samuelsson @ 2007-07-09 16:33 ` Bernhard Fischer 2007-07-10 11:51 ` Julien Letessier 1 sibling, 1 reply; 25+ messages in thread From: Bernhard Fischer @ 2007-07-09 16:33 UTC (permalink / raw) To: buildroot On Mon, Jul 09, 2007 at 03:41:35PM +0200, Julien Letessier wrote: >I'm following the discussion and would like to make a point: >all of this is irrelevant for packages that use the GNU auto* tools properly >(i.e. a whole lot of packages). > >Their configure script uses the TARGET_CONFIGURE_OPTS to generate correct >makefiles, and no flags should thereafter be passed to $(MAKE) directly (or >they'll break). >So IMO, > $(MAKE) -C $(FOO_DIR) $(TARGET_CONFIGURE_OPTS) >will almost always break such a package. Even packages that just > $(MAKE) -C $(FOO_DIR) CC=$(TARGET_CC) >break more often than not. yes. we should not change stuff after the configure stage. [] >>> 2) CFLAGS are wrong as CXXFLAGS >>> >>So when compiling C++ code, and if I want the -Os and other options, >>how do you suggest we pass them. Unfortunately we will have to have TARGET_CXXFLAGS or filter out flags from CFLAGS that are rejected by the CXX compiler. The latter is of course ugly and will most likely not work reliably. I do not see a viable alternative to TARGET_CXXFLAGS (or fortran, ada, java, objc, you-name-it for that matter). >> >>> 3) since your change we end up using the default flags from the >>> packages, which more often than not default to -O2. Let me refer you to >>> options.c of gcc (or the respective docs for the gory details). >>> >>Thanks, I am able to read code. yea, i know. >> >>> I am going to revert this change for now. What were you trying to >>> do/solve? >>> >>A number of packages break unless the above is done. By overriding >>CFLAGS in the top-level makefile, CFLAGS in packages themselves get >>overridden and fail to build. Essentially if you do not like the >>method above, then a bunch of packages will need to be changed in >>order to work properly with CFLAGS be specified at the very top. Patching the affected packages is cumbersome and complicates maintenance. Just thinking loud.. what about patching the cross-compiler to use -Os unconditionally for any or no -O? Not really nice either, i fear. The native compiler would not be affected by this. What do you think? ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-09 16:33 ` Bernhard Fischer @ 2007-07-10 11:51 ` Julien Letessier 2007-07-10 18:24 ` Bernhard Fischer 0 siblings, 1 reply; 25+ messages in thread From: Julien Letessier @ 2007-07-10 11:51 UTC (permalink / raw) To: buildroot 2007/7/9, Bernhard Fischer <rep.dot.nop@gmail.com>: >So IMO, > > $(MAKE) -C $(FOO_DIR) $(TARGET_CONFIGURE_OPTS) > >will almost always break such a package. Even packages that just > > $(MAKE) -C $(FOO_DIR) CC=$(TARGET_CC) > >break more often than not. > > yes. we should not change stuff after the configure stage. Agreed. IMO no vars should be passed to $(MAKE) unless mandatory (e.g. INSTALL_DIR=$(STAGING_DIR)/usr) >>> 2) CFLAGS are wrong as CXXFLAGS > >>> > >>So when compiling C++ code, and if I want the -Os and other options, > >>how do you suggest we pass them. > > Unfortunately we will have to have TARGET_CXXFLAGS or filter out flags > from CFLAGS that are rejected by the CXX compiler. The latter is of > course ugly and will most likely not work reliably. > I do not see a viable alternative to TARGET_CXXFLAGS (or fortran, ada, > java, objc, you-name-it for that matter). Agreed. One set of flags per compiler is perfectly reasonable. >>A number of packages break unless the above is done. By overriding > >>CFLAGS in the top-level makefile, CFLAGS in packages themselves get > >>overridden and fail to build. Essentially if you do not like the > >>method above, then a bunch of packages will need to be changed in > >>order to work properly with CFLAGS be specified at the very top. > > Patching the affected packages is cumbersome and complicates > maintenance. Just thinking loud.. what about patching the cross-compiler > to use -Os unconditionally for any or no -O? Not really nice either, i > fear. The native compiler would not be affected by this. > > What do you think? > Again, IMO very few (~10) packages will need to be fixed, so I'd prefer patching the packages themselves. Besides, most of them *are* fixed already. If the only flag problem is the -O* problem, fixing the cross-compiler might be an option... except that GCC (especially the 4.2 branch) has a lot of regressions with -Os. Even though no bad code will be generated (AFAIK), some sources will crash the compiler, others will take any non-reasonable amount of time/memory to compile. E.g. xf86ScanPci.c in the X server requires >5GB of memory and about forever to compile on my build host with -Os (for no apparent reason). Besides, there are other flags to take care of... once we've started a list of flags to 'force' gcc to use, this will never be over. Why not forcing the compiler to use -mcpu=$(SUBARCH), -g, ad lib. Cheers, -- Julien Letessier <julien.letessier@technosens.fr> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/buildroot/attachments/20070710/2629ef82/attachment.htm ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) 2007-07-10 11:51 ` Julien Letessier @ 2007-07-10 18:24 ` Bernhard Fischer 0 siblings, 0 replies; 25+ messages in thread From: Bernhard Fischer @ 2007-07-10 18:24 UTC (permalink / raw) To: buildroot On Tue, Jul 10, 2007 at 01:51:52PM +0200, Julien Letessier wrote: >Again, IMO very few (~10) packages will need to be fixed, so I'd prefer >patching the packages themselves. Besides, most of them *are* fixed already. I looked a little bit and it merely sounds like we could perhaps get away with drop flags from TARGET_CONFIGURE_OPTS and pass (let's say) TARGET_CONFIGURE_FLAGS to properly behaving packages and do obscure workarounds for the few remaining packages that don't get their act straight. > >If the only flag problem is the -O* problem, fixing the cross-compiler might >be an option... except that GCC (especially the 4.2 branch) has a lot of >regressions with -Os. Even though no bad code will be generated (AFAIK), >some sources will crash the compiler, others will take any non-reasonable >amount of time/memory to compile. E.g. xf86ScanPci.c in the X server >requires >5GB of memory and about forever to compile on my build host with >-Os (for no apparent reason). heh, glad that i don't do X11 ;) Still, can you please file a bug in gcc.gnu.org/bugzilla with the preprocessed source of that file? TIA > >Besides, there are other flags to take care of... once we've started a list >of flags to 'force' gcc to use, this will never be over. Why not forcing the >compiler to use -mcpu=$(SUBARCH), -g, ad lib. I occasionally do this to raise my blood pressure and to start endless cursing about broken stuff, yea :/ A first step would be to explicitely do Index: package/Makefile.in =================================================================== --- package/Makefile.in (revision 19057) +++ package/Makefile.in (working copy) @@ -29,6 +29,22 @@ #TARGET_LDFLAGS=-Wl,$(BR2_SYSROOT) endif +CC_TARGET_TUNE_:=$(strip $(subst ",,BR2_GCC_TARGET_TUNE)) +#")) +CC_TARGET_ARCH_:=$(strip $(subst ",,BR2_GCC_TARGET_ARCH)) +#")) +CC_TARGET_ABI_:=$(strip $(subst ",,BR2_GCC_TARGET_ABI)) +#")) +ifneq ($(CC_TARGET_TUNE_),) +TARGET_CFLAGS+=-mtune=$(CC_TARGET_TUNE_) +endif +ifneq ($(CC_TARGET_ARCH_),) +TARGET_CFLAGS+=-march=$(CC_TARGET_ARCH_) +endif +ifneq ($(CC_TARGET_ABI_),) +TARGET_CFLAGS+=-mabi=$(CC_TARGET_ABI_) +endif + ifneq ($(BR2_PREFER_STATIC_LIB),y) ifeq ($(BR2_x86_64),y) TARGET_CFLAGS+=-fPIC -DPIC but i recently changed the cross-compiler to default to this, so it's really superfluous. An approach that would be even more evil (the above will not catch folks on a compatible host) would be to make the cross-compiler accept -fuxored-up-package and pass that ;) ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] What is the proper procedure to commit a patch? 2007-07-06 12:35 [Buildroot] What is the proper procedure to commit a patch? Ulf Samuelsson 2007-07-06 15:26 ` Bernhard Fischer 2007-07-06 15:55 ` Steven J. Hill @ 2007-07-07 10:21 ` Bernhard Fischer 2 siblings, 0 replies; 25+ messages in thread From: Bernhard Fischer @ 2007-07-07 10:21 UTC (permalink / raw) To: buildroot On Fri, Jul 06, 2007 at 02:35:32PM +0200, Ulf Samuelsson wrote: >Now, when I have access, I would like to understand the proper >procedure to add patches. >The patches I'd like to add are mainly: >* A few extra packages. Which packages are you going to add? >* Bump versions on a number of packages which has disappeared from their download location. > (dash, rmp, l2tp, mpfr,mrouted, openntpd, portage, pppd,udev) Ok, a general thing that we do _not_ want to do is to accumulate too many patches, as a general rule of thumb. Please, please try to push patches to upstream, otherwise version bumps are getting cumbersome over time. Obviously it is a good thing to improve a package, but upstream authors/maintainers should fix their stuff and not rely on their users to repeatedly fixup on behalf of the real maintainer. >Best Regards >Ulf Samuelsson ulf at atmel.com >Atmel Nordic AB >Mail: Box 2033, 174 02 Sundbyberg, Sweden >Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden >Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 >GSM +46 (706) 22 44 57 > >Technical support when I am not available: >AT90 AVR Applications Group: mailto:avr at atmel.com >AT91 ARM Applications Group: mailto:at91support at atmel.com >AVR32 Applications Group mailto:avr32 at atmel.com >http://www.avrfreaks.net/; http://avr32linux.org/ >http://www.at91.com/ ; ftp://at91dist:distrib at 81.80.104.162/ >_______________________________________________ >buildroot mailing list >buildroot at uclibc.org >http://busybox.net/mailman/listinfo/buildroot > ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2007-07-10 18:24 UTC | newest] Thread overview: 25+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-07-06 12:35 [Buildroot] What is the proper procedure to commit a patch? Ulf Samuelsson 2007-07-06 15:26 ` Bernhard Fischer 2007-07-06 15:36 ` Ulf Samuelsson 2007-07-07 10:12 ` Bernhard Fischer 2007-07-07 11:16 ` Ulf Samuelsson 2007-07-07 12:35 ` Bernhard Fischer 2007-07-07 13:46 ` Ulf Samuelsson 2007-07-06 15:55 ` Steven J. Hill 2007-07-06 21:10 ` Ulf Samuelsson 2007-07-07 10:06 ` [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) Ulf Samuelsson 2007-07-07 13:01 ` Bernhard Fischer 2007-07-07 16:06 ` Ulf Samuelsson 2007-07-07 17:29 ` Bernhard Fischer 2007-07-07 19:37 ` Ulf Samuelsson 2007-07-07 21:16 ` Bernhard Fischer 2007-07-07 22:49 ` Ulf Samuelsson 2007-07-09 8:25 ` Bernhard Fischer 2007-07-09 9:21 ` Bernhard Fischer 2007-07-09 12:20 ` Steven J. Hill 2007-07-09 13:41 ` Julien Letessier 2007-07-09 13:08 ` Ulf Samuelsson 2007-07-09 16:33 ` Bernhard Fischer 2007-07-10 11:51 ` Julien Letessier 2007-07-10 18:24 ` Bernhard Fischer 2007-07-07 10:21 ` [Buildroot] What is the proper procedure to commit a patch? Bernhard Fischer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox