| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
It's not annoying having to type it anymore. Also
"otr_boilerplate" -> "otr_module".
|
|
Given that i18n stuff regens all the time it's annoying.
|
|
|
|
|
|
Don't rely on a macro that shouldn't be necessary.
The information "opentrack_boilerplate" retrieves is now factored out to
be easily available to projects themselves.
opentrack_boilerplate can now also build executables.
When appropriate, target properties are now concatenated rather than
replaced.
|
|
|
|
Adjust usages.
|
|
|
|
|
|
Here, the "logic" module has all the stuff for building one's own
graphical user interface.
The "api" module has stuff used by other trackers.
While at it, each of "api", "logic", and "compat" need their own export
headers. This is because of preprocessor symbol clashes.
This is all because a change in the "gui"-only dependency required a
relink of all the trackers, protocols, and flters. It takes too long
when building in the release configuration. With the split, only the
"gui" module gets rebuilt. Since it has close to no static dependencies,
it's fast enough.
|
|
|
|
It's used in the win32 installer.
This reverts commit 3252beca3aa20fe5183a13029db831e4e121f6dc.
|
|
We no longer have this recurring problem since I enabled
ignoring executable bit changes on the Windows workstation.
|
|
It's pointless for it to exist, see previous commit for rationale. No
call sites.
|
|
With the GNU toolchain there's some mix-up and the "opentrack_version"
symbol isn't emitted into the object file at all. Disable LTO for the
"version" statically linked library.
The "version" statically linked library exists so that files needing the
version only need to be re-linked, not recompiled. A preprocessor global
-DVERSION=foo rebuilds the whole project after each commit. A header
definition rebuilds all include sites.
LTO in the GNU toolchain is very broken on Windows, particular the
interaction of GCC "linker plugin" injected into Binutils bfd ld. The
gold ld we can't use since it's only for ELF executables.
There's nothing alarming here at all unless there's some miscompilation
and there doesn't seem to be any. The rest of the functional changes is
changing cc -> c of that object file, and moving library definition
after the source file is already generated.
|
|
Closes #340
|
|
|
|
|
|
Closes #224
|
