On Mon, 3 Jun 2013 14:13:38 -0700, Navdeep Parhar writes:
On 05/30/13 18:43, Navdeep Parhar wrote:
I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but
not this time) as part of my pre-commit checklist. It doesn't seem to
work after the switch to bmake. What am I missing?
On Mon, 3 Jun 2013 14:13:38 -0700, Navdeep Parhar writes:
On 05/30/13 18:43, Navdeep Parhar wrote:
I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but
not this time) as part of my pre-commit checklist. It doesn't seem to
work after the switch to bmake. What am I missing?
On Mon, 6 May 2013 00:11:51 +0200, Baptiste Daroussin writes:
The ports tree on current is still in very bad shape but I don't see
anymore errors due to bmake specifically.
You have my approval as portmgr to switch base make to bmake.
As an interim step, I would propose the change below.
One is to have a MAKEOBJDIRPREFIX like option, and redefine every
target’s DESTDIR ${makeobjDESTDIR} before running do-install. Now i’ve
yet to complete this stage, but I believe this is the way to do it.
Would it be sufficient to have an INSTALL_PREFIX and/or INSTALL_DESTDIR
so that DESTDIR can
Doing the same thing could also prevent the need for a DESTDIR JAIL
install at all and just use the real build machine’s build env, rather
than a jail. Regardless. We still have to install these targets and
their DESTDIR is skewed. There is a few options,
I think I know what you mean, but not
Ah, but make(1) can delay spawning any new processes when it knows its
children are paging.
Sounds good - but I doubt the complexity it adds would really be worth
it.
If the real problem is the C++ compiler or other large tool needing
sufficient resources that you have to ensure invocations are
On Sun, 28 Oct 2012 14:06:41 +, Chris Rees writes:
Are we planning to replace /usr/bin/make with bmake in the near future?
That was what I heard, but any such move is dependent on dealing with
ports. The ~sjg/ports2bmake.tar.gz on freefall is the plan I came up
with after the above
BTW, would it be useful to put a devel/fmake into ports to make it easy
for people with older systems to install an up to date version of
freebsd make (which groks both sets of toupper/tolower modifiers)?
Perhaps a knob to install it or put in a link as /usr/bin/make ?
These discussions need backing up with a real roadmap, including detail on
exactly what 8.3 and 7.4 users will have to do to ensure that the ports
tree still works.
I've tested the ports tree converted to bmake - per the patch I
mentioned on a 7.1 box. It worked for me. Once the ports tree has
On Sat, 27 Oct 2012 09:44:36 -0500, Bryan Drewery writes:
Could there be a make.conf/env setting to make bmake run AS pmake in
full compat mode? On by default until all older branches are EoL, then
it can flip and be optional.
This has been mentioned before.
Firstly, I have changed bmake
On Sat, 27 Oct 2012 18:32:56 +0100, Chris Rees writes:
On 27 October 2012 18:27, Simon J. Gerraty s...@juniper.net wrote:
I've tested the ports tree converted to bmake - per the patch I
mentioned on a 7.1 box. It worked for me. Once the ports tree has
What about these?
[crees@pegasus
On Sat, 27 Oct 2012 14:23:29 +0100, Chris Rees writes:
We (ab)use the security update mechanism to merge the pmake changes
(:tl and :tu) into releng/7.4 and releng/8.3 (possibly the earlier
I originally provided the :tl and :tu patch for something like that
(not planning any abuse mind ;-)
But,
On Sat, 27 Oct 2012 19:53:56 +0100, Chris Rees writes:
I'm saying that it's unacceptable to expect people to change their
systems just to make the ports tree work after we have broken it on a
supposedly supported version.
But there's no suggestion of that.
The ports tree would take care of
In particular, why cannot the ':L' and ':U' support be added ?
:U is already used by bmake for something else- I can't remember what, but
I checked the man page last night :(
http://www.crufty.net/sjg/blog/freebsd-meta-mode.htm
might provide some interesting background.
It is a more FreeBSD
In particular, why cannot the ':L' and ':U' support be added ?
Because they already exist - with different meanings.
They were added to NetBSD make over 10 years ago, from the OSF version
of pmake.
In several areas the behavior of bmake has been changed to make it a
drop in replacement for
On Fri, 26 Oct 2012 08:27:06 -0600, Warner Losh writes:
And we've had the :U and :L for a similar period of time as well. =
Sorry, I didn't mean to imply age has anything to do with it.
The doc I refered to makes it clear that the two sets of conflicting
modifers were introduced at about the
with their use of FreeBSD's make in their own projects. So picking a
good name now would be helpful.
FWIW I keep a copy in /usr/bin/fmake so I can compare behavior.
___
freebsd-hackers@freebsd.org mailing list
On Fri, 26 Oct 2012 11:41:46 -0600, Warner Losh writes:
It's called a transition period for a reason. The historical use has =
permeated itself into many places, not all of which are obvious.
It would seem that leaving FreeBSD make as make, for the transition
period and installing bmake as
On Fri, 26 Oct 2012 10:55:59 -0700, David O'Brien writes:
I'm trying to create an ATF test for filemon, but I don't want to have to
build make back and forth when I want to build a port.
Likely that doesn't put me in the people working on ATF in your book.
What can I and others do to work on
On Fri, 26 Oct 2012 12:27:35 -0700, Garrett Cooper writes:
There are some basic examples, but they're in my p4 branch and
unfortunately they depend on atf.test.mk/bsd.test.mk/bsd.progs.mk
Speaking of which. I notice there is now a bsd.progs.mk in head, which
bears little relationship to the one
On Fri, 26 Oct 2012 21:00:26 +0100, Chris Rees writes:
:L -- seems that bmake's use for this is kinda pointless; returning the
name of the variable; we could swap that usage over directly.
Acutally it is very useful.
The debugging facilities in dirdeps.mk rely on it.
The junos build uses it in
On Fri, 26 Oct 2012 22:02:00 +0100, Chris Rees writes:
In that case we have a switch time on the order of years, not weeks; 8.3 is
supported until May '14, and unless we get a :tl etc MFC into 8, even
longer. All this time the ports tree must work with pmake.
I'm pretty sure I was told it is
On Thu, 25 Oct 2012 22:21:59 +0100, Chris Rees writes:
We really aren't going to have any luck yet...
[crees@pegasus]/usr/ports% sudo make MAKE=/usr/bin/bmake index | head
If anyone is eager to play with this, I just have put a copy of
ports2bmake.tar.gz in ~sjg/ on freefall.
This contains a
On Thu, 25 Oct 2012 23:01:27 +0100, Chris Rees writes:
Is there a Wiki page where the actual benefits of moving to bmake are
made clear? This is a major, *major* upheaval, and having two
versions of bsd.port.mk for years is simply not an option.
There is no need/plan for two versions of
On Sat, 13 Oct 2012 15:15:59 -0400, George Neville-Neil writes:
It could be a while (many weeks) before we get to 4, so the question
really is whether the people working on ATF are willing and able to
build and install FreeBSD using WITH_BMAKE?
=20
I think that's a small price to pay for
On Thu, 4 Oct 2012 09:42:29 -0700, Garrett Cooper writes:
I'd like to know what all is
being contributed back from Juniper in terms of tests, ATF integration
into the build system (which I've given back to marcel@/gnn@, but
We aim to contribute build improvments, and integration of ATF was part
On Tue, 2 Oct 2012 07:50:23 -0400, John Baldwin writes:
BTW, one general comment. There seem to be two completely independent
groups of folks working on ATF (e.g. there have been two different
imports of ATF into the tree in two different locations IIRC, and now
we have two different sets of
On Tue, 2 Oct 2012 07:19:55 -0700, Garrett Cooper writes:
We put the test cases in a subdir of the lib/prog
This has multiple benefits, and eliminates any impact on the normal
build of said libs/progs.
Hmmm... that's one of the 3 approaches I provided, but it turned out
to be annoying to make
Hi Garrett,
From: Garrett Cooper yaneg...@gmail.com
Subject: [CFT/RFC]: refactor bsd.prog.mk to understand multiple =
programs instead of a singular program
Date: September 2, 2012 11:01:09 PM PDT
To: freebsd-hackers@freebsd.org
Cc: freebsd-a...@freebsd.org Arch freebsd-a...@freebsd.org
=20
Not to mention the fact that bsd.prog.mk goes from being relatively
simple, to unspeakably hard to read, and all for rather limited =
return.
This btw I think is the more important issue.
I was looking at bsd.prog.mk in netbsd the other day.
It has no business being that complex.
Getting back
30 matches
Mail list logo
