Hi,
Since some things happen at the same time there is no single "serial
order". The semaphore mechanism, forces one of the possible orders.
I forgot to say that for recipes with multiple commands you need to
either use the new .ONESHELL target or do this kind of thing:
mytarget:mytarget:
->com
On Tue, Aug 03, 2010 at 12:03:35AM +0300, Thomas Backlund wrote:
> 02.08.2010 23:51, Sam Ravnborg skrev:
> >>
> >> Thanks, this seems to fix the first issue, but then I get the same erro on
> >> the following line 190:
> >>
> >> 190: bootwrapper_install %.dtb:
> >> 191:$(Q)$(MAKE) ARCH=ppc
Follow-up Comment #4, bug #16362 (project make):
(Submitted by J David Bryan )
The patch in comment #3, which solves the originally reported problem, did
not make it into version 3.82. Regrettably, I did not check for this in the
RC.
Could this patch please be included in the next release?
02.08.2010 23:51, Sam Ravnborg skrev:
>>
>> Thanks, this seems to fix the first issue, but then I get the same erro on
>> the following line 190:
>>
>> 190: bootwrapper_install %.dtb:
>> 191:$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst
>> %,$(boot)/%,$@)
>>
>
> Obviously - dunno ho
Sam Ravnborg writes:
> +bootwrapper_install
Missing colon.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Bug-make mailing
02.08.2010 21:28, Sam Ravnborg skrev:
> On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote:
>> Hi,
>> (please cc me as I'm not subscribed)
>>
>> updating from make 3.81 to 3.82 gets me this:
>>
>> [tho...@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
>> [tho...@tmb
On Mon, Aug 2, 2010 at 4:22 PM, Edward Welbourne wrote:
>> If my guess is not wrong, the semaphore safeguard the consistency of
>> output of one command, not the order of commands.
>
> well, with -j, commands are being run concurrently, so there *isn't* a
> strict ordering of commands to "safeguar
>
> Thanks, this seems to fix the first issue, but then I get the same erro on
> the following line 190:
>
> 190: bootwrapper_install %.dtb:
> 191:$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>
Obviously - dunno how I missed that.
Updated patch below.
I will do a
> From: Juan Manuel Guerrero
> Date: Mon, 2 Aug 2010 20:24:58 +0200
>
> Here is a small patch to make "make" compile out-of-the-box with djgpp.
Thanks.
> 2010-07-31 Juan Manuel Guerrero
>
> * configh.dos: Define HAVE_STRNCASECMP.
>
> * dosbuild.bat: Use /dev/env/DJDIR instead o
Here is a small patch to make "make" compile out-of-the-box with djgpp.
Regards,
Juan M. Guerrero
2010-07-31 Juan Manuel Guerrero
* configh.dos: Define HAVE_STRNCASECMP.
* dosbuild.bat: Use /dev/env/DJDIR instead of c:/djgpp.
Add ./popen.c to the list of objects
On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote:
> Hi,
> (please cc me as I'm not subscribed)
>
> updating from make 3.81 to 3.82 gets me this:
>
> [tho...@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
> [tho...@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=po
Hi,
(please cc me as I'm not subscribed)
updating from make 3.81 to 3.82 gets me this:
[tho...@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
[tho...@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
/mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed
im
> the output I see from make is after all macro substitutions have been
> made, which can make it virtually impossible
> to recognize as far as where it came from in the original source
This, however, is an issue with how the make file is written.
It sounds like its recipes for commands are of f
> 2x is too much. 1.5x has been the best in my experience, any more than that
> and you're losing too much CPU to scheduling overhead instead of real work.
> Any less and you're giving up too much in idle or I/O time.
This depends a bit on whether you're using icecc or some similar
distributed c
> If my guess is not wrong, the semaphore safeguard the consistency of
> output of one command, not the order of commands.
well, with -j, commands are being run concurrently, so there *isn't* a
strict ordering of commands to "safeguard", although output shall be
delivered in roughly the order of c
Edward Welbourne wrote:
2x is too much. 1.5x has been the best in my experience, any more than that
and you're losing too much CPU to scheduling overhead instead of real work.
Any less and you're giving up too much in idle or I/O time.
This depends a bit on whether you're using icecc or some si
16 matches
Mail list logo