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:
# This is for 1.4: cvs update -Pd # This is for 2.0: svn update
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.