I was wondering if anyone would be interested in autotooling
(autoconf, automake, libtool) Mesa. I'd be willing to supply a patch
to do this (some can be copied from the xserver), but I thought I'd
check first to see if it would even be accepted before I started
working on it.
The current Mesa
On 8/7/07, Brian Paul [EMAIL PROTECTED] wrote:
Bash was needed for the line:
@ if [ -e configs/current ] ; then
is
@ if `test -e configs/current ` ; then
a suitable replacement for sh?
Man, solaris sh sucks. Do you know specifically what the error was? In
the second one, you
On 8/7/07, Daniel Stone [EMAIL PROTECTED] wrote:
On Tue, Aug 07, 2007 at 02:03:19PM -0700, Dan Nicholson wrote:
Actually, I think the problem here is that `test' on Solaris sh can't
handle -e. Just use -f instead. It respects real files or symlinks.
-f on zsh/bash, at least, is regular
When installing a package, it is often useful to place the contents in
a temporary staging directory. The customary way to support this installation
style is through the variable DESTDIR. When set during `make install', it
will prepend this path to all installed contents.
---
Dan
On 9/12/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
Currently there is no reliable and simple way to configure for and develop
with the Mesa OpenGL libraries. This is especially true if there are
multiple
GL installations. The pkg-config utility makes these problems much
Many of the directories in progs/ were missing .gitignore files or
were tracking generated files. This patch is basically the process of
running `make' in each directory and then finding the untracked files
with `git-ls-files -o --exclude-per-directory=.gitignore'. The existing
files were also
This patch set moves the library dependencies for the programs out of
the configs file and into the programs' Makefiles. The purpose of this
is to allow building a set of the programs which don't require libglut
without changing the value of APP_LIB_DEPS.
The second and third commits change the
---
configs/linux-static|3 +--
configs/linux-x86-64-static |3 +--
configs/linux-x86-static|3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/configs/linux-static b/configs/linux-static
index 00edb16..45aefce 100644
--- a/configs/linux-static
+++
This commit adds the necessary libraries for the programs in each
specific Makefile. Previously, all programs were linked with libraries
listed in the $(APP_LIB_DEPS) variable. This effectively meant that the
libraries to link into applications was hardcoded. Instead, the contents
of
On 10/29/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
This patch set moves the library dependencies for the programs out of
the configs file and into the programs' Makefiles. The purpose of this
is to allow building a set of the programs which don't require libglut
without
On 10/29/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
This patch set moves the library dependencies for the programs out of
the configs file and into the programs' Makefiles. The purpose of this
is to allow building a set of the programs which don't require libglut
without
On 10/29/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
On 10/29/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
This patch set moves the library dependencies for the programs out of
the configs file and into the programs' Makefiles. The purpose
Like the linux-dri target, this probably shouldn't be on by default
until it's more stable. It currently can't build on the 7.0 branch.
---
Dan
I don't know if this should be applied for master, too. Nouveau was
building for me there.
configs/linux-dri-xcb |2 +-
1 files changed, 1
Hi Brian,
It seems most distros are building Mesa with the GCC option
-fno-strict-aliasing. Here were a couple bugs I could find that this
works around:
https://bugs.freedesktop.org/show_bug.cgi?id=6046
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311
Should this be in Mesa by default
On 10/31/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
Hi Brian,
It seems most distros are building Mesa with the GCC option
-fno-strict-aliasing. Here were a couple bugs I could find that this
works around:
https://bugs.freedesktop.org/show_bug.cgi?id=6046
http
Some of the Linux and FreeBSD x86 (non-static) configurations remove
-fPIC. However, the linux-x86 target doesn't. I'm not gonna try to
pretend to be an expert on position-independent code, but I'm
wondering if this should be done. If so, should all the Linux x86
targets be standardized on that?
One more. The linux target and many others set GLUT_CFLAGS =
-fexceptions. However, the linux-dri target does not. The commit this
comes from (9204e87b) doesn't mention anything about it. Any ideas?
Should I add it to linux-dri, too?
--
Dan
On 10/31/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
Some of the Linux and FreeBSD x86 (non-static) configurations remove
-fPIC. However, the linux-x86 target doesn't. I'm not gonna try to
pretend to be an expert on position-independent code, but I'm
wondering
On 10/31/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
One more. The linux target and many others set GLUT_CFLAGS =
-fexceptions. However, the linux-dri target does not. The commit this
comes from (9204e87b) doesn't mention anything about it. Any ideas?
Should I add
This is a simple script that compares the make variables set by two
different configs stubs. The purpose is to highlight differences so
that any unnecessary duplication or divergence can be removed.
For example, on Linux x86:
$ ./bin/confdiff.sh linux linux-x86
The output isn't very clean,
On 10/31/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
On 10/31/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
Some of the Linux and FreeBSD x86 (non-static) configurations remove
-fPIC. However, the linux-x86 target doesn't. I'm not gonna try to
pretend
On 10/31/07, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
This is a simple script that compares the make variables set by two
different configs stubs. The purpose is to highlight differences so
that any unnecessary duplication or divergence can be removed.
For example
On 11/1/07, Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2007-10-31 at 14:04 -0700, Dan Nicholson wrote:
New commits:
commit 013dbcd6111bc880e65ed00a7ca31e19230a81d5
Author: Dan Nicholson [EMAIL PROTECTED]
Date: Wed Oct 31 09:47:39 2007 -0700
Add -fno-strict-aliasing
On 11/1/07, Dan Nicholson [EMAIL PROTECTED] wrote:
On 11/1/07, Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2007-10-31 at 14:04 -0700, Dan Nicholson wrote:
New commits:
commit 013dbcd6111bc880e65ed00a7ca31e19230a81d5
Author: Dan Nicholson [EMAIL PROTECTED]
Date: Wed Oct 31
Use a GCC option to fix issues using libglut in C++ applications. See
commit dbcd20f and SourceForge bug 726223 for more details. In some
cases the setting already existed and just a comment was added.
---
Dan
After Michel reminded me that I should add -fno-strict-aliasing for
all GCC platforms
On Nov 11, 2007 12:54 AM, Brice Goglin [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
This commit adds the necessary libraries for the programs in each
specific Makefile. Previously, all programs were linked with libraries
listed in the $(APP_LIB_DEPS) variable. This effectively meant
Hi Brian,
Since we're not using something like automake to control the build, I
was wondering if Mesa could make more use of GNU make conditionals and
functions. There are a lot of different ways that Mesa can be built,
and I believe it could be much more robust than it currently is. Right
now we
On Nov 13, 2007 7:19 AM, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
On Nov 11, 2007 12:54 AM, Brice Goglin [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
This commit adds the necessary libraries for the programs in each
specific Makefile. Previously, all programs were linked
Since most of the xdemos don't require libGLU, it should not be required
except for those special cases. The Makefile now checks for libGLU
before attempting to build these programs.
---
Brian, I saw you changed offset.c to not use libGLU, so it could be
dropped from this patch. Does the
On Nov 13, 2007 12:11 PM, Brian Paul [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Dan Nicholson wrote:
Since we're not using something like automake to control the build, I
was wondering if Mesa could make more use of GNU make conditionals and
functions. There are a lot of different
On Dec 3, 2007 11:01 AM, Brian Paul [EMAIL PROTECTED] wrote:
Marten van der Honing wrote:
Hello,
I want to compile the mesa source for the directfb target but i get
the following error while doing: make linux-directfb .
glapi/glapitemp.h:4428: warning: 'NoOp_dispatch_stub_607' defined
The user can request specific demos directories to build in. For
example:
./configure --with-demos=demos,xdemos
The drawback is that we don't check for the necessary libararies in
that case, only that the directory in progs/ exists.
---
configure.ac | 43
Report some of the common settings back to the user after configure
has completed.
---
configure.ac | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index c639378..94fb9e3 100644
--- a/configure.ac
+++
Allow the user to specify that they want static libraries through the
--{enable,disable}-{static,shared} switches like libtool. The mesa build
only allows for one at a time, so static will be chosen if someone has
passed --enable-static or --disable-shared.
This also allows the mklib options to
Added autoconf bits to allow using DRI as the driver through the option
--with-dri-driver=DRIVER. The options are x11 (default) and dri. Three
DRI specific options for controlling the driver directory, direct
rendering and TLS are also added.
The DRI will probably not work for platforms besides
Added autoconf support for using OSMesa as the driver instead linking
it to libGL. This is enabled through --with-driver=osmesa.
To differentiate these cases, another option --enable-x11-osmesa is used
to enable or disable building OSMesa when the driver is x11.
---
configure.ac | 76
Allow the user to specify channel bits of 16 or 32 to enable OSMesa16 or
OSMesa32 instead of the default OSMesa. This option is controlled
through the option --with-osmesa-bits=BITS and is only honored when the
driver is osmesa.
The osdemos are not enabled in the 16 or 32 bit case because the
The user can request specific DRI drivers to build rather than the
default of all that build on this platform. This allows the list of
drivers to be easily slimmed down.
This is controlled through the option --with-dri-drivers. For example:
./configure --with-driver=dri
On Dec 8, 2007 3:16 AM, Julien Cristau [EMAIL PROTECTED] wrote:
On Fri, Dec 7, 2007 at 15:33:13 -0800, Dan Nicholson wrote:
The standard autoconf initialization macros require that config.guess,
config.sub and install-sh exist. The config.* scripts are from gnulib
HEAD, and the install-sh
This adds the initial support for using autoconf configuration. Support
is available for shared Xlib driver builds. Later this will be extended
to dri and osmesa-only builds and possibly targetting non-X backends.
Support for static library builds will also be added.
The configure script fills in
On Dec 8, 2007 12:48 PM, Alex Neundorf [EMAIL PROTECTED] wrote:
On 12/8/07, Dan Nicholson [EMAIL PROTECTED] wrote:
This patch set adds initial autoconf support for Mesa. Previous
discussion was that full autotools was not desired. This approach is
Is switching *to* autotools now not a bit
On Dec 9, 2007 1:32 PM, Kristian Høgsberg [EMAIL PROTECTED] wrote:
- it would be nice if we didn't have to keep config.guess, config.sub
and install-sh in git, but I guess there is no good way of
autogenerating these when no using automake.
It kind of sucks, but I don't see an easy way to
On Dec 10, 2007 7:12 AM, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
This patch set adds initial autoconf support for Mesa. Previous
discussion was that full autotools was not desired. This approach is
less invasive by working in conjunction with the current Mesa configs
On Dec 10, 2007 7:46 AM, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
export CC=/bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc
export CXX=/bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-g++
export CFLAGS=-O3 -ansi -pedantic
export CXXFLAGS=-O3
There are quite a few branches in the mesa repo that haven't seen a
commit in many years.
http://cgit.freedesktop.org/mesa/mesa/refs/heads
I may be missing something, but it seems like it would be nice to
clean up some branches that have no chance of being committed to
again. Some that come to
On Dec 18, 2007 11:10 PM, Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2007-12-18 at 22:40 -0800, Dan Nicholson wrote:
There are quite a few branches in the mesa repo that haven't seen a
commit in many years.
http://cgit.freedesktop.org/mesa/mesa/refs/heads
I may be missing
On Dec 7, 2007 5:33 PM, Dan Nicholson [EMAIL PROTECTED] wrote:
This patch set adds initial autoconf support for Mesa. Previous
discussion was that full autotools was not desired. This approach is
less invasive by working in conjunction with the current Mesa configs
system. The configure script
On Dec 27, 2007 1:31 PM, Dan Nicholson [EMAIL PROTECTED]
Brian gave me the thumbs up to merge this work to master. Since I sent
this series, I've added some fixes that Kristian suggested and some
others that Brian sent to me off list. There is also some
documentation that can be found from
On Jan 1, 2008 10:59 AM, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
The conditional in src/mesa/Makefile currently hardcodes the cases where
libOSMesa can be built on libGL. Likewise, the xlib case always includes
libOSMesa in the stand-alone target.
This changes
Hi Brian,
On Jan 21, 2008 3:37 PM, Brian Paul [EMAIL PROTECTED] wrote:
This will be a bug-fix only release.
One thing I keep forgetting about is the simple fix to make the xdemos
GL only. I.e., move yuvrect_client from the PROGS variable so GLU
isn't needed.
On Jan 22, 2008 6:58 AM, Brian Paul [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
Hi Brian,
On Jan 21, 2008 3:37 PM, Brian Paul [EMAIL PROTECTED] wrote:
This will be a bug-fix only release.
One thing I keep forgetting about is the simple fix to make the xdemos
GL only. I.e., move
On Jan 24, 2008 2:54 PM, Brian Paul [EMAIL PROTECTED] wrote:
Brian Paul wrote:
src/mesa/drivers/x11/xm_dd.c |8
src/mesa/state_tracker/st_atom_constbuf.c |1 +
2 files changed, 5 insertions(+), 4 deletions(-)
commit diffs at
On Jan 24, 2008 3:16 PM, Brian Paul [EMAIL PROTECTED] wrote:
Is there some kind of git-reset that'll restore my repo to the state
before the accidental push? I've shot myself in the foot with git-reset
in the past and usually recover rm'ing the repo and starting over.
It's kind of hard to
On Feb 1, 2008 10:59 AM, Ian Romanick [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
| I tried and tried to produce a proof of concept with CMake, but
| couldn't find a satisfactory solution for using it with mesa/gallium.
| Getting convenience
The indirect_dispatch.h and indirect_table.c source files use
gl_and_glX_API.xml in their generation rather than glX_API.xml, but it
wasn't listed in their prerequisites. In turn, gl_and_glX_API.xml uses
glX_API.xml, but this is already listed in $(COMMON_GLX).
---
src/mesa/glapi/Makefile |4
Put the path to indent and the flags to call it with in configs/default
rather than in the Makefile. This makes it easier to change the values
globally.
---
configs/default |4 +++-
src/mesa/glapi/Makefile | 16 +++-
2 files changed, 10 insertions(+), 10 deletions(-)
Three minor patches for making the generation of the GLX sources more
robust and user configurable. Functionally, nothing has changed.
--
Dan
configs/default |4 +-
src/mesa/glapi/Makefile | 98 ---
2 files changed, 53 insertions(+), 49
Make use of the make automatic variables $@ (the target) and $ (first
prerequisite) to clean up the commands for the glapi generation. This
improves readability and guards against typos since words are repeated
less frequently.
---
src/mesa/glapi/Makefile | 96
On Feb 13, 2008 6:40 AM, Dan Nicholson [EMAIL PROTECTED] wrote:
The glapi source files for the xserver's GLX module are currently
generated in the mesa tree and then manually merged into the the xserver
tree. This step in the GLX build is error prone as the files can easily
become
On Thu, Feb 14, 2008 at 9:34 AM, Daniel Stone [EMAIL PROTECTED] wrote:
On Thu, Feb 14, 2008 at 09:14:09AM -0800, Ian Romanick wrote:
Dan Nicholson wrote:
| The glapi source files for the xserver's GLX module are currently
| generated in the mesa tree and then manually merged
On Thu, Feb 14, 2008 at 9:57 AM, Daniel Stone [EMAIL PROTECTED] wrote:
On Thu, Feb 14, 2008 at 09:44:28AM -0800, Dan Nicholson wrote:
On Thu, Feb 14, 2008 at 9:34 AM, Daniel Stone [EMAIL PROTECTED] wrote:
On Thu, Feb 14, 2008 at 09:14:09AM -0800, Ian Romanick wrote:
We used to do
On Feb 15, 2008 1:55 PM, Ian Romanick [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Nicholson wrote:
| Unless anyone has anyone has any further objections, I'll be pushing
| these to mesa and xserver within the next day or so. Ian, are you
| still concerned
Instead of globbing all the headers in include/GL, we should install
the headers only when the associated library is being installed. For
example, this means that glut.h will not be installed if libglut is not
being installed.
Most of the headers are included in the GL_HEADERS variable in
On Wed, Feb 27, 2008 at 8:26 AM, Adam Jackson [EMAIL PROTECTED] wrote:
On Tue, 2008-02-26 at 11:17 -0800, Dan Nicholson wrote:
On Tue, Feb 26, 2008 at 11:06 AM, Adam Jackson [EMAIL PROTECTED] wrote:
February 29: Branch 1.4.99.901, no new features
Out of curiosity, which version
On Wed, Feb 27, 2008 at 10:04 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote:
On Wed, Feb 27, 2008 at 12:43 PM, Dan Nicholson [EMAIL PROTECTED] wrote:
On Wed, Feb 27, 2008 at 8:26 AM, Adam Jackson [EMAIL PROTECTED] wrote:
Aah, the Mesa question. I love this part.
DRI2, unlike
The defacto method to rebuild the autotools and run the generated
configure is an autogen.sh script. It is much more discoverable than the
custom `make configure' used here. The Makefile targets are still useful
for creating tarballs, though. This autogen.sh is copied from Xorg.
---
Dan
I feel
On Fri, Mar 7, 2008 at 2:04 PM, Daniel Stone [EMAIL PROTECTED] wrote:
On Fri, Mar 07, 2008 at 12:24:20PM -0800, Dan Nicholson wrote:
The defacto method to rebuild the autotools and run the generated
configure is an autogen.sh script. It is much more discoverable than the
custom `make
On Fri, Mar 7, 2008 at 3:03 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Friday, March 07, 2008 12:24 pm Dan Nicholson wrote:
The defacto method to rebuild the autotools and run the generated
configure is an autogen.sh script. It is much more discoverable than the
custom `make configure
On Sun, Mar 9, 2008 at 4:56 PM, Brian Paul
I'm OK with the autogen.sh script. Was there more?
Please update the Mesa docs too, as needed.
Nothing more, I just wanted to get your approval before adding more
files from the autospew. I'll update my patch with Daniel's
suggestions and the
Kristian,
Unfortunately, moving the libGL install target to src/glx breaks all
the non-glx targets since libGL will never be installed in those
cases. Is there a particular problem you were trying to solve with
that?
--
Dan
On Mon, Mar 10, 2008 at 2:15 PM, Kristian Høgsberg [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 2:32 PM, Dan Nicholson [EMAIL PROTECTED] wrote:
Kristian,
Unfortunately, moving the libGL install target to src/glx breaks all
the non-glx targets since libGL will never be installed
I'd like to cherry-pick back the changes from master that generate the
glapi files for xserver glx in the mesa tree. You can't build xserver
master or the server-1.5-branch against Mesa 7.0 right now. These
commits won't fix that issue, but it can't be fixed at all without
these patches. If
2008/3/11 Wu, Nian [EMAIL PROTECTED]:
Brian Paul wrote:
Cool, hopefully you can update the
http://wiki.x.org/wiki/Development/git with the new best practices
for building/installing Mesa into a separate path?
I followed the steps in http://wiki.x.org/wiki/Development/git to
The autoconf macro AC_PATH_PROGS handles the case of searching for
multiple program names already, so we don't need to open code it.
---
Eric, does this seem alright? I think there's a bug in setting the MAKE
variable here at all (when you run GNU make, it will set $MAKE in the
environment),
On Wed, Apr 9, 2008 at 11:07 AM, Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2008-04-09 at 14:18 +0300, Hasso Tepper wrote:
The attached patches add support for DragonFly BSD. dragonfly-mesa70.patch
is applicable to both 7.0 branch and master,
dragonfly-mesa-autoconf.patch just adds
On Wed, Apr 23, 2008 at 7:24 AM, Brian Paul
[EMAIL PROTECTED] wrote:
Anatolij Shkodin wrote:
There are some programs on FreeBSD that require static MesaGL libraries.
However, freebsd-static is unavailable in Makefile.
Compiling linux-static works well, but then hangs during make
Since the only valid consumer of the DRI drivers is the X.Org xserver,
this changes the default DRI driver directory to match xorg-server:
${libdir}/dri. The old default of /usr/X11R6/modules/dri was wrong for
nearly all current systems.
---
configs/default |2 +-
configure.ac
On Tue, May 6, 2008 at 2:47 PM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 10:56 Tue 06 May , Dan Nicholson wrote:
Adds an --enable-xcb switch to use XCB in GLX. This only has an effect
when the driver is DRI.
---
Donnie, does this work for you?
Is it really only used when
Added the autoconf driver option --with-driver=glcore for building
libGLcore for xorg-server. When building glcore through autoconf, it
will check that xorg-server is new enough (1.5.99.1 corresponds to
current master). It will then check if XF86DRI is defined and enable
the DRI functionality in
Rather than just defining HAVE_POSIX_MEMALIGN on Linux, check whether
the function exists on all platforms and define the macro if it is.
---
Dan
This seems like the right thing to do, but I only have Linux to test
on. Any BSDers know if this is alright? As I understand it,
posix_memalign is
Since the gl pkg-config file doesn't convey any specifics about the
backend in use, this adds a new pkg-config file for when DRI is in use.
This can be used by the xserver build to determine if the DRI extension
is appropriate.
---
Dan
I don't know if this makes anything a lot better, but I
On Fri, Jun 20, 2008 at 6:07 PM, Alan Coopersmith
[EMAIL PROTECTED] wrote:
I needed to apply the attached patches to git master to be able to build
on Solaris using the autoconf support and the Sun compilers - can they be
included for the 7.1 release?
I'm just gonna comment on the
Any issues with this patch? I'll probably push it if there are no objections.
On Wed, Jun 4, 2008 at 1:26 PM, Dan Nicholson [EMAIL PROTECTED] wrote:
Rather than just defining HAVE_POSIX_MEMALIGN on Linux, check whether
the function exists on all platforms and define the macro
Anyone have any problems with this?
On Thu, Jun 12, 2008 at 7:12 AM, Dan Nicholson [EMAIL PROTECTED] wrote:
Since the gl pkg-config file doesn't convey any specifics about the
backend in use, this adds a new pkg-config file for when DRI is in use.
This can be used by the xserver build
On Mon, Jun 16, 2008 at 2:07 PM, Brian Paul
[EMAIL PROTECTED] wrote:
seventh guardian wrote:
Oh, I see that the master branch has autoconf. Are there any plans to
use autoconf for the origin/gallium-0.1 branch?
No plans for now. Too busy w/ other things.
Feel free to try bringing it over
On Sun, Jun 29, 2008 at 7:44 PM, Roland Mainz [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
Do you know which parts are too POSIXy? I don't think it would be too
much work to make the build work with any reasonable Bourne shell.
The problem is that Solaris's old /usr/bin/sh is really the old
On Thu, Jul 3, 2008 at 8:04 AM, Timo Aaltonen [EMAIL PROTECTED] wrote:
On Thu, 3 Jul 2008, Dan Nicholson wrote:
On Thu, Jul 3, 2008 at 2:08 AM, Timo Aaltonen [EMAIL PROTECTED] wrote:
Hi!
I'm updating the Debian mesa package to use autoconf, and noticed that
the
handling of --libdir
On Fri, Jul 04, 2008 at 02:09:09AM +0300, Timo Aaltonen wrote:
On Thu, 3 Jul 2008, Dan Nicholson wrote:
Here's a patch to try out. Could you review it a bit? I think I caught
all details, but it's a fairly invasive patch. One drawback is that
the pkgconfig directory is still set directly
On Sat, Jul 5, 2008 at 4:56 AM, Julien Cristau [EMAIL PROTECTED] wrote:
On Sat, Jul 5, 2008 at 12:49:57 +0200, Julien Cristau wrote:
would it be possible to make this work with space as a separator?
Nevermind, that seems to work already. Sorry for the noise.
Funny, I didn't intend for that
On Thu, Jul 3, 2008 at 4:50 PM, Alan Coopersmith
[EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
Oh, we should probably be setting SHELL in configs/autoconf all the
time. Autoconf has support for this by using the shell that configure
was called with or the value of CONFIG_SHELL.
Do you know
On Fri, Jul 4, 2008 at 12:05 AM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Thu, 2008-07-03 at 16:50 -0700, Alan Coopersmith wrote:
As for libX11, the Solaris linker complains if you call an X11 function
like XOpenDisplay() from your application, but don't link directly to it,
even if you link
Add an --enable-motif option, which will enable the Motif widgets in
libGLw and link it with libXm. The Motif installation information will
be gathered from the motif-config script (this comes with LessTif) or
fallback to the standard autoconf checks.
To allow the location of the Motif headers to
On Thu, Sep 25, 2008 at 2:38 AM, Mustafizur
[EMAIL PROTECTED] wrote:
Yes, i thought so..so i tried to link libmesa.a in
src/gallium/winsys/egl_xlib/Makefile.But then i ran into more interesting
problem, i am not sure whether any one has faced it before, but i think it
is a serious
On Mon, Nov 24, 2008 at 5:38 AM, RALOVICH, Kristóf
[EMAIL PROTECTED] wrote:
On Mon, Nov 24, 2008 at 14:11, Jerome Glisse [EMAIL PROTECTED] wrote:
On Mon, 24 Nov 2008 12:51:08 +0100
RALOVICH, Kristóf [EMAIL PROTECTED] wrote:
On Tue, Nov 18, 2008 at 18:05, RALOVICH, Kristóf
[EMAIL PROTECTED]
On Thu, Dec 11, 2008 at 12:07 PM, Verge miket...@gmail.com wrote:
As requested.
The errors were so much, couldn't dispaly it all.
BY the way, I obtained this errors when I try to gmake Mesa after
./configuring it to sparc-linux target.
What arguments did you give to configure?
Paste of
, are you trying to cross compile mesa or are you just trying use a
different compiler? If you just want to specify the compiler, just
`export CC=sparc-linux-gcc' before you run ./configure.
Dan Nicholson-2 wrote:
On Thu, Dec 11, 2008 at 12:07 PM, Verge miket...@gmail.com wrote:
As requested
On Fri, Dec 12, 2008 at 9:08 AM, Verge miket...@gmail.com wrote:
Ah, really sorry. Made a stupid mistake.
Ofcourse, what I kept as an input was infact the compiler. What I meant to
write was
./configure --target=sparc-linux --host=sparc-linux
I am trying to make mesa make libraries for
On Mon, Jan 12, 2009 at 7:04 AM, Julien Cristau jcris...@debian.org wrote:
Fixes build on arm-linux-gnueabi
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index d3a9364..6a99f30 100644
--- a/configure.ac
+++
On Mon, Jan 12, 2009 at 10:53 AM, Julien Cristau jcris...@debian.org wrote:
On Mon, Jan 12, 2009 at 10:47:53 -0800, Ian Romanick wrote:
Does defining _GNU_SOURCE actually cause those other things to be
defined? What happens if there are places in the Mesa code that check
for, say,
On Mon, Jan 12, 2009 at 11:02 AM, Julien Cristau jcris...@debian.org wrote:
On Mon, Jan 12, 2009 at 11:00:15 -0800, Dan Nicholson wrote:
Do you want to push your patch, and I'll add another to reduce the
macros to just _GNU_SOURCE?
I don't have write access to the mesa repo, so I'll let you
1 - 100 of 203 matches
Mail list logo
