PB project types

  • I have another request for a pointer to some documentation.  Where can I
    find a description of all the project types that I'm asked to choose among
    when I create a new PB project?

    The context for this is that I need to create an application that has 3
    types of executable elements: the application, shared objects that are
    linked to the application when it starts, and shared objects that are
    explicitly opened and mapped as the application runs (extensions,
    plug-ins...).

    On Solaris, I created types 2 & 3 as .so files using "gcc -shared ..." and
    fPIC compilation.  Then I either linked directly with the .so (type 2) or I
    used dlopen() to handle the extension-type .so files.  As far as I can tell,
    dlopen() doesn't exist and linking a shared library using -l<filname> gives
    errors, so I need to find an equivalent strategy for Mac OS X.
  • On Thursday, October 12, 2000, at 11:45 PM, Phillip Mills wrote:

    > I have another request for a pointer to some documentation.  Where can I
    > find a description of all the project types that I'm asked to choose among
    > when I create a new PB project?
    >
    > The context for this is that I need to create an application that has 3
    > types of executable elements: the application, shared objects that are
    > linked to the application when it starts, and shared objects that are
    > explicitly opened and mapped as the application runs (extensions,
    > plug-ins...).
    >
    > On Solaris, I created types 2 & 3 as .so files using "gcc -shared ..." and
    > fPIC compilation.  Then I either linked directly with the .so (type 2) or I
    > used dlopen() to handle the extension-type .so files.  As far as I can tell,
    > dlopen() doesn't exist and linking a shared library using -l<filname> gives
    > errors, so I need to find an equivalent strategy for Mac OS X.

    On MacOS X, it's best to create an application with frameworks.
    Create a new target "Cocoa Application", add the frameworks as targets. Then select the application target, select the last build phase, choose Project -> New Build Phase -> New Copy Files Build Phase
    where: Frameworks
    then drag&drop the frameworks from the product group to the "Files" section

    andy
  • So far I've avoided Cocoa as probably irrelevant since this is a C++,
    cross-platform, non-GUI application.  Is that a bad theory?

    If the application is not using Cocoa, how does that affect the way to build
    dynamically-loadable libraries?

    (Once again, although I appreciate the answers to specific questions, I'd be
    just as happy with documentation references so that I can investigate
    additional details.)

    -----Original Message-----
    From: Andreas Monitzer [mailto:<a...>]
    Sent: Thursday, October 12, 2000 5:51 PM
    To: <macosx-dev...>
    Subject: Re: PB project types

    On Thursday, October 12, 2000, at 11:45 PM, Phillip Mills wrote:

    > I have another request for a pointer to some documentation.  Where can I
    > find a description of all the project types that I'm asked to choose among

    > when I create a new PB project?
    >
    > The context for this is that I need to create an application that has 3
    > types of executable elements: the application, shared objects that are
    > linked to the application when it starts, and shared objects that are
    > explicitly opened and mapped as the application runs (extensions,
    > plug-ins...).
    >
    > On Solaris, I created types 2 & 3 as .so files using "gcc -shared ..." and

    > fPIC compilation.  Then I either linked directly with the .so (type 2) or
    I
    > used dlopen() to handle the extension-type .so files.  As far as I can
    tell,
    > dlopen() doesn't exist and linking a shared library using -l<filname>
    gives
    > errors, so I need to find an equivalent strategy for Mac OS X.

    On MacOS X, it's best to create an application with frameworks.
    Create a new target "Cocoa Application", add the frameworks as targets. Then
    select the application target, select the last build phase, choose Project
    -> New Build Phase -> New Copy Files Build Phase
    where: Frameworks
    then drag&drop the frameworks from the product group to the "Files" section

    andy
    _______________________________________________
    MacOSX-dev mailing list
    <MacOSX-dev...>
    http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • > So far I've avoided Cocoa as probably irrelevant since this is a C++,
    > cross-platform, non-GUI application.  Is that a bad theory?
    >
    > If the application is not using Cocoa, how does that affect the way to build
    > dynamically-loadable libraries?
    >
    > (Once again, although I appreciate the answers to specific questions, I'd be
    > just as happy with documentation references so that I can investigate
    > additional details.)

    You can use CoreFoundation's CFBundle for loading (C-Interface).
    Check your local /Developer/Documentation directory.

    andy
  • > So far I've avoided Cocoa as probably irrelevant since this is a C++,
    > cross-platform, non-GUI application.  Is that a bad theory?

    You can use Cocoa for your native platform code while keeping all the rest
    of your cross-platform code untainted.  We've done this for a number of
    ports of large cross-platform applications (e.g. FrameMaker, Flash,
    Quake), some of which were written in C++.

    C++ does currently make this a little more difficult, though, since
    Objective C++ is no longer available.  Without Objective C++, Objective C
    objects and C++ objects can no longer talk directly to each other, which
    means that one ends up having to write some bridge code between those
    objects using straight C.  If you have a small enough interface between
    your cross-platform C++ objects and your native objects this probably
    isn't a big deal, but if you have a lot of API that may be a compelling
    reason to avoid Objective C (and thus Cocoa) for now.  (Though keep in
    mind that writing in Cocoa might save you more lines of more complex
    platform code than you'd end up writing for that bridge code, depending on
    what you're doing.  And it occurs to me that one might be able to
    automate the process of writing bridge code...)

        Ken
previous month october 2000 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today