Dbox2:Development:README.3rdparty.en (Oldmake) obsolete

Aus TuxBoxWIKI
Wechseln zu: Navigation, Suche


HINWEIS:

Diese Kategorie bzw. dieser Artikel basiert auf auf dem alten Buildsystem "Oldmake", welches ab Januar 2009 durch das jetzt im CVS-Head befindliche "Newmake" abgelöst wurde. Es ist relativ sicher, dass viele Funktionen nicht mehr aktiv unterstützt werden oder nicht mehr funktionieren. Es besteht aber die Möglichkeit "Oldmake" weiterhin zu warten. Der letzte funktionsfähige Stand wurde im CVS mit dem Tag 

last_oldmake_head

markiert und ein entsprechender Branch 

oldmake

angelegt, so dass das Verfahren, wenn auch eingeschränkt, weiter verwendet werden kann. Von den meissten aktiven Entwicklern wird dieser Branch jedoch nicht mehr weiter gepflegt, so dass es am Nutzer selbst liegt, notwendige Änderungen im Entwicklerforum mitzuteilen oder sofern die Möglichkeit besteht, selbst entsprechende Änderungen ins CVS zu schreiben.

Flagge de.jpg Deutsch: Development:README.3rdparty.de


General

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. 

packetname;URL1[;URL2...;URLN]

example: 

paket-1.0.tar.gz;khttp://www.packethome.com/download


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: 

identifier;version;directory;archive[:patch1...:patchN];rule1[;rule2...;ruleN]

identifier

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.

version

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.

directory

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).

archive

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.

rules

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): 

packet;1.0;packet-1.0;packet-1.0.tar.gz;extract:packet-1.0.tar.gz

example2 (extract and apply patch): 

packet;1.0;packet-1.0;packet-1.0.tar.gz:packet.diff;extract:packet-1.0.tar.gz;patch:packet.diff


rules-install

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: 

packet;make:install:DESTDIR=TARGET

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.


configure.ac

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.

TUXBOX_RULES_MAKE(packet)

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.

TUXBOX_RULES_MAKE_EXDIR(packet)

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.


Makefile.am

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.

see also


Abgerufen von „https://wiki.tuxbox-neutrino.org/w/index.php?title=Dbox2:Development:README.3rdparty.en_(Oldmake)_obsolete&oldid=11790“