Joel Thibault wrote:
Cool! When do you expect (or estimate) release 1.6 will be available?
Is there a roadmap or other document available showing milestones such
as these?
The milestones are in Trac, but jmpp hasn't got around to defining 1.6
yet...
http://trac.macports.org/projects/macp
On Nov 1, 2007, at 07:27, Joel Thibault (MacPorts) wrote:
On 10/30/07, I wrote:
Cool! When do you expect (or estimate) release 1.6 will be
available?
Is there a roadmap or other document available showing milestones
such as these?
Not that I'm aware of.
__
On 10/30/07, I wrote:
>
> Cool! When do you expect (or estimate) release 1.6 will be available?
>
Is there a roadmap or other document available showing milestones such as these?
Thanks,
Joel
--
Joel Thibault [AIM: Jole Tebo]
Software Engineer in Boston
___
Parallell builds are an optional feature, and will never be disabled
by default.
*enabled* by default, darnit.
--anders
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Markus Weissmann wrote:
No, but we should only enable parallel builds for software we know to
behave correctly. I wont kick you if you enable a parallel build for a
port that you maintain and you are not 100% sure that it'll work
_always_ -- the bug reports are yours. But I do not like 1.
unm
On 31.10.2007, at 12:36, Vincent Lefevre wrote:
On 2007-10-31 12:26:44 +0100, Markus Weissmann wrote:
On 31.10.2007, at 05:13, Vincent Lefevre wrote:
I disagree. Port maintainers should test their port to see if they
work with "make -j".
Well, you cannot reliably test this. If you're lucky i
On Oct 31, 2007, at 7:36 AM, Vincent Lefevre wrote:
On 2007-10-31 12:26:44 +0100, Markus Weissmann wrote:
On 31.10.2007, at 05:13, Vincent Lefevre wrote:
I disagree. Port maintainers should test their port to see if they
work with "make -j".
Well, you cannot reliably test this. If you're luck
On 2007-10-31 12:26:44 +0100, Markus Weissmann wrote:
> On 31.10.2007, at 05:13, Vincent Lefevre wrote:
>> I disagree. Port maintainers should test their port to see if they
>> work with "make -j".
>
> Well, you cannot reliably test this. If you're lucky it might work
> one time and fail the other.
On 31.10.2007, at 05:13, Vincent Lefevre wrote:
On 2007-10-30 16:20:18 +0100, Markus Weissmann wrote:
On 30.10.2007, at 13:52, Vincent Lefevre wrote:
The bug could also be reported upstream, so that a ".NOTPARALLEL:"
is added to the Makefile.
Well, this simply is not going to work -- this ha
On 2007-10-30 16:20:18 +0100, Markus Weissmann wrote:
> On 30.10.2007, at 13:52, Vincent Lefevre wrote:
>> The bug could also be reported upstream, so that a ".NOTPARALLEL:"
>> is added to the Makefile.
>
> Well, this simply is not going to work -- this has to be an opt-in,
> not an opt-out option!
On Oct 30, 2007, at 11:20 AM, Markus Weissmann wrote:
Well, this simply is not going to work -- this has to be an opt-in,
not an opt-out option!
I agree with Markus. It doesn't make sense to create a new default
option that could (and probably will) break a bunch of ports.
If you do not kn
On 30.10.2007, at 13:52, Vincent Lefevre wrote:
On 2007-10-30 12:43:52 +0100, Anders F Björklund wrote:
Weissmann Markus:
Yes, but I meant this to be a per-Portfile choice so a maintainer
can mark
his/her port as being able to build in parallel. Doing this with the
sledgehammer for all ports
o The bug could also be reported upstream, so that a ".NOTPARALLEL:"
o is added to the Makefile.
Interesting pseudo-target.
Maybe MacPorts uses, and ports that can't should patch their makefiles?
--
Salvatore Domenick Desiano
Doctoral Candidate
Robotics Institute
On 10/28/07, Anders F Björklund afb-at-macports.org |MacPorts|
<[EMAIL PROTECTED]> wrote:
> js wrote:
>
> > http://www.macosxhints.com/article.php?story=20070524074057479
> >> From this article, I learned how we can easily speed up build phase
> >> of MacPorts.
> >
> > Can I make this behavior (-j)
On 2007-10-30 12:43:52 +0100, Anders F Björklund wrote:
> Weissmann Markus:
>> Yes, but I meant this to be a per-Portfile choice so a maintainer can mark
>> his/her port as being able to build in parallel. Doing this with the
>> sledgehammer for all ports that use 'make' might be a bit too much.
Weissmann Markus:
Yes, but I meant this to be a per-Portfile choice so a maintainer can
mark his/her port as being able to build in parallel. Doing this with
the sledgehammer for all ports that use 'make' might be a bit too
much. ;)
It is supposed to be the default... But broken ports might
On 30.10.2007, at 12:13, Anders F Björklund wrote:
I'd rather encourage a mechanism for port that provides a
mechanism for port authors to know how many processors there are
and to enable parallel builds if they know this to work.
Perhaps a switch "use_parallel_build [yes|no]" that will add "
I'd rather encourage a mechanism for port that provides a mechanism
for port authors to know how many processors there are and to enable
parallel builds if they know this to work.
Perhaps a switch "use_parallel_build [yes|no]" that will add "-j
2*CPUS" to build.args.
There's a bunch of other i
On 28.10.2007, at 23:52, js wrote:
On 10/29/07, Anders F Björklund <[EMAIL PROTECTED]> wrote:
Note that some ports will fail to build, when using "make -j 2"
What causes the build erorr? is it for bad Makefile or problem of
"-j"
option itself?
Bad makefiles, usually missing dependencies.
On 10/29/07, Anders F Björklund <[EMAIL PROTECTED]> wrote:
> >> Note that some ports will fail to build, when using "make -j 2"
> >
> > What causes the build erorr? is it for bad Makefile or problem of "-j"
> > option itself?
>
> Bad makefiles, usually missing dependencies.
So, in a way, using -j
On 2007-10-28 16:11:48 +0100, Anders F Björklund wrote:
> js wrote:
>> What causes the build erorr? is it for bad Makefile or problem of "-j"
>> option itself?
>
> Bad makefiles, usually missing dependencies.
And this may be difficult to fix. For instance:
http://dev.mutt.org/trac/ticket/2538
js wrote:
Note that some ports will fail to build, when using "make -j 2"
What causes the build erorr? is it for bad Makefile or problem of "-j"
option itself?
Bad makefiles, usually missing dependencies.
--anders
___
macports-users mailing list
On 10/28/07, Anders F Björklund <[EMAIL PROTECTED]> wrote:
> > Can I make this behavior (-j) default for all ports using make?
>
> In MacPorts 1.6, you can set the -j parameter with "build.jobs".
> ( see http://trac.macports.org/projects/macports/ticket/12280 )
Great. I look forward to it!
> Howe
On 10/28/07, Bryan Blackburn <[EMAIL PROTECTED]> wrote:
> There is the 'buildmakejobs' option in /opt/local/etc/macports/
> macports.conf which should be passing a '-j #' to make, though I
> personally haven't tried it.
I didn't know that. I'll try.
But port(1) and macports.conf(5) don't have
any
On Oct 28, 2007, at 2:42 AM, js wrote:
http://www.macosxhints.com/article.php?story=20070524074057479
From this article, I learned how we can easily speed up build
phase of MacPorts.
$ sudo port clean lv
...
Can I make this behavior (-j) default for all ports using make?
There is the '
js wrote:
http://www.macosxhints.com/article.php?story=20070524074057479
From this article, I learned how we can easily speed up build phase
of MacPorts.
Can I make this behavior (-j) default for all ports using make?
In MacPorts 1.6, you can set the -j parameter with "build.jobs".
( see ht
http://www.macosxhints.com/article.php?story=20070524074057479
>From this article, I learned how we can easily speed up build phase of
>MacPorts.
$ sudo port clean lv
---> Cleaning lv
$ sudo port configure lv
---> Fetching lv
---> Verifying checksum(s) for lv
---> Extracting lv
---> Applying
27 matches
Mail list logo
