make.conf, kernel.conf, world.conf?

make.conf, kernel.conf, world.conf?

Post by jan » Fri, 19 Jul 2002 00:24:22



Doesnt using /etc/make.conf for buildworld configurations
only makes sense when you are building a new world on the
system you plan to install it on.

Think about buildkernel for a minute.
I like building different kernels for different hardware on
my network. I build the different versions on one box:

#make buildkernel KERNCONF=myconfig0
#make buildkernel KERNCONF=myconfig1

This works well because I put my kernel compilation overrides
(NO_MODULES say) into the kernel config file. I build as many
as I want, and then I can install them on the desired machine
and it no way affects my current machine.
I dont touch /etc/make.conf for kernel builds.

There ought to be an equivalent for buildworld that goes:
make buildworld worldconf=w1.conf
make buildworld worldconf=w2.conf

So I can keep my "world configs" seperate.

If you plan on building multiple worlds for other systems
(and dont want to rebuild your current system) are you
supposed to save a copy of your current make.conf, change
it before you build each destination world, and change it
back later?

The idea of make.conf for buildworld is right. But
keeping it in /etc has got to be wrong. Right?

Am I missing something here?

(Still looking at buildworld)

-Jan

 
 
 

make.conf, kernel.conf, world.conf?

Post by Jens Schweikhard » Fri, 19 Jul 2002 00:48:16




...
# The idea of make.conf for buildworld is right. But
# keeping it in /etc has got to be wrong. Right?

Wrong. This is a reasonable default.

# Am I missing something here?

