Mailing List Archive

On Feb 1, 2006, at 4:06 PM, Dirk Schönberger wrote:

> Hi,
>
> 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.....

Probably just be done as an eclass with the appropriate function
being called with a USE flag conditional in pkg_postinst(). Aside
from shuffling the files in ${D} around to match the framework
directory structure, you would also scan all shared libs with otool
(1) to check that install_names are set correctly, and set them with
install_name_tool(1) if they are not.

Of course this would only be needed for packages that don't support
frameworks natively... for instance Python and SDL both have upstream
framework build targets already.

>
>
> Or am I in the wrong project alltogether? ;)
>

I dunno, lets see your patches for this feature and we'll go from
there ;)


--Kito

kito@gentoo.org




--
gentoo-osx@gentoo.org mailing list

> >
> >
> > Or am I in the wrong project alltogether? ;)
> >

> I dunno, lets see your patches for this feature and we'll go from
> there ;)

I don't think I have the knowledge to do this on my own.
OTOH I have currently the need for this, at least for the SDL family of libs
(SDL, SDL_image, SDL_ttf, SDL_mixer)
so with a little help I would like to see if I can patch together something
proof of concept like.

Something like a "Creating and using MacOS frameworks in 21 days" type guide
would be nice, though ;)

Regards
Dirk



--
gentoo-osx@gentoo.org mailing list

On Feb 1, 2006, at 5:03 PM, Dirk Schönberger wrote:

>>>
>>>
>>> Or am I in the wrong project alltogether? ;)
>>>
>
>> I dunno, lets see your patches for this feature and we'll go from
>> there ;)
>
> I don't think I have the knowledge to do this on my own.
> OTOH I have currently the need for this, at least for the SDL
> family of libs
> (SDL, SDL_image, SDL_ttf, SDL_mixer)
> so with a little help I would like to see if I can patch together
> something
> proof of concept like.
>
> Something like a "Creating and using MacOS frameworks in 21 days"
> type guide
> would be nice, though ;)

Straight from the horses mouth:

http://developer.apple.com/documentation/MacOSX/Conceptual/
BPFrameworks/index.html


--Kito





--
gentoo-osx@gentoo.org mailing list

>> Something like a "Creating and using MacOS frameworks in 21 days"
>> type guide
>> would be nice, though ;)
>
> Straight from the horses mouth:
>
> http://developer.apple.com/documentation/MacOSX/Conceptual/
> BPFrameworks/index.html
>

Thanks for the link. However, it seems to be rather Apple specific and not
really suited specific for the things I want to do.
So perhaps I have to start from the basics and woork from there on.

I have an open source application (a game which depend on SDL, not in
Gentoo, yet).
I have a working libSDL, libSDL_ttf, libSDL_image aso from Gentoo-OSX,
installed into /usr prefix (/usr/lib, /usr/include)
The game compiles and runs fine if started from the console.
As a good Apple developer and user ;) I would like to create an
application folder
in order to be able to start the application from inside the finder,
without having to resort to the CLI.
I have managed a basic app folder, mostly by manually copying the
necessary files into the needed places. The game runs from the finder.

Next step would be to create a standalone application, suitable for
distribution.
This means including the used libs into the app folder structure.
If I check the actual executable with otool -L, I see that the exe is
still linked against /usr/lib/libSDL-X.Y.Z.dylib (including other libs and
system frameworks)

From what I see, basically I have two choices.

a) copy the needed libs to a app folder local sub folder and do some hacks
with DYLD_LIBRARY_PATH. The actual starting program of my application is a
Unix shell script, so this could be even possible
b) learn to build frameworks from inside Gentoo, so that I can link
against the framework. I have the idea that I can distribute the framework
as part of my app folder and it is fetched automatically.

From what I have seen in the link you gave, framework creation is done in
XCode / ProjectBuilder only. I did not found any example about how to do
this in a portage like environment (I found a DarwinPorts script for
creating a libSDL framework, but this uses .pbx scripts, too)

