Commit graph

7 commits

Author SHA1 Message Date
Michael Stahl
5032dc0fc3 gbuild: invert handling of standard system libraries:
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.

Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
2012-09-28 16:49:08 +02:00
Michael Stahl
b85c349783 gbuild: replace direct gb_STDLIBS use with ...
... new gb_LinkTarget_add_standard_system_libs

Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
2012-09-28 16:49:06 +02:00
Michael Stahl
2e677c3981 gbuild: split uwinapi out of gb_STDLIBS
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
2012-09-28 16:49:05 +02:00
Stephan Bergmann
9ac86f484b Improvement on previous commit, UCB clean up
* As UCB is only ever initialized with "Local"/"Office", remove this
  configuration vector completely.  The "create" ctor creates an instance
  internally initialized with those "Local"/"Office" keys.  Special (test) code
  can still instantiate an uninitialized one via plain createInstance.  And for
  backwards compatilibity process startup still ensures to create an initialized
  instance early, in case there is still code out there (in extensions) that
  later calls plain createInstance and expects to get the already-initialized
  (single) instance.

* XInitialization is an "implementation detail" of the UniversalContentBroker
  service, do not expose in XUniversalContentBroker.

* ucbhelper/configurationkeys.hxx is no longer needed and is removed.

* ucbhelper/contentbroker.hxx is an empty wrapper and is removed; however, that
  requires ucbhelper::Content constructors to take explicit XComponentContext
  arguments now.

* The only remaining code in ucbhelper/source/client/contentbroker.cxx is
  Android-only InitUCBHelper.  Is that relevant still?

Change-Id: I3f7bddd0456bffbcd13590c66d9011915c760f28
2012-09-14 18:24:49 +02:00
Michael Meeks
fdda178d88 targetted improvement of UNO API includes / usage 2012-07-02 14:43:34 +01:00
Michael Stahl
c923f7d2c2 gbuild: "use" vs. "add":
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
  (i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
  (i.e. it is registered at the Module, has it's own makefile, may be
  in a different module than the target)
2012-04-08 01:05:52 +02:00
Matúš Kukan
cbd2e67d20 ucb: convert to gbuild 2012-01-15 16:11:32 +01:00