| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
You can add extra library paths to LDFLAGS directly.
|
| |
|
|
|
|
|
|
|
|
| |
If you want to change your compiler arguments, just set CFLAGS/CXXFLAGS.
Having Mesa have this separate variable is a great way to have your arguments
not thoroughly propagated to all compiler invocations.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
In all current uses, it was appended to CFLAGS, which already had -m32. If
you want to do some other flag supplied to compiler invocations, there's
CFLAGS/CXXFLAGS.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since osmesa now has been converted to Makefile.am, an appropriate install: rule
is generated to install the shared libary, so we no longer need to do that in
src/mesa/Makefile.old
This leaves nothing in src/mesa/Makefile.old but the tags: rule, so move that to
Makefile.am and remove Makefile.old
Also, nothing now uses OSMESA_LIB_GLOB anymore, so remove it
Signed-off-by: Jon TURNEY <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* "configure substitutions are not allowed in _SOURCES variables" in automake,
so remove the AC_SUBST'ed GLAPI_ASM_SOURCES and instead use some AM_CONDITIONALS
to choose which asm sources are used
* Change GLAPI_LIB to point to the .la file in other Makefile.am files, and make a link
to the .a file for the convenience of other Makefiles which have not yet been converted
to automake
v2:
- Use AM_CPPFLAGS for cleaner build output
- EXTRA_SOURCES is not needed
- Remove libglapi.a compatibility link on clean
Signed-off-by: Jon TURNEY <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Matt Turner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now mesa/drivers/dri is converted to automake, we want to update DRI_LIB_DEPS
so that we link with the libmesa or libdricore libtool library, as appropriate.
However, this is complicated by the fact that gallium/targets is not (yet)
converted, so we can't share the DRI_LIB_DEPS autoconf variable with that anymore.
Add an additional autoconf variable GALLIUM_DRI_LIB_DEPS, which is now used in
gallium/targets/Makefile.dri, to link with the libdircore or libmesa native library.
v2: libdricore$VERSION.a needs to be libdricore$(VERSION).a
Signed-off-by: Jon TURNEY <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Matt Turner <[email protected]>
|
| |
|
|
|
|
| |
Signed-off-by: Jon TURNEY <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Matt Turner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Our intention is still that it's not abi stable, so make the package
version number get included in the library name. Now you can parallel
install dricore-using drivers from multiple mesa versions. We can put
it into lib now that we're following library versioning rules
(assuming that ABIs don't change within a single Mesa point release).
LD_LIBRARY_PATH still doesn't work with a non-/, non-/usr prefix
because libtool uses rpath instead of runpath for nonstandard
prefixes.
|
| |
|
