| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This is not supported. People must use the content of the installation
directory instead.
This reduces complexity of qbs' own project files.
Change-Id: I39f8bb4d5252b0631a64b3aac01f83b09b28ae0f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
| |
So that we can easily test this functionality in the absence of a
statically built Qt.
Change-Id: I9c8f296222bc3155cb95219d4ababfd34e1e7e7b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
|
|
|
| |
... rather than separately in the derived items.
Change-Id: I3f036ad45269daaa44aabfcd017c524083c84399
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exporting a list of rpaths from a target is completely bogus as-is,
because a target cannot know a dependee's install location relative to
itself. This patch instead has each target category (executables in bin,
libraries in lib, libexec binaries in libexec/qbs, and plugins in
lib/qbs/plugins) set its relative installation directory at the product
level, and then an appropriate rpath is created for the target by
calculating a relative path from the target to the lib directory in the
context of an installed build. This also has the advantage that rpaths
are now calculated dynamically at build time rather than hardcoded, so
if a user changes the directory depth of pluginsInstallDir, for example,
everything will be adjusted automatically. Each target also therefore
now has an rpath pointing exactly to its immediate dependencies, instead
of relying on the parent process to inherit the rpath entries. Among
simply being correct, this also has the advantage that any target can
now be loaded correctly by another process which itself sets no rpath
happening to point to the qbs lib directory.
Change-Id: I8fdf24b74ef60426cea0930b7941479919226fd2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
| |
Results in a smaller symbol table and seems like a no-brainer. It was
only set to the less-strict "hidden" in the first place by mistake.
Change-Id: I7bae6a88d0619507b54da345e9f6fec5a063744b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the native object format intended to be used for runtime
loadable executable content (also known as "plugins"). Unlike most Unix
systems, macOS's Mach-O executable format does differentiate between
shared libraries (MH_DYLIB) and loadable modules (MH_BUNDLE).
For the most part, the only noticeable difference is that attempting to
link to an MH_BUNDLE will produce a hard error, which is in any case,
helpful.
Change-Id: I0d3ff284b3fe8f1b10700f1e48bc84dd5c4715b2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
| |
This makes debugging with proper symbolication possible on macOS.
Change-Id: Iad28ba3cdc2b33d099e5b80687b17d2335af4e5e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
| |
The plugins must not define QBS_LIBRARY.
Change-Id: Ie7fd3b5052bb37b5a25a08fa41a44e4731088761
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
...and fit the generator plugins into this new plugin structure.
Plugins are now handled entirely by the build system in a generic manner
and no part of qbscore (code or build files) has a direct reference to
any plugin regardless of whether qbs is being built as shared or static
libraries.
Change-Id: I4a20546ce275df71083ee22c2cb67f781c4de764
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