Not sure. But do you know that make(1) accepts several makefiles
specified with -f file and that they are treated as if they were
concatenated (at least that's what POSIX says)? Maybe you can use this
to achieve your goal.

$ cat foo.mk  
NO_MODULES = bar
$ cat mf
all:
        echo $(NO_MODULES)
$ make -f mf
echo true
true
$ make -f foo.mk -f mf
echo bar
bar

Untested:

cd /usr/src
make -f /your/w1.conf -f Makefile buildworld

Regards,

        Jens
--
Jens Schweikhardt  http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

 
 
 

make.conf, kernel.conf, world.conf?

Post by annel.. » Fri, 19 Jul 2002 15:56:26



> Doesnt using /etc/make.conf for buildworld configurations
> only makes sense when you are building a new world on the
> system you plan to install it on.
> Think about buildkernel for a minute.
> I like building different kernels for different hardware on
> my network. I build the different versions on one box:
> #make buildkernel KERNCONF=myconfig0
> #make buildkernel KERNCONF=myconfig1
> This works well because I put my kernel compilation overrides
> (NO_MODULES say) into the kernel config file. I build as many
> as I want, and then I can install them on the desired machine
> and it no way affects my current machine.
> I dont touch /etc/make.conf for kernel builds.
> There ought to be an equivalent for buildworld that goes:
> make buildworld worldconf=w1.conf
> make buildworld worldconf=w2.conf
> So I can keep my "world configs" seperate.

The difference between building kernels and building world is
that "make buildworld" wipes out /usr/obj, i.e., you don't
generally store a bunch of "worlds" on your system at the same
time, whereas you may store a bunch of alternative kernels, or
build a kernel for a slow machine on a fast one, move it, etc.

Quote:> If you plan on building multiple worlds for other systems
> (and dont want to rebuild your current system) are you
> supposed to save a copy of your current make.conf, change
> it before you build each destination world, and change it
> back later?

Okay, how are you going to install them?  I read a while ago
something Matt Dillon wrote about nfs installs, and as I recall
he recommended that /usr/src and /usr/obj be mounted as such
(no symlinks etc) on the target machine.  So, one world at a time,
right? (But see below--you can put the output different places.)

I have successfully done an nfs install--actually on a laptop
running FreeBSD in vmware (running in Win2k)--following Matt's
directions (which I think were on the -stable mailing list).  In
fact some people regularly install via nfs in this way, running
the buildworld only once on the source machine, since they are
installing on many identical machines.

Quote:> The idea of make.conf for buildworld is right. But
> keeping it in /etc has got to be wrong. Right?
> Am I missing something here?

I guess if I regularly wanted to do a buildworld for alternative
machines, I'd write a script for each and keep it in $HOME/bin.
It would first cd /usr/src (because make reads the Makefile in the
directory from which it's called) and then use make buildworld with
whatever options on the command line I happened to want (this command
line being part of the script).

You could also have scripts that move the appropriate /etc/make.conf
into place for whatever configuration you wanted to use to build world.
I think this would be messier though.

You could also write makefile to include with the -f option, and keep it
in /usr/src, but the -f option overrides, as I understand it, the default
search for a makefile, so you need to make -f Makefile -f makeworld1 so
that the basic Makefile (and whatever other makefiles it incorporates
via .include statements) gets read first.

I think the script that cd's to /usr/src and then runs make buildworld
with appropriate options is probably the best way to go.  One option
would be the place where the object files...so on the fast machine with
huge amounts of disk space (at least 350MB per world) you could have a
bunch of different output directories (with their subdirs) that are then
mounted on the target as /usr/obj for installation (make installworld)
along with /usr/src from the "source" machine.

All that said, "make" is complicated and whatever you do, you want to
test it first to make sure (no pun intended) you get what you expect
(and read appropriate man pages first).

        Annelise

--
Annelise Anderson
Author of:               FreeBSD: An Open-Source Operating System for Your PC
Available from:  BSDmall.com and amazon.com
Book Website:    http://www.bittreepress.com/FreeBSD/introbook/      

 
 
 

make.conf, kernel.conf, world.conf?

Post by annel.. » Fri, 19 Jul 2002 16:25:54




>> Doesnt using /etc/make.conf for buildworld configurations
>> only makes sense when you are building a new world on the
>> system you plan to install it on.

An addendum to my response: as I recall you should do
make buildworld and make installworld with the same options.
Usually /etc/make.conf handles this for you--i.e., if you build
without profiled libraries, you install without profiled libraries
(so you don't try to install what hasn't been built).

Thus, if installing on a machine different from the one on which
"world" was built, you either want to use the same options to "make"
or configure /etc/make.conf in accordance with the build.

Heh, nobody said it would be easy, and nobody was right.

        Annelise

--
Annelise Anderson
Author of:               FreeBSD: An Open-Source Operating System for Your PC
Available from:  BSDmall.com and amazon.com
Book Website:    http://www.bittreepress.com/FreeBSD/introbook/      

 
 
 

make.conf, kernel.conf, world.conf?

Post by jan » Fri, 19 Jul 2002 17:44:52



>> So I can keep my "world configs" seperate.

> The difference between building kernels and building world is
> that "make buildworld" wipes out /usr/obj, i.e., you don't
> generally store a bunch of "worlds" on your system at the same
> time, whereas you may store a bunch of alternative kernels, or
> build a kernel for a slow machine on a fast one, move it, etc.

Suppose I want both -current, and -stable compiled and up to
date on the same box?

Quote:>> If you plan on building multiple worlds for other systems
>> (and dont want to rebuild your current system) are you
>> supposed to save a copy of your current make.conf, change
>> it before you build each destination world, and change it
>> back later?

> Okay, how are you going to install them?  I read a while ago
> something Matt Dillon wrote about nfs installs, and as I recall
> he recommended that /usr/src and /usr/obj be mounted as such
> (no symlinks etc) on the target machine.  So, one world at a time,
> right? (But see below--you can put the output different places.)

I use the nfs installs, all the time:
(On the destination computer:)




Does what its supposed to. Very well.

What I havent figured out how to do is:

cvsup src
mv /usr/src /usr/src.stable
cvsup src-stable
mv /usr/src /usr/src.current
cd /usr/src.stable
edit stableworld.conf, specify destination as /usr/obj.stable
make -f stableworld.conf buildworld
cd /usr/src.current
edit currentworld.conf, specify destination as /usr/obj.current
make -f currentworld.conf buildworld

Then I would install the 2 different worlds on 2 different boxes
using the nfs technique:




        make -f stableworld.conf installworld

and likewise when on syscurrent.
Note, I have no intention of installing either of these worlds
onto my compilerserver box. And yet the advice people are giving
is to update /etc/make.conf for constructing the builds.
(That cant be the right approach!)

I have not been able to figure out how to do this till now
because there seems to be a dependence on the src, and obj
being under /usr/src and /usr/obj respectively.
I have tried to use symlinks, but the buildworlds fail
and until now, I havent been able to figure out why
they fail. My workaround has been to dedicate a buildcurrent
box, and dedicate a buildstable box.

Im still studying buildworld, I have some ideas on how this
should work that I will present shortly.

Maybe this is a secret IQ test for freebsd users. If you
cant dedicate a box for building current, they dont want you to
compile and install it unless you can solve the buildworld
puzzle ??!

Jan

 
 
 

make.conf, kernel.conf, world.conf?

Post by Richard Cale » Fri, 19 Jul 2002 20:32:01


a> I have successfully done an nfs install--actually on a laptop
a> running FreeBSD in vmware (running in Win2k)--following Matt's
a> directions (which I think were on the -stable mailing list).  In
a> fact some people regularly install via nfs in this way, running
a> the buildworld only once on the source machine, since they are
a> installing on many identical machines.

It's really not a question of the machines being identical, but the
policy. I build once for 2 laptops a server and my desktop
machine. I count it as a feature that they all have exactly the same
build of the OS on them.

I've never found it necessary to tailor buildworld to a machine. I'm
sure it is necessary for some situations, but I'd guess for most
people buildworld is generic.

--

                                                 |<

 
 
 

make.conf, kernel.conf, world.conf?

Post by mic.. » Fri, 19 Jul 2002 22:21:22



> What I havent figured out how to do is:
> cvsup src
> mv /usr/src /usr/src.stable
> cvsup src-stable
> mv /usr/src /usr/src.current
> cd /usr/src.stable
> edit stableworld.conf, specify destination as /usr/obj.stable
> make -f stableworld.conf buildworld
> cd /usr/src.current
> edit currentworld.conf, specify destination as /usr/obj.current
> make -f currentworld.conf buildworld
> I have not been able to figure out how to do this till now
> because there seems to be a dependence on the src, and obj
> being under /usr/src and /usr/obj respectively.
> I have tried to use symlinks, but the buildworlds fail
> and until now, I havent been able to figure out why
> they fail. My workaround has been to dedicate a buildcurrent
> box, and dedicate a buildstable box.

Indeed this does not work well. For example i have done the following:
on my machine asmodee, i have a filesystem mounted on /asmodee and
i used to install the source tree here. So i had /asmodee/usr/src and
a symlink of /usr/src on that. Now the problem is that the buildworld
runs correctly, but the files under /usr/obj are found in the tree
beginning by
/usr/obj/asmodee/usr/src
and not under /usr/obj/usr/src. If on a NFS mounted machine you mount
/usr/src on asmodee:/usr/src and the same for /usr/obj then make
installworld does not work because of the /obj/asmodee/usr/. You can
solve that by mimicking the same file structure on the distant machine.
Presumably a similar trick could work in your case.
But this is very inconvenient, and i finally moved everything in the standard
place. Indeed it is an error to try non standard things and hope solving
the problems with symlinks. On the other hand, if you have a lot of
partitions on your disk, it is very easy to mount a stable source tree
on /usr/src and then a current source tree at the same place. You can
do the same for the /usr/obj compiled tree. This allows to do exactly
what you want with a minimal number of manipulations. All you need
is two spare partitions on disk (a mount hides what is previously below).

--
Michel Talon

 
 
 

make.conf, kernel.conf, world.conf?

Post by Steven G. Kar » Sat, 20 Jul 2002 01:00:08




Quote:

> Suppose I want both -current, and -stable compiled and up to
> date on the same box?

Several of the FreeBSD committers actually do this.  They
can build a -stable world on a -current box or vice versa.

Quote:

> What I havent figured out how to do is:

> cvsup src
> mv /usr/src /usr/src.stable
> cvsup src-stable
> mv /usr/src /usr/src.current
> cd /usr/src.stable
> edit stableworld.conf, specify destination as /usr/obj.stable
> make -f stableworld.conf buildworld
> cd /usr/src.current
> edit currentworld.conf, specify destination as /usr/obj.current
> make -f currentworld.conf buildworld

You're using the wrong cvsup supfile.  You want to use
/usr/share/examples/cvsup/cvs-supfile.   This will
grab the entire CVS repository and you need quite a
bit of disk space.  Once you have the repository, you
can do

setenv CVSROOT /home/ncvs
cd /usr/stable             <-- This can be any directory.
cvs checkout -r RELENG_4   <-- Freebsd-stable
cd /usr/current            <-- This can be any (other) directory.
cvs checkout               <-- Freebsd-current

--
Steve
http://troutmask.apl.washington.edu/~kargl/

 
 
 

make.conf, kernel.conf, world.conf?

Post by Steven G. Kar » Sat, 20 Jul 2002 02:07:27




Quote:

> Indeed this does not work well. For example i have done the following:
> on my machine asmodee, i have a filesystem mounted on /asmodee and
> i used to install the source tree here. So i had /asmodee/usr/src and
> a symlink of /usr/src on that. Now the problem is that the buildworld
> runs correctly, but the files under /usr/obj are found in the tree
> beginning by
> /usr/obj/asmodee/usr/src
> and not under /usr/obj/usr/src. If on a NFS mounted machine you mount
> /usr/src on asmodee:/usr/src and the same for /usr/obj then make
> installworld does not work because of the /obj/asmodee/usr/. You can
> solve that by mimicking the same file structure on the distant machine.
> Presumably a similar trick could work in your case.

make -DMAKEOBJDIRPREFIX=/obj/asmodee installworld

--
Steve
http://troutmask.apl.washington.edu/~kargl/

 
 
 

make.conf, kernel.conf, world.conf?

Post by Drew Laws » Sat, 20 Jul 2002 02:57:13




Quote:>You're using the wrong cvsup supfile.  You want to use
>/usr/share/examples/cvsup/cvs-supfile.   This will
>grab the entire CVS repository and you need quite a
>bit of disk space.

Not so much by current standards.  The CVS reporitory on my machine
is about 1.5GB.

--
Drew Lawson            |  It's not enough to be alive

 
 
 

make.conf, kernel.conf, world.conf?

Post by Steven G. Kar » Sat, 20 Jul 2002 03:16:15






>>You're using the wrong cvsup supfile.  You want to use
>>/usr/share/examples/cvsup/cvs-supfile.   This will
>>grab the entire CVS repository and you need quite a
>>bit of disk space.

> Not so much by current standards.  The CVS reporitory on my machine
> is about 1.5GB.

I recycle old scsi hard drives with 2 to 8 GB capacities from
machines thrown out by colleagues, so 1.5 GB is huge. :-)

--
Steve
http://troutmask.apl.washington.edu/~kargl/

 
 
 

make.conf, kernel.conf, world.conf?

Post by mic.. » Sat, 20 Jul 2002 07:02:03





> make -DMAKEOBJDIRPREFIX=/obj/asmodee installworld

Dear Steven,
you have an intimate knowledge of all the bells and whistles in
Makefile.inc1 !
Indeed, this is not documented at start, but later on
MAKEOBJDIRPREFIX?=      /usr/obj
Thanks a lot.

--
Michel Talon

 
 
 

make.conf, kernel.conf, world.conf?

Post by Steven G. Kar » Sun, 21 Jul 2002 00:21:51







>> make -DMAKEOBJDIRPREFIX=/obj/asmodee installworld

> Dear Steven,
> you have an intimate knowledge of all the bells and whistles in
> Makefile.inc1 !
> Indeed, this is not documented at start, but later on
> MAKEOBJDIRPREFIX?=      /usr/obj
> Thanks a lot.

It is hardly intimate.  I run into problems like you, but
then I poke around in the various Makefiles to try to
understand and fix the problem.  Makefile.inc1 is probably
the file everyone should spend some time reading.  I've run
FreeBSD since it was known as 386BSD 0.0 + patchkit, so I
do have some accumulated knowledge of the "FreeBSD way";
I suppose I just don't communicate that knowledge very well
here in c.u.b.f.m.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

 
 
 

1. Can I define srm.conf, access.conf in httpd.conf ?

I defined ErrorDocument 403 /sorry.htm
in srm.conf, because I found this instruction in this file in a commented
line with examples.

I Found I can define ErrorDocument in httpd.conf file instead of srm.conf
I didn't know this.

What I don't know is, If I can define all my src.conf and access.conf inside
httpd.conf
or only some instructions.

Thanks

--

Gerardo Blanco

2. Opinions Wanted ISP ISDN

3. Pine 3.95 and pine.conf/pine.conf.fixed

4. Maxtor FTP site

5. /etc/inetd.conf, /etc/xinetd.conf

6. Q: Is there a newer c++ compiler available?

7. sgen.conf st.conf questions.

8. 5/11 sound/oss replace cli()

9. dhclient.conf to add dns in resolv.conf

10. ipf.conf /ipf.rules/ ipnat.rules or conf

11. netsvc.conf vs irs.conf

12. deleted isapnp.conf and conf.modules

13. 4th USENIX Conf on Object-Oriented Tech and Sys (COOTS) - Conf Program