On Feb 14, 2006, at 9:53 PM, Nick Dimiduk wrote:
Nick Dimiduk wrote:
Kito wrote:
On Feb 1, 2006, at 4:06 PM, Dirk Schönberger wrote:
would it be possible / feasible, that Gentoo creates and uses
Frameworks for
its libraries?
Its possible, feasible and highly desired! Has been on my TODO
list for over a year now.....
Will anyone be upset if I take a stab at this (frameworks feature)
this week?
OK. This is my first stab at an ebuild for creating frameworks.
Cool, thanks for hacking on this =)
ECLASS="BPFramework"
INHERITED="$INHERITED $ECLASS"
I would probably just use 'frameworks' as the name, the 'BP' prefix
is not generally used.
local fw = "${PN}.framework"
# install_framework: install a framework into the appropriate
directory.
# usage: install_framework file [<new file>]
# ie. install_framework "${PN}.framework"
install_framework() {
[[ -z "${1}" ]] && die "usage: install_framework <file> [<new file>]"
if useq ppc-macos ; then
insinto /Library/Frameworks
newins "$1" "${2:-${1}}" || die "Failed to install ${1}"
fi
}
This wouldn't work as it isn't respecting ${D}. You want to have the
package install itself to ${D} and let portage handle touching the
live fs.
# create_framework: create the basic framework structure
# usage: create_framework
create_framework() {
if useq ppc-macos ; then
dodir "${fw}/Versions/${PV}/{Headers,${PN},Resources}"
dosym "${fw}/Versions/${PV}/Headers" "${fw}/Headers"
# dosym "${fw}/Versions/${PV}/${PN}" "${fw}/${PN}"
dosym "${fw}/Versions/${PV}/Resources" "${fw}/Resources"
dosym "${fw}/Versions/${PV}" "${fw}/Versions/Current"
fi
}
Hmmm, I wonder if we could make use of alternatives.eclass to handle
the symlinks for 'Current'
# insert_binary: insert a compiled file into the framework
# usage: insert_binary <file> [...]
insert_binary() {
[[ -z "${1}" ]] && die "usage: insert_binary <file> [...]"
if useq ppc-macos ; then
into "${fw}/Versions/${PV}"
insopts "-m0755"
while [ -n ${1} ] ; do
doins ${1}
dosym "${fw}/Versions/${PV}/${1}" "${fw}/${1}"
shift
done
fi
}
Probably shouldn't use `useq` or `ppc-macos` anymore. In fact, I'm
not even sure these need a conditional...but if they do, we should
probably `use userland_Darwin` instead.
# insert_header: insert a header file into the framework
# usage: insert_header <file.h> [...]
insert_header() {
[[ -z "${1}" ]] && die "usage: insert_header <file.h> [...]"
if useq ppc-macos ; then
into "${fw}/Versions/${PV}/Headers"
while [ -n ${1} ] ; do
doins ${1}
shift
done
fi
}
# insert_resource: insert a resource into the framework
# usage: insert_resource <file> [...]
insert_resource() {
[[ -z "${1}" ]] && die "usage: insert_resource [...]"
if useq ppc-macos ; then
into "${fw}/Versions/${PV}/Resources"
while [ -n ${1} ] ; do
doins ${1}
shift
done
fi
}
The insert functions are useful, but I was also picturing a custom
src_install that automagically shuffled the files around in ${D} to
match the framework structure. For instance, check out some of your
existing frameworks of opensource projects like python, perl, and
SDL. You'll see they have somewhat of a standard unix-y layout ('./usr
{bin,lib,shared}') usually with symlinks like `Documentation-
>Versions/Current/usr/share/doc Headers->Versions/Current/usr/include`.
The harder problem is how to handle shared objects. Usually a
framework builds its shared lib as MyFramework.framework/Versions/
Current/MyFramework and symlinks it to MyFramework.framework/
MyFramework. So in a typical single dylib package, you would mv/
rename the actual dylib file, then set its install_name using
install_name_tool(1) to match the new location/destination and fix
any paths to linked libs as needed.
An even harder problem than that, is allowing packages to depend on
portage-built frameworks. Could perhaps abuse built_with_use
something like:
if built_with_use sys-libs/foo framework; then
append-flags "-FFoo"
fi
Not the best solution, but something that needs to be solved
eventually...
Again, thanks for working on this, good job!
--Kito
--
[email protected] mailing list
