HowTo compile additional code

How To Compile Additional Code

• load IPCop sources
• load packages used on IPCop with ./make.sh prefetch
• get the precompiled toolchain to save much time when building with ./make.sh gettoolchain
• compile the whole distribution with ./make.sh build

Then you have all necessary tools to be able to change the code the way you want. Each package compilation script is in lfs directory.

A simple package version upgrade

It should be enough to :

• change VER in the lfs/<package file="">
• then fetch the new source package and get the checksum

This is for 1.4:

./make.sh prefetch
md5sum /tmp/your-package-name

And this is for 2.0:

./make.sh prefetch
md5sum cache/tmp/your-package-name

• change the MD5 checksum of the new package in the lfs/<package file=""> script in the $(DL_FILE)_MD5= line
• repeating ./make.sh prefetch should move the loaded file in /tmp to the cache directory ready to be used for compilation
• ./make.sh build will compile your new package

Adding/removing a package

If you add a package, the building of this package needs to be added in make.sh, probably at the end of make.sh buildstage3 if it is a file used after installation. There are enough existing examples in the lfs directory to be a source of inspiration. For files you want to include in installed files (i.e. included in the ISO you are building), add the result of your package in log (check log/<package file=""> to the appropriate src/ROOTFILE.xxx In v2, each package had his own rootfile in config/rootfiles. If you remove one package, you could only suppress the corresponding rootfile.

Kernel setting changes

./make.sh shell allow to run make menuconfig inside the chroot once the distribution is compiled. just type :

./make.sh shell 
cd /usr/src/linux

For a kernel upgrade, simply use make oldconfig For kernel settings changes, it is more convenient to use make menuconfig

After the use of make menuconfig, make oldconfig will remove comments added by make menuconfig to ease diff checking.

In case of x86, you would have to report the change on the other .config (std or smp config). Then copy the changed .config file on config/kernel/kernel-config.xxx.

Live with your modifications

Preferably retrieve IPCop sources from cvs (1.4) or svn (2.0). This way, you can keep your changes uncommited on your cvs/svn tree and your modified sources could be updated with a simple cvs update -Pd (1.4) or svn update (2.0).

If your change conflicts in one place with official changes, you would have to repair that part only and not need to report each of your changes on every release.

Changing the way a package is compiled is the easy part of your programmer's life. Maintaining a change in the long term may be more challenging. You are always welcome to report your changes, so they could be included in a next release or version.

Prefered way to report those enhancement is to post a RFE on sourceforge with a diff -u or cvs diff -u (1.4) or svn diff (2.0) of your modifications. Another possibility is to send a message to the ipcop-devel mailing list.