After a framework is created (which I think is the problematic part), I
assume that using the framework just is replacing a

gcc CFLAGS main.c -o main.o
gcc LFLAGS main main.o

with

CFLAGS=-I/usr/include
LDFLAGS=-L/usr/lib -lSDL

by a

CFLAGS=-framework SDL
LDFLAGS=-framework SDL

and for deployment just copy the files from the framework (or a subset
from them?) into my app folder?

Regards
Dirk


--
gentoo-osx@gentoo.org mailing list

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?
--
gentoo-osx@gentoo.org mailing list

On 07-02-2006 10:24:40 -0500, 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?

I for sure won't be.

--
Fabian Groffen
Gentoo for Mac OS X Project
--
gentoo-osx@gentoo.org mailing list

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. This
is my first eclass, so please (kindly) point out my ignorance in the
matter. It is still very untested; help me get this thing going before
I submit it to gentoo-dev.

The code is in my darcs-managed overlay:
http://code.sbbod.net/portage-overlay/eclass/BPFramework.eclass
--
gentoo-osx@gentoo.org mailing list

>
> OK. This is my first stab at an ebuild for creating frameworks. This
> is my first eclass, so please (kindly) point out my ignorance in the
> matter. It is still very untested; help me get this thing going before
> I submit it to gentoo-dev.
>
> The code is in my darcs-managed overlay:
> http://code.sbbod.net/portage-overlay/eclass/BPFramework.eclass
> --

I just shortly looked at it and I don't know all intricacies, but I see
the use of {PV}.
I real frameworks, a new version of the headers or libraries is assumed to
be installed if "major changes", i.e. source incompatible API changes,
occur. IIRC, {PV} changes with each new minor version or -r version? So
this may possibly create too many versions. Does there exist a variable
which changes less often, or should there be introduced such a variable?

Regards
Dirk
--
gentoo-osx@gentoo.org mailing list

Dirk Schönberger wrote:
> I just shortly looked at it and I don't know all intricacies, but I see
> the use of {PV}.
> I real frameworks, a new version of the headers or libraries is assumed to
> be installed if "major changes", i.e. source incompatible API changes,
> occur. IIRC, {PV} changes with each new minor version or -r version? So
> this may possibly create too many versions. Does there exist a variable
> which changes less often, or should there be introduced such a variable?

I'd read this about major version changes... AFAIK there is no way to
test for external API changes via a variable name. The best we can do
is read the upstream changelog. The other thing to note is that unless
the library is slotted, portage will uninstall the old version of the
library (default behavior, iirc) leaving only the most recent version in
the framework.

I'm open to suggestions.

Also, are there any libraries in particular with which you'd like to see
this working? What packages should I be using to test this?

-Nick
--
gentoo-osx@gentoo.org mailing list

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





--
gentoo-osx@gentoo.org mailing list

On Feb 15, 2006, at 2:30 AM, Dirk Schönberger wrote:

>>
> I just shortly looked at it and I don't know all intricacies, but I
> see
> the use of {PV}.
> I real frameworks, a new version of the headers or libraries is
> assumed to
> be installed if "major changes", i.e. source incompatible API changes,
> occur. IIRC, {PV} changes with each new minor version or -r
> version? So
> this may possibly create too many versions. Does there exist a
> variable
> which changes less often, or should there be introduced such a
> variable?

SLOT could possibly be abused here.


--Kito





--
gentoo-osx@gentoo.org mailing list

On Feb 16, 2006, at 11:19 AM, Kito wrote:

>
> On Feb 14, 2006, at 9:53 PM, Nick Dimiduk wrote:
>
>>
>> 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.
>

Err, I suppose I should read before typing :/ insinto obviously
handles ${D} transparently. I motion that this statement be struck
from the record.

--Kito
--
gentoo-osx@gentoo.org mailing list

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
--
gentoo-osx@gentoo.org mailing list