* Re: [gentoo-dev] Cross Compilation and Dynamic Slots
@ 2004-08-11 14:21 99% ` Jason Stubbs
0 siblings, 0 replies; 1+ results
From: Jason Stubbs @ 2004-08-11 14:21 UTC (permalink / raw
To: gentoo-dev
On Tuesday 10 August 2004 23:55, Jason Stubbs wrote:
> No Grand Unified Theory of Everything yet, but ...
Almost there!
I'll summarise the list of requirements that I see and then go through how
they can solve various problems with regards to ${SUBJECT}.
PROFILES
packages.cc
Defines a set of atoms that must be on the host system to be able to
compile for this profile.
bashrc - available as of portage-2.0.51_pre17
ARCH, USERLAND, LIBC & KERNEL are defined as those required for the
package that is about to be compiled when sourced. Bashrc should define
aliases for the toolchain to define how to compile for the host
specified with a system of this profile.
ATOMS
cat/pkg&keyword
Defines that a package needs to be compiled as the specified keyword.
Portage expands the keyword to ARCH, USERLAND, LIBC & KERNEL and passes
those to the host profile's bashrc. If an atom does not specify a
keyword, it is taken to be that of the target root's profile.
cat/pkg{atom [atom]}
The braced atom specifies extra bounds for a matching cat/pkg's DSLOT.
EBUILDS
DSLOT="atom [atom ...]"
Portage scans installed and to be installed packages against the
specified atom(s) and builds the DSLOTted package once for each
individual package match, passing the matched package name to the
ebuild in the DSLOT variable.
pkg_select()
This function configures the system to use this package by default. If
it is successful or if there is no need to do so, it should return 0.
It should also export any information needed to revert the system back
to its original state. If it is not successful, it should do any
cleanup required immediately and return 1.
pkg_revert()
This function reverts the system to back to the state it was in before
running pkg_select() based on information exported by pkg_select().
INSTALLED DB
/var/db/pkg/keyword/cat/pkg-ver[--pkg-ver]
The keyword is taken or inferred from the cat/pkg&keyword specified for
the installed package. The [-pkg-ver] component represents the DSLOTted
version of the package.
Not too much I hope... Anyway, on to how I envision it working.
MOD_PHP
DEPEND would simply contain "net-www/apache" without respect to USE flags as
well as any other DEPENDs it might have. DSLOT would also contain
"net-www/apache". Apache doesn't need to do any special setup and so would
simply return a 0 for both pkg_select() and pkg_revert(). In the case that
both apache-1.3.31-r2 and apache-2.0.50 are installed, portage would elect to
install mod_php twice, passing in the different versions of apache each time.
Each installation would end up in a directories under /var/db/pkg labelled
mod_php-4.3.8--apache-1.3.31-r2 and mod_php-4.3.8--apache-2.0.50.
As for differing use flags, users could specify them in package.use using the
new atom syntax. For example, "dev-php/mod_php{=apache-2*} -mysql". Users
could also restrict the combination by way of package.mask. If they wanted
both apache-1 and apache-2 installed but only wanted mod_php for apache-2,
for example, a user could specify "dev-php/mod_php{=apache-1*}" in
package.mask and so on and so forth.
NVIDIA_KERNEL
The only required change would be DSLOT="virtual/linux-sources" as the ebuild
already detects what kernel version is at /usr/src/linux and compiles against
it. The kernels, on the other hand, would define pkg_select() to change the
linux symlink to its own sources and export what was previously linked. Then
in pkg_revert() it would restore the symlink to its original state.
OTHERS
The only other that I know of, ocaml, could use the pkg_select() function to
run ocaml-config to set the compiler to the version required. Any package
that needs to be slotted based on the version of another package should be
able to be done so in pretty much the same way.
GCC
To build a cross compiler, the atom would be "sys-devel/gcc&keyword". Gcc
would then receive the keyword in the form of ARCH, USERLAND, LIBC & KERNEL
but would still be able to tell the host architecture by way of the keyword
'USE flag'. Portage would then slot the compiler into /var/db/pkg/keyword/.
Gcc would also define pkg_select() and pkg_revert() to do the same as ocaml.
CROSS COMPILATION
A "chroot" would be created and the profile set. Any other files (such as
make.conf, et al) would also be created before any emerging starts. The
profile then dictates what tools are required from the host by way of
packages.cc. In a sparc profile, for example, would be "sys-devel/gcc&sparc".
Portage would then emerge gcc into the host system as specified above.
When packages are to be merged into the "chroot", portage will look at the
packages.cc and run pkg_select() on each tool required before doing the
compilation and merging and then run pkg_revert() after each.
MULTILIB
I'll use amd64 as the example. In the profile, bashrc would set aliases
defining how to run gcc to create 32bit binaries when ARCH="x86". The
profile's ACCEPT_KEYWORDS would be "amd64 x86". When keyword matching is
done, they are search in order of ACCEPT_KEYWORDS and the first match is used
when sourcing bashrc and when recording the installation into the installed
package database.
Any packages that the to be installed package depends on will then be
installed using the accepted keyword.
I'm sure there are a few issues remaining here. I think that most of them will
be much easier to deal with, though. Feedback is greatly welcome.
Regards,
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2004-07-31 4:09 [gentoo-dev] Dynamic SLOTs Jason Stubbs
2004-08-10 14:55 ` Jason Stubbs
2004-08-11 14:21 99% ` [gentoo-dev] Cross Compilation and Dynamic Slots Jason Stubbs
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox