Doug Barton wrote:
>> (Over 2GBs of RAM + Swap being used). It does this consistently when it
>> tries to compile xf86PciScan.c (hope thats the right file).
>
> May not be the answer you want to hear, but I built all the xorg stuff
> multiple times on -current systems both pre and post the gcc + s
Ali Mashtizadeh wrote:
> I seem to have problems building xorg-server port on freebsd HEAD with a
> snapshot of source that is about 5 days old. I'm running AMD64 build
> everything i've installed is fine except when building xorg-server gcc
> 4.2starts to use all the memory i have and then exits
Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
1. make and its sub-makes for a) reading the file; b) parsing the file
(note that .if and .for processing is done while parsin
I seem to have problems building xorg-server port on freebsd HEAD with a
snapshot of source that is about 5 days old. I'm running AMD64 build
everything i've installed is fine except when building xorg-server gcc
4.2starts to use all the memory i have and then exits saying not
enough memory
(Over
On Sun, May 27, 2007 at 03:30:48PM -0700, Jeremy Chadwick wrote:
>
> That said, I'll ask this out in the open: am I the only one who sees the
> benefit of GNU make in regards to this? There's a lot of built-in
> functions in GNU make which could help in regards to ports. I have no
> qualms with
Stephen Montgomery-Smith wrote:
Roman Divacky wrote:
On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote:
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith
wrote:
I have been thinking a lot about looking for speed increases for
"mak
Roman Divacky wrote:
On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote:
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and thin
Correct me if I wrong. Don't you missed the fact that chdir(2) changes
process wide attribute?
Though it's easy to fix with -C option.
Stephen Montgomery-Smith wrote:
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith
wrote:
I have been thinking a lot abo
Resent to freebsd-hackers@:
Greetings, all.
On 2007.05.22, at 03:57, Ivan Voras wrote:
Hi!
I've had the opportunity to talk to Adam Martin, Marcel Moolenaar and
Peter Wemm about making GPT bootable, but not all of them at the same
time, so I'd like this thread to be the meeting point on the s
In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
> Mike Meyer wrote:
> > In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
> >> 1. make and its sub-makes for a) reading the file; b) parsing the file
> >> (note that .if and .for processing is done while parsing); c)
On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote:
> Jeremy Chadwick wrote:
> >On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
> >> I have been thinking a lot about looking for speed increases for "make
> >> index" and pkg_version and things like th
Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
1. make and its sub-makes for a) reading the file; b) parsing the file
(note that .if and .for processing is done while parsing); c) processing
targets.
Make and submakes have been gone over already. See http:/
Stephen Montgomery-Smith wrote:
> Ivan Voras wrote:
>> As long as far-out ideas are being discussed, how about caching such
>> information (including dependenices) in a file (I'd call it a database
>> but then I'd had to start a holy war :) ) so it's calculated only once,
>> preferably on the port
Garrett Cooper wrote:
Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
1. make and its sub-makes for a) reading the file; b) parsing the file
(note that .if and .for processing is done while parsing); c) processing
targets.
Make and submakes have been gone o
Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
1. make and its sub-makes for a) reading the file; b) parsing the file
(note that .if and .for processing is done while parsing); c) processing
targets.
Make and submakes have been gone over already. See http:/
In <[EMAIL PROTECTED]>, Hartmut Brandt <[EMAIL PROTECTED]> typed:
> 1. make and its sub-makes for a) reading the file; b) parsing the file
> (note that .if and .for processing is done while parsing); c) processing
> targets.
Make and submakes have been gone over already. See http://miller.emu.id.a
On Mon, 28 May 2007, David Naylor wrote:
On Monday 28 May 2007 03:43, you wrote:
Maybe I should look at the inner workings of cmake and gmake. Maybe
they have some good ideas. However having looked through the source
code of make, and also looking at the cvs logs, it does seem to be well
wr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ivan Voras wrote:
> Stephen Montgomery-Smith wrote:
>> I have been thinking a lot about looking for speed increases for "make
>> index" and pkg_version and things like that. So for example, in
>> pkg_version, it calls "make -V PKGNAME" for every ins
On Monday 28 May 2007 03:43, you wrote:
> Maybe I should look at the inner workings of cmake and gmake. Maybe
> they have some good ideas. However having looked through the source
> code of make, and also looking at the cvs logs, it does seem to be well
> written. The only possibility I see of m
Ivan Voras wrote:
Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and things like that. So for example, in
pkg_version, it calls "make -V PKGNAME" for every installed package. Now
"make -V PKGNAME" should be a speedy
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and things like that. So for example, in
pkg_version, it calls "make -V PKGNAME" for every installed
Stephen Montgomery-Smith wrote:
> I have been thinking a lot about looking for speed increases for "make
> index" and pkg_version and things like that. So for example, in
> pkg_version, it calls "make -V PKGNAME" for every installed package. Now
> "make -V PKGNAME" should be a speedy operation, bu
Stephen Montgomery-Smith wrote:
Hartmut Brandt wrote:
Having done a great deal of rewriting of make some two years ago I can
tell you that even a small change to make is a tough job testing-wise:
run all the combinations of !-j and -j on all architectures and run
the change through the port-bu
Hartmut Brandt wrote:
Having done a great deal of rewriting of make some two years ago I can
tell you that even a small change to make is a tough job testing-wise:
run all the combinations of !-j and -j on all architectures and run
the change through the port-building cluster. That's a warning
Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and things like that. So for example, in
pkg_version, it calls "make -V PKGNAME" for every installed package. Now
"make -V PKGNAME" should be a speedy operation, but th
Matthew Seaman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and things like that. So for example, in
pkg_version, it calls "make -V PKGNAME" for every install
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Stephen Montgomery-Smith wrote:
> I have been thinking a lot about looking for speed increases for "make
> index" and pkg_version and things like that. So for example, in
> pkg_version, it calls "make -V PKGNAME" for every installed package. Now
> "
On Sat, 26 May 2007, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Benjamin Lutz <[EMAIL PROTECTED]> writes:
: On Friday 25 May 2007 01:22:21 Alexey Mikhailov wrote:
: > [...]
: > 2. As I said before initial subject of this project was "Distributed
: > audit daemon". But after
28 matches
Mail list logo
