OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => OpenBSD => Topic started by: iamasmith on March 13, 2006, 07:34:15 am
-
I thought I would offer up my build environment for people to consider because it gives a little flexibility in maintaining the ports collection both on your Zaurus and on your desktop OpenBSD machine.
The idea behind this build environment is that you can maintain ports trees with arm and i386 binaries present in the trees and only have to lose the object files when you need to update from CVS. The advantage of this is that if you have a build that mostly completes on the Zaurus but fails part way through you can try the same build on the i386 desktop machine without having to clean the build directory of arm binaries - that way you can return to the zaurus build later and save a lot of time rebuilding.
The build environment uses shadow directories quite heavily to avoid pollution of the cvs - which is maintained pristine so that normal cvs updates will keep you in sync with the latest -current environment. The main dependency of the environment is that you have a partition that you can mount in the same location on both the OpenBSD desktop system and the Zaurus. I achieve this by having an ffs partition mounted on the desktop machine at /obsdarc which is shared out by NFS and mounted to /obsdarc on the Zaurus.
Step 1.
Prepping the environment on the desktop machine...
Create a directory structure like this...
cd /obsdarc
mkdir -p {cvs,zaurus,ports-persist/{distfiles,packages}}
The idea behind the ports-persist directory structure is that we shall maintain a shared location of downloaded sources (distfiles) and a shared location for output packages since the output location is broken down by architecture this does not represent a problem for us. The advantage here is that when the source shadow trees are cleared we keep our build packages and previously downloaded source files.
Step 2.
Check out cvs to the cvs location as follows...
I use a mirror in Germany for my source tree and have a simple file called /obsdarc/cvs/cvsenv containing..
export CVSROOT=anoncvs@anoncvs2.de.openbsd.org:/cvs
Create yourself a suitable file containing the cvs location and checkout the CVS as follows...
cd /obsdarc/cvs
. ./cvsenv
cvs co ports
cvs co src
cvs co XF4
The above cvs example is checking out the whole OpenBSD source as well as the ports tree... you may want just the ports tree but this build environment works for all if you choose.
Step 3.
Create some update scripts.. I have 3 scripts called shadowpatch-ports.sh, shadowpatch-sys.sh and shadowpatch-XF4.sh...
Firstly the shadowpatch-ports.sh script...
#!/bin/sh
SRCLOC=/obsdarc/cvs
PPLOC=/obsdarc/ports-persist
DRIVERS=/obsdarc/drivers
MAINLOC=/usr
DUPLOC=/obsdarc/zaurus
#Recreate main location shadow directory
rm -rf $MAINLOC/ports
mkdir $MAINLOC/ports
lndir $SRCLOC/ports $MAINLOC/ports
cd $MAINLOC/ports
ln -s $PPLOC/* .
#<Apply Patches>
#</Apply Patches>
#Update secondary location for Zaurus
rm -rf $DUPLOC/ports
mkdir $DUPLOC/ports
cd $MAINLOC/ports
cp -R * $DUPLOC/ports
This script is the basic building block, you can assemble the script however you like for sys and XF4 if you choose to implement them too by simply changing the ports location to src etc.... below is an example of patches that I use from my shadowpatch-sys script... (note that the final cp -R is critical that you use uppercase R so that symlinks rather than files are copied).
#!/bin/sh
SRCLOC=/obsdarc/cvs
DRIVERS=/obsdarc/drivers
MAINLOC=/usr
DUPLOC=/obsdarc/zaurus
#Recreate main location shadow directory
rm -rf $MAINLOC/src
mkdir $MAINLOC/src
lndir $SRCLOC/src $MAINLOC/src
#<Apply Patches>
#Kern.visorpatch
cd $MAINLOC/src/sys/dev/usb
cp $DRIVERS/Kern.visorpatch/uvisor.c-ajs-clie.patch .
mv uvisor.c uvisor.c.orig.link
cp uvisor.c.orig.link uvisor.c
patch -p0 < uvisor.c-ajs-clie.patch
#Kern.ztsrotate
cd $MAINLOC/src/sys/arch/zaurus/dev
cp $DRIVERS/Kern.ztsrotate/zts.c.rotationpatch .
...
...
#</Apply Patches>
#Update secondary location for Zaurus
rm -rf $DUPLOC/src
mkdir $DUPLOC/src
cd $MAINLOC/src
cp -R * $DUPLOC/src
as you can see in this snippet I am using a location under /mnt/obsdarc called drivers to hold my private patches which I am applying to a copy of the file taken from the link.. I move the original link first then copy the file and in this manner the patch only updates the shadow directory and not the linked location (the original CVS). - also note the omission of the ln -s $PPLOC command in this version of the script.
As you can see these scripts maintain two shadow copies of the output locations such that you do not have to keep the build source on the Zaurus. Also note that the ln -s $PPLOC . command (in the ports script) is creating symlinks into the ports-persist structure so that it becomes shared between the two environments. You may therefore perform a build from the Desktop and then the Zaurus and the source files will already be available (note you want to remove that ln -s $PPLOC . command from any shadowpatch-sys or shadowpatch-XF4 that you may implement)..
on a final note for this step it is traditional to shadow link XF4 to /usr/Xbld so implement any shadowpatch-XF4 to link to that location.
Step 4.
Run those scripts..
Run the scripts that you created and you should have a directory structure present on your desktop that you can build from (for the src and XF4 trees too if you chose to implement those scripts).
You should also have a set of shadow directories located in /mnt/obsdarc/zaurus.
Step 5.
Create the Zaurus hookup..
Mount the volume to the same path as the desktop using nfs.. in this scenario I use /mnt/obsdarc
Now create the symlink locations as follows..
ln -s /obsdarc/zaurus/ports /usr/ports
rmdir /usr/src
ln -s /obsdarc/zaurus/src /usr/src
ln -s /obsdarc/zaurus/Xbld /usr/Xbld
Note that the initial directory structure for OpenBSD will have the /usr/src directory present so it is necessary to remove it.
Once these links are in place you may produce builds from the zaurus and since /sys is a symbolic link into the kernel source under /usr/src that link will take effect automatically.
OK, that's it...
Once set up you may periodically updated the cvs and simply run the scripts to shadow the directories and you will have immediate version sync for the sources for both the desktop and the zaurus.
One last thing that is worth mentioning... how do you tell which ports that you want to update between version sync (it is important that you do this)...
In the directory /usr/ports/infrastructure/build is as script called out-of-date. This script audits all the packages that you have installed and compares them against ports available in the ports tree producing a list of packages that need to be updated. If you have never done this before it may take a while to update everything reported using make update but it is worthwhile doing it after every cvs update to ports. (note that this script takes a helluva long time to run on the zaurus).
One final thing to note about the out of date script is that you may get this specific message..
Outdated ports:
devel/gettext # expat.4.0 -> expat.5.0
lang/python/2.3,-expat # expat.4.0 -> expat.5.0
This message is telling me that gettext and python-expat are linked against version 4.0 of the expat library and that version 5 is available on the system. Ignore anything related to version 4.0 expat!
Version 4.0 expat is present in the ports system and all ports are built against that version. Version 5 libraries, however, are present in XF4... this causes the script to say there is a later version available. The ports system will never link against version 5.0 unless it is brought into the ports system and since 5.0 expat doesn't exist in ports this isn't going to happen. The official response to this is to ignore the out of date warnings for expat until the OpenBSD team decides how to cleanly handle this in the future.
-Andy
-
ok Andy... since you've established yourself as openbsd-on-the-zaurus-hacker-extraordinaire
have you managed to get things cross compiled cleanly by any chance? from what I understand it is unsupported and not recommended, but it sure would be nice....
-
ok Andy... since you've established yourself as openbsd-on-the-zaurus-hacker-extraordinaire
have you managed to get things cross compiled cleanly by any chance? from what I understand it is unsupported and not recommended, but it sure would be nice....
[div align=\"right\"][a href=\"index.php?act=findpost&pid=118361\"][{POST_SNAPBACK}][/a][/div]
I haven't actually tried Sequethin since with my new 10/100 CF card and Microdrive perf tunings (also now I switched to an OpenBSD desktop too NFS3 seems to help a lot also) I can build most things over night and I know that most things will build - even built Gnumeric with a lot of dependencies over night
If you want to take a look at the cross tools stuff the make stuff is in /usr/src/Makefile.cross
I think you just do
make cross-tools TARGET=zaurus
to build them... then you would obviously have to build a cross-distrib for stuff to link against and then you would need to rewrite /usr/share/mk/* and all the ports definitions to be cross compile aware if you wanted to use the ports tree... sounds like a lot of work
-Andy
-
actually, I have an OpenBSD VMWare machine that I don't mind screwing up... I'll try the first bit and let you know how 'thorny' it looks after that..
EDIT:*argh* later... I need to rebuild that VM because it ran out of disk space.
-Andy
-
ok, after the first step.. (make cross-tools TARGET=zaurus) you have a /usr/cross/zaurus directory on your OpenBSD system with binutils, gcc and base libraries in the subdirectories... you will need to do a lot more (I think instructions are on the openbsd site) to build the X libraries into this structure but if you want to play with cross compilation this is a start.
-Andy
-
ok, after the first step.. (make cross-tools TARGET=zaurus) you have a /usr/cross/zaurus directory on your OpenBSD system with binutils, gcc and base libraries in the subdirectories... you will need to do a lot more (I think instructions are on the openbsd site) to build the X libraries into this structure but if you want to play with cross compilation this is a start.
-Andy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=118397\"][{POST_SNAPBACK}][/a][/div]
I might just go for the nfs idea you mentioned earlier. Now it's just a matter of whether I can/should wait for 3.9 or get started this weekend. (I did some screw things with ports and deps so I need to start fresh )
Thanks for the work you're putting into this! It's nice to know there's at least one person posting in here more than once a year haha
-
An important update to this posting... I have changed the mount point suggested from /mnt/obsdarc to /obsdarc.
This is particularly important if you want to do make release which builds the installation tarballs. I discovered last night that part of this process uses the /mnt point to mount a vnd device which is used during the image creation. When this happens the scripts are abviously lost because the links are no longer valid.
I would suggest moving your mount points to something off root and editing the update scripts if you want to make release.
For more info see release(8)
-Andy