Kito wrote:
I would probably just use 'frameworks' as the name, the 'BP' prefix is
not generally used.
Can do.
<snip>
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.
Ignored. :D
<snip>
Hmmm, I wonder if we could make use of alternatives.eclass to handle the
symlinks for 'Current'
I'm not familiar with this eclass; I'll check it out.
<snip>
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.
This syntax came from the example in
http://dev.gentoo.org/~plasmaroo/devmanual/eclass-writing/. I agree it
may not be the best approach.
<snip>
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`.
I'll look at these. We may have conflicting ideas on how this eclass
would be used.
<snip>
My vision for the used of this eclass is as follows: the library gets a
USE flag, like "framework" or some such, which builds the library as a
framework. These functions are used to help the ebuild author create
the framework from the package files, as an ebuild author would use do*
with a package lacking a standard `make install`. It's not clear if the
activated USE flag would disable installation to a standard /usr/lib
style location or simply add the construction of a framework.
Let's further discussion! Exactly what does this eclass need to do?
-Nick
--
[email protected] mailing list
