tom fogal wrote:
Andy Furniss writes:
I've just had to rm -r and re-clone because I couldn't find how to
distclean :-).
"git clean -df" makes things pretty clean ;)
I don't think I know how to distclean in cmake either... the workaround
for cmake is to just use out of source builds. Then "c
Andy Furniss writes:
> I've just had to rm -r and re-clone because I couldn't find how to
> distclean :-).
"git clean -df" makes things pretty clean ;)
I don't think I know how to distclean in cmake either... the workaround
for cmake is to just use out of source builds. Then "clean... no, i
*me
Marek Olšák wrote:
I just pushed commit c880d607992ae7bdc29f70f8eec34c481fed7811 to piglit,
which should fix this.
Thanks, that fixes glew - but I don't get much further because it still
tries to link against old Xlibs in /usr rather than new ones in custom path.
I must admit I haven't tried
I just pushed commit c880d607992ae7bdc29f70f8eec34c481fed7811 to piglit,
which should fix this.
Marek
On Fri, Feb 18, 2011 at 1:34 PM, Andy Furniss wrote:
> As I have mesa/libdrm/xorg gits installed under home and my system versions
> are very old and broken/missing I need to get cmake to use c
As I have mesa/libdrm/xorg gits installed under home and my system
versions are very old and broken/missing I need to get cmake to use
custom paths.
With current git even though glew include dir is settable with ccmake it
still insists on looking in /usr/include. I have tried many combinations
