Dbox2:Development:README.3rdparty.en (Oldmake) obsolete
This item, based upon Oldmake, is not longer provided from CVS-HEAD and also related branches like dreambox. There is no priority for maintenance from current active developers. So it's sure that many features of this buildsystem don't work with current HEAD, but you can use the tag
to get the last level of Oldmake as HEAD so you can continue work and maintain this branch.
oldmakeYou can tell necessary changes to developers to the developer-forum or commit your changes for Oldmake and related branches by yourself.
- dbox2 Entwicklung
- Create Images and Yadd's (english)
- Images und Yadd's erstellen (deutsch)
- CDK YADD Boot Procedure
- CDK YADD Bootvorgang
And this is how you add new tools to the cdk
First of all start thinking if whatever you intend to add really is a useful addition to the project. If you still think your idea is great you can start integrating it.
The audience of this document is neither developers wanting to add their own software nor people who deeply integrated some 3rd party software into their projects.
It is meant for people wanting to add someone's else's code in more or less its original form. Please be very careful to check that the code's license is suitable for the project.
Often you will need to make some small changes to the source code to make it build properly. In that case you must NOT create a new archive but simply take the original version, copy it, add your changes and create a diff between the two.
You do this with the command:
"diff -Naur packet.orig packet > packet.diff"
The created patch goes to "$HOME/tuxbox-cvs/cdk/Patches". Do not add any version information to the filename.
The next step is to make some additions to the following files:
$HOME/tuxbox-cvs/cdk/Makefile.am $HOME/tuxbox-cvs/cdk/configure.ac $HOME/tuxbox-cvs/cdk/rules-archive $HOME/tuxbox-cvs/cdk/rules-make $HOME/tuxbox-cvs/cdk/rules-install
Let's start with rules-archive
This file describes the packets' download source(s). Since most packets are hosted on public servers we simply download them when needed. Both the http and ftp protocol is supported. Format is one line per packet, first the name then URL(s), all separated by semicolons.
Next we deal with rules-make
This file describes the steps necessary to 'make' the packet.
Again we have one line per packet with several entries separated by semicolons. The entries are as follows:
Must be a unique name. It will be used again in the files rules-install, configure.ac and Makefile.am. It can be any name but it's best to use part of the packet name to avoid namespace clashes.
Versionnumber of the packet. Even though most packets have this as part of their archive name you might find one that doesn't so it's provided as an additional separate entry.
This is the name of the directory that results from unpacking the archive. Even though most archives will contain just one directory which will in turn contain all the necessary files and subdirectories there might be some exceptions. In this case choose a suitable name here and use "dirextract" as a rule (see below).
The name of the packet archive itself. If there are additional files necessary (diffs or additional archives) you add the names without path and separate them by colons.
You state rules that need to be applied to the packet and its files
extract - extracts a packet dirextract - creates a directory and extracts the packet inside it patch - applies a diff-file to patch the packet
Take a look at rules-make for additional rules.
example1 (just extract):
example2 (extract and apply patch):
If everything related to the installation will be taken care of by Makefile.am you can simply add just one line here containing the identifier.
Else you might want to add an entry like this:
You can state multiple commands which have to be separated by semicolons. The commands and their parameter(s) are separated by colons.
DESTDIR=TARGET is used to inform 'make' about the path of the cdkroot. But of course this is not valid for all packets, some might use different variable names or you will need to add parameters like --prefix while running their 'configure'-scripts.
Choose a suitable section here (take the existing entries as a guide) and either add TUXBOX_RULES_MAKE(...) or TUXBOX_RULES_MAKE_EXDIR(...). Replace the three dots by the unique identifier you chose in rules-make.
Creates variables from the information you gave in rules-install and rules-make. These variables can be used later inside Makefile.am. The following variables will be defined:
DEPENDS_packet - archive(s) and patch(es) necessary to build the packet PREPARE_packet - expands to commands for extracting and patching the packet DIR_packet - name of the directory to which the archive has been unpacked to INSTALL_packet - expands to commands for installing the packet CLEANUP_packet - expands to commands responsible for removing the sourcecode and build files no longer needed after building and installing the packet. Note that this does NOT remove the downloaded archive.
same as above but the difference being that you use it for packets that do not get built inside their sourcedirectory. Additionally the variable CONFIGURE_packet is defined which expands to a command executing the configure-script of the packet.
If you know your way around Makefile.am you should have no trouble. This file contains commands and variables that are used to create the final Makefile when 'configure' is run and serves as a kind of basis.
If you create rules for 'make' that belong to a packet then add a dot in front of the name. The last command used is "touch $@". This command will create a file with the name of the currently used rule which indicates that the rule was sucessfully executed.
Example for a rule:
.paket: .bootstrap @DEPENDS_packet@ @PREPARE_packet@ cd @DIR_packet@ && \ $(BUILDENV) \ ./configure \ --build=$(build) \ --host=$(target) \ --prefix= && \ $(MAKE) all && \ @INSTALL_packet@ @CLEANUP_packet@ touch $@
$(BUILDENV) is a macro that expands to widely used environmental variables like CC, CFLAGS etc. Then and now you might encounter a packet that needs additional or different variables. You can add these below $(BUILDENV) in a rule. Take a look at Makefile.am for examples.
Furthermore there are some rules in Makefile.am which group the single packet rules to useful group-rules (for exmaple "libs"). These rules might be further grouped until finally there is an "all"-rule.
Take a look at the group-rules and think where your newly added rule might fit best.
example: devel = .gdb .strace .packet
At the end of Makefile.am you will find a section that deals with cleaning up the environment in case you want to start from anew. You need to add your packet's rulename here to remove the file that has been created by 'touch' when the packet was built and which would prevent the packet from being rebuilt.
Grundlagen - Installation - Debug-Mode - Hardware - CDK/Development
LCars - Neutrino - Enigma - Plugins - Spiele - Software - Tools - Howto - FAQ - Images
Hauptseite - News - Alle Artikel - Bewertungen - Gewünschte Seiten - Index - Neue Artikel - Impressum - TeamHilfeportal - Seite bearbeiten - Bilder - Links - Tabellen - Textgestaltung