On Wed, 30 May 2007, Bakul Shah wrote:
Peter Jeremy <[EMAIL PROTECTED]> wrote:
On 2007-May-27 16:12:54 -0700, Bakul Shah <[EMAIL PROTECTED]> wrote:
Given the size and complexity of the port system I have long
felt that rather than do everything via more and more complex
Mk/*.mk what is is ne
Peter Jeremy <[EMAIL PROTECTED]> wrote:
> On 2007-May-27 16:12:54 -0700, Bakul Shah <[EMAIL PROTECTED]> wrote:
> >Given the size and complexity of the port system I have long
> >felt that rather than do everything via more and more complex
> >Mk/*.mk what is is needed is a ports server and a thin C
On Tue, May 29, 2007 at 08:34:29PM +1000, Peter Jeremy wrote:
> On 2007-May-27 15:30:48 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> >This sounds like a good solution. In fact, I'm lead to believe that
> >heavy reliance on /bin/sh is part of why the ports collection is slow.
>
> Someone ne
On 2007-May-27 15:30:48 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
>This sounds like a good solution. In fact, I'm lead to believe that
>heavy reliance on /bin/sh is part of why the ports collection is slow.
Someone needs to enable accounting on a recent -current (with the
high-resolution
On 2007-May-27 15:52:16 -0500, Stephen Montgomery-Smith <[EMAIL PROTECTED]>
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. No
On 2007-May-28 00:15:28 +0200, Michel Talon <[EMAIL PROTECTED]> wrote:
>Of course a lot of people have thinked about it, and quickly realized
>that it was not going to work. In the bsd.ports.mk, evaluation of one
>variable may be dependent on some conditional, which may itself be
>dependant on some
On 2007-May-27 16:12:54 -0700, Bakul Shah <[EMAIL PROTECTED]> wrote:
>Given the size and complexity of the port system I have long
>felt that rather than do everything via more and more complex
>Mk/*.mk what is is needed is a ports server and a thin CLI
>frontend to it.
I don't believe this is pra
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
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
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:/
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
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
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:/
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:
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 Sun, May 27, 2007 at 10:51:56PM -0400, Mike Meyer wrote:
> In <[EMAIL PROTECTED]>, Edwin Groothuis <[EMAIL PROTECTED]> typed:
> > On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
> > > In summary, the ports infrastructure is really complicated because it's
> > > trying to deal with
In <[EMAIL PROTECTED]>, Edwin Groothuis <[EMAIL PROTECTED]> typed:
> On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
> > In summary, the ports infrastructure is really complicated because it's
> > trying to deal with all kinds of constraints and conditions. I challenge
> Reading this
On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
> In summary, the ports infrastructure is really complicated because it's
> trying to deal with all kinds of constraints and conditions. I challenge
Reading this, I was wondering what the ports infrastructure has
ever done for us?
See
I'm looking for something that will work with the existing framework.
But yes, I get the feeling that maybe using "make" to process the ports
might be the source of the problem. Make is a program primarily
designed for figuring out which was made first, the target or the
source, but in the por
On Mon, May 28, 2007 at 12:15:28AM +0200, Michel Talon wrote:
> To gain some performance, a first idea would be to simplify
> bsd.ports.mk. I am convinced that a substantial part of the 4000 lines
> are historical crap which serve no useful purpose.
11272 of LOC in bsd.*.mk, but who's counting.
>
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
On Mon, 28 May 2007, Michel Talon wrote:
Stephen Montgomery-Smith said:
I suggest rewriting "make" so that variables are only evaluated on a
"need to know" basis.
or "I have tried to do this."
Of course a lot of people have thinked about it, and quickly realized
that it was not going
Not quite what you asked for but...
Given the size and complexity of the port system I have long
felt that rather than do everything via more and more complex
Mk/*.mk what is is needed is a ports server and a thin CLI
frontend to it.
This server can store dependency data in an efficient manner,
Hi,
On Sun, May 27, 2007 at 03:30:48PM -0700, Jeremy Chadwick wrote:
> Does it need to be done this way? Can we just iterate through all of
> the ports, call make -V _DEPEND_DIRS, then sort | uniq the results?
This is exactly what ALL-DEPENDS-LIST does. Except it's faster. It
keeps two lists a
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 package. Now
> "
Stephen Montgomery-Smith said:
> I suggest rewriting "make" so that variables are only evaluated on a
> "need to know" basis.
> or "I have tried to do this."
Of course a lot of people have thinked about it, and quickly realized
that it was not going to work. In the bsd.ports.mk, evaluation
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 the make has to
load in and analyz
35 matches
Mail list logo
