Comments (7)
We actually don't really expect people to ship all of GTM as a framework, but
instead to build it directly into their
application. The BuildingAndUsing doc has a comment about this, as time goes
and we keep adding more to
GTM, we figure it make more sense to use the framework simple as a initial aide
to quickly try out some parts of
GTM, but for shipping an application, it probably makes more sense to directly
compile the individual sources
you need so you don't have to carry a lot of code you don't need.
Original comment by [email protected]
on 25 Feb 2009 at 2:32
- Added labels: Priority-Low, Type-Enhancement
- Removed labels: Priority-Medium, Type-Defect
from google-toolbox-for-mac.
I agree that a shipping product doesn't need to bundle GTM.framework (and I
appreciate the effort you've put in
to make the modules independent to allow this), but it's currently not possible
to *explore* using
GTM.framework within a non-application target (such as a plugin or framework)
without modifying the
GTM.framework target or modifying the application bundle of the app that links
such a framework or loads such
a bundle. In addition, for projects that want to track the SVN for GTM, it
would be easier to use GTM.framework
all the way through development and switch to direct inclusion of modules only
at the ramp up to a release
candidate--that way they benefit from build improvements, project additions,
dependency changes, etc. without
having to merge those changes manually.
Original comment by [email protected]
on 25 Feb 2009 at 10:48
from google-toolbox-for-mac.
There also no reason that changing from @executable_path/../Frameworks to
@rpath for the installation path
would eliminate the use case you lay out in comment 1 and in the
BuildingAndUsing doc. Rather it would add a
little flexibility to the "aide" stage and would *allow* though not require
bundling the entire framework.
Original comment by [email protected]
on 25 Feb 2009 at 10:50
from google-toolbox-for-mac.
just making sure I follow things right, you're talking about a case where:
- you build a framework that links against the gtm framework.
- your framework then goes into another app? ie-a plugin, to another app or a
supporting library?
If that's the case, the app might be something that exists, so you can't really
control it's rpath? Seems like the
safest might be to just switch to @loader_path? That way it's always relative
to whatever is using GTM. There
are still some use cases that could fail, but I'm not sure there's any solution
that's "right" for all possible
cases?
Also, @rpath is only valid for 10.5+, so the 10.4 configs would have to stay w/
the current value or switch to
@loader_path.
Original comment by [email protected]
on 27 Feb 2009 at 4:45
from google-toolbox-for-mac.
Yes, you understand correctly, but I don't think @loader_path will work for
plugins and frameworks.
Just to be totally explicit, there are two use cases:
1. I'm building Foo.plugin (a loadable bundle) and want to link Foo.plugin
against GTM.framework *and*
bundle GTM.framework in Foo.plugin since I do not control the application that
will load Foo.plugin. In this
case, the final plugin bundle will look like
Foo.plugin/
Contents/
Frameworks/
GTM.framework
...
MacOS/
Foo
...
Having GTM.framework built with an installation path of
@loader_path/../Frameworks would support this use
case.
2. I'm building Bar.framework and want to link Bar.framework against
GTM.framework *and* bundle
GTM.framework with Bar.framework. One instance this came up for me was that I
wanted to replace internal
implementations in one of our frameworks with implementations from GTM. Since
our framework is used in
several apps (internally and by 3rd party developers), I wanted to isolate the
GTM dependency so that all of
the build settings of applications that link Bar.framework do not have to all
be modified. In this case, the final
Bar.framework package looks like this:
Bar.framework/
Frameworks/
GTM.framework
Bar
...
In this case, having GTM.framework installed at @loader_path/../Frameworks does
not work (it would need to
be @loader_path/Frameworks).
The difference between framework and plugin/app bundles is a fail on Apple's
part (rdar://). There is no way,
using @loader_path (or @executable_path) to support both use cases (1) and (2).
The solution is to set the
installation path of GTM.framework to @rpath. Then adding
@loader_path/../Frameworks to Foo.bundle's LD_RUNPATH_SEARCH_PATHS build
setting and @loader_path/Frameworks to Bar.framework's LD_RUNPATH_SEARCH_PATHS
build setting allows both use cases to succeed.
Because @rpath is only 10.5+, I propose changing 10.4 configs to
@loader_path/../Frameworks, as this would
support use case (1) which is currently unsuported and changing the 10.5+
configs to @rpath as this would
support both use cases (and many others).
Original comment by [email protected]
on 27 Feb 2009 at 5:10
from google-toolbox-for-mac.
Other solution is to build with -headerpad_max_install_names (which we should
be doing anyways) and let the
users set the path how they like with install_name_tool.
Original comment by dmaclach
on 27 Feb 2009 at 5:29
from google-toolbox-for-mac.
landed in revision 86
Original comment by [email protected]
on 27 Feb 2009 at 7:45
- Changed state: Fixed
from google-toolbox-for-mac.
Related Issues (20)
- ARC Support HOT 1
- Documented install location is incorrect (and potentially confusing) HOT 1
- Leak detection not working on Lion
- Does not compile with Apple LLVM 4.0 in Xcode 4.5 HOT 6
- Picasa photos appear so small on iPhone HOT 2
- Redirect to cached version of my website when searching in google HOT 1
- Cannot find the folder "~/Library/Application Support/Developer/Shared/Xcode/Plug-ins" HOT 2
- Compatability with XCode 4.3.1 HOT 1
- GTMWindowSheetController doesn't support top level parent view HOT 1
- Update for Xcode 4.5 toolchain
- GTMFileSystemKQueue information and recursion HOT 1
- GTMStackTrace addresses do not have 0x prefix
- Unit test crash if access to address book is not granted
- Broken download resuming support HOT 1
- Xcode 5 compatiibility? HOT 1
- google-toolbox-for-mac causes warning when compiled for arm64 (iOS 64-bit) HOT 2
- Patch for /trunk/UnitTesting/GTMSenTestCase.h HOT 3
- NET::ERR_CERT_AUTHORITY_INVALID HOT 1
- Unit tests don't pass on OSX 10.9
- GTMCopyLaunchdExports doesn't work on OSX 10.10 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from google-toolbox-for-mac.