| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These definitions come in handy when a project generates alongside
its ``primary shared library'' one or more ``extension libraries''
that depend on it. When the rules for generating extension
libraries use the $^ directive, the above dependency must
be declared in a target-aware manner.
In most cases, one would want to express this dependency by way
of $(DSO_REF_SONAME), thereby pulling in lib/libfoo.so.$(MAJOR)
on ELF targets, lib/libfoo.$(MAJOR).lib.a on midipix targets,
and lib/libfoo.$(MAJOR).dll.a on win32 targets.
|
|
'cause you cannot eat your Apfel and eat it two.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Prior to this patch, there were several differences between this project's
build system and the one from which it was derived (sofort). Although the
differences were very minor and for the most part related to this project
being part of a free-standing, midipix-specific development framework,
they still added an extra maintenance burden, specifically by requiring
that common changes be applied via patch(1) rather than git-am(1).
Following recent improvements to the common build system, it is now
possible to have a free-standing, midipix-specific project without
any changes to the core build system files, hence the current upgrade.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and fix CC accordingly.
|
|
|
|
|
|
|
