Hello,
I have the kernel sources not in /usr/src/sys, but elsewhere;
I can not get set correctly SYSDIR via /etc/make.conf for some
ports (or other values like USE_GCC, ...);
if I have in /etc/make.conf these lines:
.if ${.CURDIR:M*/multimedia/cuse4bsd-kmod*}
SYSDIR=/usr/home/guru
On 09/06/2013 23:46, Matthias Apitz wrote:
Hello,
I have the kernel sources not in /usr/src/sys, but elsewhere; I can
not get set correctly SYSDIR via /etc/make.conf for some ports (or
other values like USE_GCC, ...);
if I have in /etc/make.conf these lines:
.if ${.CURDIR:M*/multimedia
El día Monday, June 10, 2013 a las 03:03:07AM +0930, Shane Ambler escribió:
it works, but if I let away the '*' in the line, i.e.
.if ${.CURDIR:M*/multimedia/cuse4bsd-kmod}
SYSDIR=/usr/home/guru/head/src/sys
.endif
the 'make' asks me to set SYSDIR:
...
You'll find the
No, I'm just borderline sure that WITHOUT_MODULES works
the same way as MODULES_OVERRIDE, that is it looks in
top directory in /usr/src/sys/modules/ and ulpt is in
/usr/src/sys/modules/usb/ulpt
Speaking of RAM savings, things you would always load
should be compiled in kernel, modules per
to start -- the more precise you can define your
test setting and its variables, the better you can diagnose the
problem.
In /etc/make.conf, you could use MODULES_OVERRIDE to define the
set of modules you want (because only _those_ will then be
build) and keeping their functionality out
Sort of a dirty trick that you have to use usb/ulpt as
opposed to ulpt, and a deficiency in the documentation.
No, I'm just borderline sure that WITHOUT_MODULES works
the same way as MODULES_OVERRIDE, that is it looks in
top directory in /usr/src/sys/modules/ and ulpt is in
through man make.conf and man src.conf and couldn't find what you
mean by the new means of /etc/src.conf .
I saw references to WITHOUT_MODULES in man make.conf but not man src.conf.
Would
WITHOUT_MODULES= ulpt
work better in /etc/src.conf than in /etc/make.conf ?
I have
WITHOUT_MODULES= ulpt
you can diagnose the
problem.
In /etc/make.conf, you could use MODULES_OVERRIDE to define the
set of modules you want (because only _those_ will then be
build) and keeping their functionality out of the kernel. In
this case, you have control over your test setting using the
modules.
The same files
Try with:
WITHOUT_MODULES= usb/ulpt
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/WITHOUT-MODULES-in-etc-make-conf-doesn-t-work-tp5723832p5723880.html
Sent from the freebsd-questions mailing list archive at Nabble.com.
___
and consider using MODULES_OVERRIDE if you will
precisely know your needs.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/WITHOUT-MODULES-in-etc-make-conf-doesn-t-work-tp5723832p5723883.html
Sent from the freebsd-questions mailing list archive at Nabble.com.
How does one, when building the kernel, prevent building one or more modules?
I have
WITHOUT_MODULES= ulpt
in /etc/make.conf
but ulpt.ko always appears in /boot/kernel directory.
For now, I want to build all modules except for this one, but perhaps I could
keep everything in kernel config
On Mon, 02 Jul 2012 22:59:44 -0400, Thomas Mueller wrote:
How does one, when building the kernel, prevent building one or more modules?
Use the new means of /etc/src.conf (see man src.conf for
details) to prevent the building of modules.
I have
WITHOUT_MODULES= ulpt
in /etc/make.conf
I think MODULES_OVERRIDE is for building only a few modules instead of a large
number of modules?
true. definitely works for me.
Alternatively, how can I prevent ulpt.ko from automatically loading when I
connect a USB printer (HP) that is supposed to work with ugen but not ulpt.
Dear ALL,
The subject says it all. I'm trying to push out of my box every ounce of
performance, perhaps even with (yet experimental) path64 compiler. So my
question is as simple as that: what is the precise spell to put in
make.comf to get (while not disrupting the ports infrastructure!)
A while ago, at least a year or more I would guess, I saw something
about placing a couple of entries in the /etc/make.conf file to
correct a problem with Firefox. I am currently using Firefox-6.0.1 on
FreeBSD-8.2. These are the entries I am wondering about:
WITH_MOZILLA=firefox
WITH_GECKO=libxul
On Sun, 4 Sep 2011 07:27:28 -0400, Carmel wrote:
A while ago, at least a year or more I would guess, I saw something
about placing a couple of entries in the /etc/make.conf file to
correct a problem with Firefox. I am currently using Firefox-6.0.1 on
FreeBSD-8.2. These are the entries I am
On 04/09/2011 12:27, Carmel wrote:
WITH_MOZILLA=firefox
This seems to be obsolete -- there's no choice to use firefox available.
Grepping the ports tree produces only 2 ports that mention WITH_MOZILLA
(mail/mail-notification and deskutils/google-gadgets) and in those
cases, WITH_MOZILLA is an
On Sun, Aug 01, 2010 at 07:28:24AM -0400, Jerry wrote:
I have been having problems with several different programs lately.
Would there be any serious drawback to simply setting: WITH_DEBUG=
in the /etc/make.conf file to force everything I build/rebuild to be
built with debug symbols
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Smith wrote:
On Sun, Aug 01, 2010 at 07:28:24AM -0400, Jerry wrote:
I have been having problems with several different programs lately.
Would there be any serious drawback to simply setting: WITH_DEBUG=
in the /etc/make.conf file to force
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
From owner-freebsd-questi...@freebsd.org Sun Aug 1 06:28:18 2010
Date: Sun, 1 Aug 2010 07:28:24 -0400
From: Jerry freebsd.u...@seibercom.net
To: freebsd-questions@freebsd.org
Subject: Setting Debug flag in /etc/make.conf
I have been having problems with several different programs lately
Robert Bonomi bon...@mail.r-bonomi.com writes:
I have been having problems with several different programs lately.
Would there be any serious drawback to simply setting: WITH_DEBUG=
in the /etc/make.conf file to force everything I build/rebuild to be
built with debug symbols? I am assuming
I have been having problems with several different programs lately.
Would there be any serious drawback to simply setting: WITH_DEBUG=
in the /etc/make.conf file to force everything I build/rebuild to be
built with debug symbols? I am assuming that I can simply place that
flag in the make.conf
. If you want to retain
it use DEBUG_FLAGS, e.g.
DEBUG_FLAGS = -ggdb
CFLAGS += ${DEBUG_FLAGS}
Ports that build using bsdmake don't really need the second line as well
as buildworld.
in the /etc/make.conf file to force everything I build/rebuild to be
built with debug symbols? I am assuming that I
I just acquired an older Gateway GT5220 with an AMD 62 Athlon-x2
dual processor. I want to set it up as a sort of test machine. There
does not seem to be a specific setting for 'cpu-type' or 'march' for
this machine. I have notices on some Linux forums that they recommend
using the 'native'
On Tue, 23 Feb 2010 06:41:04 -0500
Carmel carmel...@hotmail.com wrote:
I just acquired an older Gateway GT5220 with an AMD 62 Athlon-x2
dual processor. I want to set it up as a sort of test machine. There
does not seem to be a specific setting for 'cpu-type' or 'march' for
this machine. I
On 02/23/10 13:21, RW wrote:
On Tue, 23 Feb 2010 06:41:04 -0500
Carmelcarmel...@hotmail.com wrote:
I just acquired an older Gateway GT5220 with an AMD 62 Athlon-x2
dual processor. I want to set it up as a sort of test machine. There
does not seem to be a specific setting for 'cpu-type' or
I read somewhere that adding the following to the /etc/make.conf file
would improve system performance:
march=native
mtune=native
Is there any truth to this? I an running 32-bit I386 Freebsd on a
64-bit processor. The main reason being that the is (was) no native
64-bit drivers
is now
set in DEFAULTS, which is a small list of very important stuff that
every kernel of a certain architecture must contain in order to
function properly. It is not meant to be customizable.
4. In /etc/make.conf, I'm used to having, for example:
CPUTYPE?=core2
What would be my CPU in this case
by amd64 in my case), but the machine line
is missing entirely from GENERIC conf file. Should I add it?
4. In /etc/make.conf, I'm used to having, for example:
CPUTYPE?=core2
What would be my CPU in this case (Xeon L5506)? I know this line is
not necessary, but I'd like to set it to the most
I'm trying to overwrite a Makefile variable via /etc/make.conf
It doesn't seem to work:
# cd /usr/ports/lang/gcc43
# grep NOT Makefile
NOT_FOR_ARCHS= alpha ia64
# grep -C1 NOT /etc/make.conf
.if ${.CURDIR:M*/lang/gcc4*}
NOT_FOR_ARCHS= ia64
.endif
# make
=== gcc-4.3.3_20090122 does not run
On Mon, 26 Jan 2009 12:55:29 +, Anton Shterenlikht me...@bristol.ac.uk
wrote:
I'm trying to overwrite a Makefile variable via /etc/make.conf
It doesn't seem to work:
This behaviour is correct. The local makefiles have precedence
before the /etc/make.conf settings.
What am I doing wrong
On Monday 26 January 2009 05:06:48 Polytropon wrote:
On Mon, 26 Jan 2009 12:55:29 +, Anton Shterenlikht me...@bristol.ac.uk
wrote:
I'm trying to overwrite a Makefile variable via /etc/make.conf
It doesn't seem to work:
This behaviour is correct. The local makefiles have precedence
Anton Shterenlikht me...@bristol.ac.uk writes:
I have:
# uname -srm
FreeBSD 6.4-STABLE alpha
#
In /etc/make.conf I have
.if ${.CURDIR:M*/lang/gcc*}
NOT_FOR_ARCHS=
.endif
However, I get:
# cd /usr/ports/lang/gcc43
# make
=== gcc-4.3.3_20090101 does not run
I have:
# uname -srm
FreeBSD 6.4-STABLE alpha
#
In /etc/make.conf I have
.if ${.CURDIR:M*/lang/gcc*}
NOT_FOR_ARCHS=
.endif
However, I get:
# cd /usr/ports/lang/gcc43
# make
=== gcc-4.3.3_20090101 does not run on alpha ia64, while you are running
alpha.
*** Error code
Hi All,
I've many times successfully gone to 7.0 or 8.0 current.
cat EOF /etc/make.conf
NO_ATM=true # do not build ATM related programs and libraries
NO_AUTHPF=true # do not build and install authpf (setuid/gid)
NO_FORTRAN=true # do not build g77 and related libraries
NO_GAMES=true
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a document that describes what is available, and what each one does?
As an example, I took a peak at the nanoBSD documentation, and they have one
that is 'NO_BIND' listed ... does that mean nslookup won't work, or you just
can't run a
On 5/18/07, Marc G. Fournier [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a document that describes what is available, and what each one does?
As an example, I took a peak at the nanoBSD documentation, and they have one
that is 'NO_BIND' listed ... does that
On 5/18/07, Schiz0 [EMAIL PROTECTED] wrote:
On 5/18/07, Marc G. Fournier [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a document that describes what is available, and what each one does?
As an example, I took a peak at the nanoBSD documentation, and they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Never even thought about man ... perfect, thank you :)
- --On Friday, May 18, 2007 13:44:39 -0400 Schiz0 [EMAIL PROTECTED]
wrote:
On 5/18/07, Marc G. Fournier [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a
... perfect, thank you :)
Typical of unix variants, this cat's skin is removed
at least one other way:
$ less /usr/share/examples/etc/make.conf
--
--
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
On Tuesday 09 January 2007 10:46, Oliver Fromme wrote:
Hi,
I'm trying to write an appropriate CPUTYPE entry for
/etc/make.conf for the following machine:
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2799.95-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf41 Stepping = 1
Features
On 1/9/07, Oliver Fromme [EMAIL PROTECTED] wrote:
Hi,
I'm trying to write an appropriate CPUTYPE entry for
/etc/make.conf for the following machine:
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2799.95-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf41 Stepping = 1
Features=0xbfebfbffFPU,VME
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nikolas Britton wrote:
On 1/9/07, Oliver Fromme [EMAIL PROTECTED] wrote:
Hi,
I'm trying to write an appropriate CPUTYPE entry for
/etc/make.conf for the following machine:
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2799.95-MHz 686-class CPU
Hi,
I'm trying to write an appropriate CPUTYPE entry for
/etc/make.conf for the following machine:
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2799.95-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf41 Stepping = 1
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC
Hi,
I'm trying to get a little more speed out of my 600MHz mini-itx box as
I convert it into a FReeBSD fileserver (with GUI) . . .
I'm trying to find the right settings for /etc/make.conf and would
appreciate your help.
dmesg.boot shows the processor as being:
CPU: VIA C3 Samuel 2 (601.37-MHz
Owen G wrote:
I'm trying to get a little more speed out of my 600MHz mini-itx box as
I convert it into a FReeBSD fileserver (with GUI) . . .
I'm trying to find the right settings for /etc/make.conf and would
appreciate your help.
dmesg.boot shows the processor as being:
CPU: VIA C3 Samuel 2
I don't know if I'm being a dope about this, but I can't seem to figure
out how to get libc.so.3 compiled and installed in FreeBSD 6.x.
Previously (at least in FreeBSD 5.x), the backwards-compatible libcs could
be found in /usr/src/lib/compat, and setting the appropriate option in
/etc
/src/lib/compat, and setting the appropriate option in
/etc/make.conf (e.g. COMPAT3X=yes, etc.) would ensure that the desired
library would be built and installed.
In FreeBSD 6.x, however, those make.conf directives appear to be
unavailable and the compat libraries do not exist in the source
At 2:28pm today, Erik Trulsson wrote:
ET The misc/compat[345]x ports, are what you are supposed to use. The
ET libraries included in the misc/compat3x port does appear to have some
ET security problems that nobody has fixed, and the port is therefore
ET marked FORBIDDEN. (I don't think there
This is probably a stupid question, but I have never let a silly thing
like that stop me before.
I have FreeBSD 5.4 installed. In my /etc/make.conf file I have this
line:
BATCH=yes
I have it there so I am not bothered with requests for OPTIONS when
building ports. I have known
On Friday 11 November 2005 07:10, Gerard Seibert wrote:
This is probably a stupid question, but I have never let a silly thing
like that stop me before.
I have FreeBSD 5.4 installed. In my /etc/make.conf file I have this
line:
BATCH=yes
I have it there so I am not bothered with requests
in the /etc/make.conf, which expects things like:
#SENDMAIL_CFLAGS=
#SENDMAIL_LDFLAGS=
#SENDMAIL_LDADD=
#SENDMAIL_DPADD=
to accomplish this?
--
Ca. Tas. Tro. Phy.
-John Smedley, March 28th 1998, 3AM
Dan Mahoney
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144
, and inet6
What would I put in the /etc/make.conf, which expects things like:
Something like:
#SENDMAIL_CFLAGS+= -DMILTER -DSTARTTLS -DHASURANDOMDEV
#SENDMAIL_CFLAGS+= -I/usr/local/ssl/include -I/usr/local/include
#SENDMAIL_CFLAGS+= -DSASL=2
#SENDMAIL_LDFLAGS+= -L/usr/local/ssl/lib
#SENDMAIL_LDADD
On Thursday 19 May 2005 20:51, Kris Kennaway wrote:
On Thu, May 19, 2005 at 03:31:02PM -0400, Nicolas Blais wrote:
Hi,
This is probably a user problem (me), but why is it that when I put this
in /etc/make.conf:
.if ${.CURDIR:M*/multimedia/transcode}
WITH_DIVX5=yes
On Fri, May 20, 2005 at 03:13:08PM +0100, RW wrote:
On Thursday 19 May 2005 20:51, Kris Kennaway wrote:
On Thu, May 19, 2005 at 03:31:02PM -0400, Nicolas Blais wrote:
Hi,
This is probably a user problem (me), but why is it that when I put this
in /etc/make.conf
Hi,
This is probably a user problem (me), but why is it that when I put this
in /etc/make.conf:
.if ${.CURDIR:M*/multimedia/transcode}
WITH_DIVX5=yes WITH_OPTIMIZED_CFLAGS=yes
.endif
and build transcode, it will only receive WITH_DIVX5 and not the other flag.
and if I put this instead
On Thu, May 19, 2005 at 03:31:02PM -0400, Nicolas Blais wrote:
Hi,
This is probably a user problem (me), but why is it that when I put this
in /etc/make.conf:
.if ${.CURDIR:M*/multimedia/transcode}
WITH_DIVX5=yes WITH_OPTIMIZED_CFLAGS=yes
.endif
and build transcode, it will only
On May 19, 2005 03:51 pm, Kris Kennaway wrote:
On Thu, May 19, 2005 at 03:31:02PM -0400, Nicolas Blais wrote:
Hi,
This is probably a user problem (me), but why is it that when I put this
in /etc/make.conf:
.if ${.CURDIR:M*/multimedia/transcode}
WITH_DIVX5=yes WITH_OPTIMIZED_CFLAGS
I have tried googling for this information, but without any concrete results.
In the '/etc/make.conf' file, what are the advantages between using the
following declaration?
CPUTYPE=i686
Versus
CPUTYPE=p4
In the above scenario, the number following the letter 'p' could be between one
On 01/18/05 11:01:32, Gerard Seibert wrote:
I have tried googling for this information, but without any concrete
results. In the '/etc/make.conf' file, what are the advantages
between
using the following declaration?
CPUTYPE=i686
Versus
CPUTYPE=p4
In the above scenario, the number following
In regards to using the 'CPUTYPE=' directive in the '/etc/make.conf' file,
would it be advisable to use the CPU type; i.e., p2 for instance rather
than i686. This is assuming that the processor is detected by FreeBSD as
an Intel PII, i686 as an example.
Is there an advantage to using the 'p
] On Behalf Of Gerard Seibert
Sent: Wednesday, December 29, 2004 7:33
To: freebsd-questions
Subject: CPUTYPE directive options in /etc/make.conf
In regards to using the 'CPUTYPE=' directive in the '/etc/make.conf' file,
would it be advisable to use the CPU type; i.e., p2 for instance rather
Roberto Nunnari [EMAIL PROTECTED] writes:
As announced yesterday..
..today I finished the upgrade process and all went just fine.
...have you had the chance to find out whether perl is needed at
all in 5.2.1?
I'm sorry, but I haven't.
[I just moved to a new house this week and I can't
As announced yesterday..
..today I finished the upgrade process and all went just fine.
...have you had the chance to find out whether perl is needed at
all in 5.2.1?
Best regards.
Lowell Gilbert wrote:
Henrik W Lund [EMAIL PROTECTED] writes:
Roberto Nunnari wrote:
Thank you all for your
Hi all.
Please also reply to my mailbox, as I'm not on the list.
Thank you!
Can anybody tell me about /etc/make.conf in FreeBSD-5.2.1 ??
Yesterday I moved away /etc/make.conf that looked like this:
pcm2028.dti.supsi.ch# cat /etc/make.conf.back
# -- use.perl generated deltas -- #
# Created: Thu Nov
Hi all.
Please also reply to my mailbox, as I'm not on the list.
Thank you!
Can anybody tell me about /etc/make.conf in FreeBSD-5.2.1 ??
Yesterday I moved away /etc/make.conf that looked like this:
pcm2028.dti.supsi.ch# cat /etc/make.conf.back
# -- use.perl generated deltas
Roberto Nunnari wrote:
Hi all.
Please also reply to my mailbox, as I'm not on the list.
Thank you!
Can anybody tell me about /etc/make.conf in FreeBSD-5.2.1 ??
Yesterday I moved away /etc/make.conf that looked like this:
pcm2028.dti.supsi.ch# cat /etc/make.conf.back
# -- use.perl generated deltas
Thank you all for your answers.
one more questions...
What is the preferred/advised version for buildWorld and co?
Henrik W Lund wrote:
Roberto Nunnari wrote:
Hi all.
Please also reply to my mailbox, as I'm not on the list.
Thank you!
Can anybody tell me about /etc/make.conf in FreeBSD-5.2.1
Roberto Nunnari wrote:
Thank you all for your answers.
one more questions...
What is the preferred/advised version for buildWorld and co?
Without knowing for sure, I'd say the base version of perl is the best
one to use for the whole build* and install* process.
-Henrik W Lund
On Wed, Aug 11, 2004 at 11:20:12AM -0400, Steve Bertrand wrote:
NOPERL=yo
NO_PERL=yo
NO_PERL_WRAPPER=yo
Is yo kind of like maybe? ;o)
Perhaps this could be related to the problem you are having. The
values should either be yes, or no.
Not so. The test is if 'NOPERL' is *defined* or
Henrik W Lund [EMAIL PROTECTED] writes:
Roberto Nunnari wrote:
Thank you all for your answers.
one more questions...
What is the preferred/advised version for buildWorld and co?
Without knowing for sure, I'd say the base version of perl is the best
one to use for the whole build*
I just did:
# use.perl system
# make buildworld
on yesterday's RELENG_5_2 and it seems it has finished
successfully the build..
tomorrow I'll try buildkernel + install and I'll report
the results here. To be true, though, I have no idea
if perl is used or not during the build process..
Best
[EMAIL PROTECTED]
Cc: Roberto Nunnari [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, August 11, 2004 1:47 PM
Subject: Re: /etc/make.conf
Henrik W Lund [EMAIL PROTECTED] writes:
Roberto Nunnari wrote:
Thank you all for your answers.
one more questions...
What
I'm curious - I have an AthlonXP cpu, and I seen on several posts where
people have listed, CPUTYPE?=athlon-xp in /etc/make.conf.
My question is this, what are the ramifications if I added that to my
/etc/make.conf now, after my current device has had nothing in the
before mentioned file.
How
Chris wrote:
I'm curious - I have an AthlonXP cpu, and I seen on several posts
where people have listed, CPUTYPE?=athlon-xp in /etc/make.conf.
My question is this, what are the ramifications if I added that to my
/etc/make.conf now, after my current device has had nothing in the
before
as a subsequent build.
As for valid CPUTYPE values, have you checked out the manpage?
man make.conf
I'm pretty sure I've seen it in there somewhere.
/usr/share/examples/etc/make.conf is where it is described.
HTH
Regards,
Mark
___
[EMAIL PROTECTED] mailing list
http
Best regards,
Chris
On Mon, 26 Jul 2004, Henrik W Lund wrote:
Chris wrote:
I'm curious - I have an AthlonXP cpu, and I seen on several posts where
people have listed, CPUTYPE?=athlon-xp in /etc/make.conf.
My question is this, what are the ramifications if I added that to my
/etc/make.conf now
Don't worry about recompiling everything right away. Gnome takes a long
time to compile! The cpu type does seem to help multimedia apps and WMs if
they were designed to take advantage of the extra instructions.
I usually get a machine up and then change the cpu type after I have the
basics
/make.conf in 5.x, or you can look at it in CVS
via
http://www.freebsd.org/cgi/cvsweb.cgi/src/share/examples/etc/make.conf )
Otherwise, port specific make flags can be found generally by
inspecting the Makefiles for each port, or the Makefiles under
/usr/ports/Mk. Each of the Makefiles in /usr/ports/Mk
where can i find info about possible options in make.conf for ports
builder
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
On Mon, Jul 19, 2004 at 10:42:08AM +0200, Wojciech Puchar wrote:
where can i find info about possible options in make.conf for ports
builder
Look at the ports(7) man page and the default make.conf (which is
/etc/defaults/make.conf under 4.x, and
/usr/share/examples/etc/make.conf in 5.x, or you
builder
Look at the ports(7) man page and the default make.conf (which is
/etc/defaults/make.conf under 4.x, and
/usr/share/examples/etc/make.conf in 5.x, or you can look at it in CVS
via
http://www.freebsd.org/cgi/cvsweb.cgi/src/share/examples/etc/make.conf )
that's what i needed. thank
In my /etc/make.conf I have:
FETCH_CMD = /usr/local/bin/wget
When I go to build a port (in this case, kde3), it goes to fetch gettext
(for example), then I get:
wget: illegal option --
Then it stops. I've updated wget to 1.8.2, with the same result. So now
I've #'d out that line in make.conf
On Tue, Mar 02, 2004 at 02:14:39PM -0500, Glenn Sieb wrote:
In my /etc/make.conf I have:
FETCH_CMD = /usr/local/bin/wget
When I go to build a port (in this case, kde3), it goes to fetch gettext
(for example), then I get:
wget: illegal option --
Then it stops. I've updated wget
Jonathan Chen wrote:
The recent updates to the ports/Mk/* files restricts the FETCH_CMD to
/usr/bin/fetch. Why would you use wget instead of the base-system's
fetch to build the ports anyway?
Because fetch used to break horribly under our stateful ipf firewall at
the office.
Because wget
=p2 in my
/etc/make.conf because its example, e.g. CPUTYPE?=p2, didn't 'take' anywhere,
not even building kernel world.
BTW this is one parm I must override, as this is an early p2 chip and it does
not have much of what is assumed in later i686 chips. I had been seeing some
unexplainable glitches
for this discussion is specifically how to prevent
overriding a port's own setting for that parm, and to provide a
default setting -O[1] when the port does not set it at all?
Well-behaved ports respect CFLAGS, meaning that you can define that variable
in /etc/make.conf (or on the command line when you
is specifically how to prevent
overriding a port's own setting for that parm, and to provide a
default setting -O[1] when the port does not set it at all?
Well-behaved ports respect CFLAGS, meaning that you can define that variable
in /etc/make.conf (or on the command line when you invoke make
Richard Coleman [EMAIL PROTECTED] writes:
Unless there is evidence of more recent gcc bugs, that part of the
handbook should really be removed.
There's plenty of such evidence.
In fact, reports of FreeBSD bugs should be pretty much ignored unless
they can be reproduced with -O.
for that parm, and to provide a
default setting -O[1] when the port does not set it at all?
Well-behaved ports respect CFLAGS, meaning that you can define that variable
in /etc/make.conf (or on the command line when you invoke make), and the port
should use that value when building the software
Paul Seniura wrote:
Chapter 2 of FreeBSD Developers' Handbook:
| 2.4 Compiling with cc
|
| -O
|Create an optimized version of the executable. The compiler
|performs various clever tricks to try and produce an executable
|that runs faster than normal. You can add a number after the
speed up making the world?
|
|[...]
|* Also in /etc/make.conf, set CFLAGS to something like -O -pipe.
| The optimization -O2 is much slower, and the optimization
| difference between -O and -O2 is normally negligible.
|[...]
No mention of bugs there, either. In fact the book
to the
sheer manual labor it would take to code this up for each port.
The idea of having a test in /etc/make.conf struck me as the way to
go, since it is effectively 'sourced'-in and could contain some simple
shell logic operations.
I hope I'm explaining this correctly. ;)
I'd love to hear feedback
On Thu, Feb 12, 2004 at 06:17:03PM -0600, Paul Seniura wrote:
Hi y'all,
I'm trying to find a way to do a CFLAGS+='-O' if and only if such a
parm was not already provided before 'make' actually runs.
I had this coded with the single = sign, i.e. without ?= or +=, but
the process still
Hi Kris,
On Thu, Feb 12, 2004 at 06:17:03PM -0600, Paul Seniura wrote:
Hi y'all,
I'm trying to find a way to do a CFLAGS+='-O' if and only if such a
parm was not already provided before 'make' actually runs.
I had this coded with the single = sign, i.e. without ?= or +=, but
On Thu, Feb 12, 2004 at 09:56:08PM -0600, Paul Seniura wrote:
Hi Kris,
On Thu, Feb 12, 2004 at 06:17:03PM -0600, Paul Seniura wrote:
Hi y'all,
I'm trying to find a way to do a CFLAGS+='-O' if and only if such a
parm was not already provided before 'make' actually runs.
Just wondering if people wouldn't mind sharring their /etc/make.conf
settings with others.
Here's mine:
CPUTYPE?=p3
CFLAGS= -O -pipe
CXXFLAGS+= -fmemoize-lookups -fsave-memoized
NOPROFILE= true
USA_RESIDENT= yes
SUP=/usr/local/bin/cvsup
SUPFLAGS= -g -L 2
SUPHOST
On Feb 11, 2004, at 4:59 AM, Bryan Cassidy wrote:
Just wondering if people wouldn't mind sharring their /etc/make.conf
settings with others.
Here's what I use on -STABLE:
KERNCONF=NORMAL
#KERNCONF=GENERIC
CPUTYPE=pentium
CFLAGS= -O2 -pipe
COPTFLAGS= -O -pipe
BOOTWAIT=5000
#NO_CPU_FLAGS=true
IPFW2
However, I do use tcsh for shell operations and sh for scripting. I can see
the merit of not building BIND as you said. I checked the ports, and these
programs also exists in ports, I guess I can always build and install from
port after a fresh port cvsup if I need to later on.
Thanks.
On
1 - 100 of 116 matches
Mail list logo
