| Age | Commit message (Collapse) | Author | Files |
|---|
|
of moving files (from poky). The copyfile function will be moved to bitbake in due course.
|
|
New file: packages/mono/mono-mcs-intermediate_1.2.5.1.bb
Compiles mono in native mode with standard prefix, then tars up the
resulting tree and puts the tarfile into staging
New file: packages/mono/mono_files.py
Automatically generated using collect-path.py (attached to this mail)
and contains a list that maps file patterns to package names (and
contained assemblies, see below).
New file: classes/mono.bbclass
Has a helper function for the list that maps file patterns to package
names and assemblies (see below). Also has a function mono_do_clilibs
and inserts that function into PACKAGEFUNCS. This function calls
mono_find_provides_and_requires which finds out (through calls to
monodis --assembly and monodis --assemblyref) which assemblies are
provided and required by a particular package. mono_do_clilibs then
puts the information about provided assemblies into
${STAGING_DIR}/clilibs/${packagename}.list and information about the
required packages into ${PKGDEST}/{packagename}.clilibdeps where it
will later be picked up by the modified read_shlibdeps.
Originally I had dependency resolution through the partial list in
mono_files.py but obviously this doens't scale, so I implemented the
new method with mono_do_clilibs. The benefit is now that I don't really
need the extra information in mono_files.py anymore and can in
principle get rid of mono_get_file_table and related code. Instead it
should be possible to modify collect-paths.py to output bitbake .inc
code (e.g. PACKAGES = "..." and a whole lot of FILES_... = "...")
instead of python code. There's still the minor problem of how to
handle the .mdb files, that's why I didn't implement it yet but instead
opted for an approach that I knew would work. (Debian just puts
the .mdb files into the individual packages, while I would argue that
they do belong into corresponding -dbg packages.)
Modified file: classes/package.bbclass
In read_shlibdeps I folded the two identical code blocks dealing with
*.shlibdeps and *.pcdeps into one and added *.clilibdeps (generated by
mono_do_clilibs above).
Modified file: packages/mono/mono_1.2.5.1.bb
Add the mono-mcs-intermediate workaround. Add a whole lot of python
code in populate_packages_prepend in order to split up the packages
based on information from mono_files.py (via mono.bbclass'
mono_get_file_table). As I said above a lot of this code can hopefully
be replaced in the future.
|
|
up/optimise PACKAGES checks a bit
|
|
some unneeded complexity (from poky)
|
|
|
|
|
|
|
|
when multiple -dev or -dbg packages are generated and when a single one is generated (from poky)
|
|
|
|
certain dependency chainhandling in both ipkg and dpkg (from poky)
|
|
generate (PACKAGES != ) removing needless dependencies (from poky)
|
|
correct operation with bitbake 1.8.x. Old behaviour is maintained in a special legacy anonymous function in base.bbclass. The patch is an improved version of the one discussed on the mailing list.
|
|
|
|
- if package contain libraries which are not used outside then add PRIVATE_LIBS
variable with names of them to not generate shlibs for them.
|
|
"inherit package_ipk package_tar" and seems to interfere with do_split_packages
|
|
|
|
|
|
causing python
traceback spew during population
|
|
migration
|
|
|
|
I do not know does this is best way of fixing it but it is better to have it in
repository then having rootfs images without libc.
|
|
${HOST_PREFIX}objdump
package.bbclass : make use of the OBJDUMP variable rather than
calling ${BUILD_PREFIX}objdump inside do_shlibs. As the original
usage was faulty and ended up calling host objdump which works
for some arm targets but not all.
|
|
RRECOMMENDS, from Poky
* poky rev 823: 'package.bbclass: depchains: don't -destructively- set the pkg's RRECOMMENDS.'
* poky rev 824: 'base.bbclass: depchains: don't -destructively- set the pkg's RRECOMMENDS.'
|
|
packages. The way it selects the principle package name needs totally reworking as the current code is flawed but apply a workaround for now (this is unrelated to other changes to package.bbclass)
|
|
packages. The way it selects the principle package name needs totally reworking as the current code is flawed but apply a workaround for now (this is unrelated to other changes to package.bbclass)
|
|
then package_write which actually generates the packages. The two stage approach allows us to avoid circular dependency issues from classes like debian.bbclass. As the data being emitted into pkgdata/ changed, you need to either wipe tmp or rerun the do_package tasks (wipe the do_package stamps). Everything will repackage anyway due to the new task.
|
|
functional changes (from poky)
|
|
barfing
package.bbclass: likewise
|
|
* people should really watch out with introducing regressions
|
|
people are reporting
~lart kergoth for introducing this regression
|
|
* Add package "depchains". This facilitates, for example, ensuring that if
A depends upon B, then A-dev will RRECOMMENDS B-dev, and the same for the
-dbg packages.
|
|
other packages.
|
|
|
|
* Avoid premature use of the PKG_* variables. We don't need to make use of
the debian.bbclass (or otherwise) renamed package names until the very end
of the packaging. This was necessary in order to enhance my
depchain/correspondantdeps stuff, and doesn't seem to harm anything.
|
|
* Fix bug which caused non-detection.
* Make visible error message for such condition.
* But still recover and continue for now, while we don't
have all occurances fixed in metadata. Note that while
content of the package will be ok, metadata can be wrong.
So, recover behavior should not be relied upon, this going to
be fatal condition later.
Oked-by: RP, hrw
|
|
* Factor out "strippedness" substring as FILE_UNSTRIPPED_MATCH.
* Allow FILE_UNSTRIPPED_MATCH to be overriden, useful to support
other executable formats.
* Also, don't complain if .debug directory already exist
(can heppen if manually run BB tasks, e.g. for debugging).
|
|
Make legitimize_package_name also convert <U0123> style encoding of
unicode codepoints into their utf-8 representation, as in glibc locale
files.
|
|
|
|
package if we want
|
|
multithreading version of bitbake. Also, set BB_DEFAULT_TASK to specify the default task (build) rather than hardcode into bitbake.
|
|
|
|
Set PACKAGEFUNCS only once. Now if more than one bbclass inherits
package both additional functions will be executed. The new packagefuncs
will be appended to the list and the old ones will not be lost
|
|
that are stripped from binaries and the symbols are linked to the original binaries via the gnu-debuglink section.If the -dbg packages are installed, oprofile and gdb will use them for symbol lookup.
|
|
|
|
|
|
|
|
using qemu. based on a patch originally written by Phil Blundell. fixes hh.org Bug #1385 (localedef OOM issue).
- running localedef (in qemu...) for every locale takes a while. set
BINARY_LOCALE_ARCHES = "" to avoid the new behaviour.
|
|
package.bbclass now tracks any package renaming performed using PKG_*.
When a package is built, the runtime variables are translated using
this cached information which is stored in staging.
From now on, only use package names are valid in runtime variables like
RDEPENDS, RRECOMMENDS and RSUGGESTS. eg. fontconfig-dev is correct,
libfontconfig-dev would be wrong.
As debian.bbclass can't determine package renaming until after a
package's contents is known, the class has to set BUILD_ALL_DEPS = "1".
This also means OE is no longer forced into one package renaming scheme.
|
|
|
|
|
