Thread: [TuxKart-devel] configure dir
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel
|
From: Bram S. <br...@ch...> - 2000-07-01 17:53:47
|
Steve Baker wrote: >FYI: I just released the first release of TuxKart - which uses PLIB and >the same characters as my Tux_AQFH game. > > http://tuxkart.sourceforge.net Nice one! Congrats. A remark: autocont/automake suggests doing the configure stage in a directory other than the distrib dir. If you follow this advice, a make install will fail for tuxkart. (/usr/local/share/* remains empty) Turkart will only install if distrib-dir == configure-dir. I cannot comment on the game itself, unfortunately, I do not have a joystick. (I guess my forcefeedback wheel is a no-go with linux) Bram -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bram Stolk "Linux - Why use windows, if there is a door?" work: br...@sa... priv: br...@ch... |
|
From: Steve B. <sjb...@ai...> - 2000-07-02 01:23:10
|
Bram Stolk wrote:
> A remark:
> autocont/automake suggests doing the configure stage in a directory
> other than the distrib dir.
Why? That's crazy - everyone unpacks the tarball, cd's into
the newly formed directory and types ./configure;make;make install
...which works just fine.
Why on earth would you want to do any different?
> If you follow this advice, a make install will fail for tuxkart.
> (/usr/local/share/* remains empty)
> Turkart will only install if distrib-dir == configure-dir.
I guess I don't understand the issue - nobody else of the 1000 or
so downloads since yesterday has mentioned this. TuxAQFH and PLIB
both use the same mechanisms - and between those two, that's 200,000
downloads with no complaints.
What's the problem?
> I cannot comment on the game itself, unfortunately, I do not
> have a joystick. (I guess my forcefeedback wheel is a no-go with linux)
Dunno - the force-feedback part is no-go because Microsoft won't share
the interface details for force-feedback devices. But as a digital
joystick-like device, it's probably supported.
I'm working on a keyboard and/or mouse interface as we speak - so
it shouldn't be long in coming.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Bram S. <br...@ch...> - 2000-07-02 08:41:43
|
Steve Baker wrote: > > Bram Stolk wrote: > > > A remark: > > autocont/automake suggests doing the configure stage in a directory > > other than the distrib dir. > > Why? That's crazy - everyone unpacks the tarball, cd's into > the newly formed directory and types ./configure;make;make install > ...which works just fine. > > Why on earth would you want to do any different? > > > If you follow this advice, a make install will fail for tuxkart. > > (/usr/local/share/* remains empty) > > Turkart will only install if distrib-dir == configure-dir. > > I guess I don't understand the issue - nobody else of the 1000 or > so downloads since yesterday has mentioned this. TuxAQFH and PLIB > both use the same mechanisms - and between those two, that's 200,000 > downloads with no complaints. > > What's the problem? Eh, you're right about the little impact of the issue, and because it works for 99.999999% of your users, I understand that it is probably not worth fixing. However, if you want to do the "Right Thing" as you call it, I beg you to read a bit further. The document "the GNU configure and build system" states that seperation is 'highly recommended', and gives some arguments at http://www.airs.com/ian/configure/ an excerpt: * In order to use a object directory which is different from the source directory, you must be using the GNU version of `make', * which has the * required `VPATH' support. Despite this restriction, using a different object directory is highly recommended: * * It keeps the files generated during the build from cluttering up your sources. * It permits you to remove the built files by simply removing the entire build directory. * It permits you to build from the same sources with several sets of configure options simultaneously. But I think the author forgets the main reason: If I want to build for three architectures (intel,alpha,ppc), and for each architecture I want to test the difference between optimized and non-optimized builds, then I do not want to have 6 copies of the source. Each target each own build dir, and only 1 src dir is very clean. Heck, you could even have a Mesa-build and a nVidia OGL build coexist on your system, sharing the same sources. Now don't tell me that this does not appeal to you :-) It really must. Also, making a distribution is easier, you can tar the src dir, without having to worry about what's in there: it will be sources only, no configure residue. But as I've said, the numbers tell you it's not worth the effort. So please ignore my pedantic ramblings, and enjoy the success of yet another steve and oliver baker tux game :-) I just hope you agree with me now, that the illicit reasons do exist. Bram Stolk -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bram Stolk "Linux - Why use windows, if there is a door?" work: br...@sa... priv: br...@ch... |
|
From: Steve B. <sjb...@ai...> - 2000-07-02 09:20:27
|
Bram Stolk wrote:
>
> Steve Baker wrote:
> >
> > Bram Stolk wrote:
> >
> > > A remark:
> > > autocont/automake suggests doing the configure stage in a directory
> > > other than the distrib dir.
Ah! Now I understand - you just want the binaries somewhere separate
from the sources...and the proposed way to do that is to run the configure
file from the distribution tree in an empty directory heirarchy so that
the object code ends up there instead of all mixed up in the source tree
(something which annoys me no end with autoconf/automake).
> But I think the author forgets the main reason:
>
> If I want to build for three architectures (intel,alpha,ppc), and for each
> architecture
Yep - I agree 100% - we have this problem all the time at work where we
have to build the same code for three different IRIX varients, a Solaris
machine and a bunch of Linux boxes - some with Alpha's and some with Pentiums.
The problem here is that it requires the GNU version of make to do this - and
MANY systems don't have that installed as the default...or at all for that
matter. There are also numerous 'pmake', 'smake' and 'NMAKE' varients with
certain advantages to each...pmake and smake can do cool parallel makes on
machines like our big ONYX boxes that have 40+ CPU's. GNU make gives up and/or
crashes when you do that.
What we did was to write a preprocessor for our Makefiles that takes a special
'XMakefile' - runs it through cpp and a number of other tools and spits out a
normal 'Makefile' - which it then passes to whatever underlying make there is.
Then in each source directory, we have daughter directories named after each
machine architecture and the makefile mangler manages to get the '.o' and '.a'
files to disappear into those daughter directories by stuffing '-o' directives
onto compile lines and various other subterfuges.
For our own purposes, this works quite well and with 'make' aliased to 'xmake',
nobody is even very much aware of the intrusion. Regenerating the Makefile
before each 'make' has the advantage that we can hide the annoying differences
between 'make' implementations.
However, that's clearly not a solution for mass distribution.
> Heck, you could even have a Mesa-build and a nVidia OGL build coexist on your
> system,
> sharing the same sources. Now don't tell me that this does not appeal to you :-)
erm - sorry:
"That does not appeal to me". :-)
The reason it doesn't is that now that we have the "OpenGL ABI for Linux" stuff
nailed down, I don't *need* separate binaries for nVidia and Mesa. Here at home,
I have one machine with an nVidia GeForce and another with a Voodoo-3 2000 - and
they share a NFS partition on my home fileserver. Hence, the exact same binaries
run on both machines - and I can compile on either one of them and run on the other.
> It really must.
Nope!
> But as I've said, the numbers tell you it's not worth the effort. So please
> ignore my pedantic ramblings, and enjoy the success of yet another steve
> and oliver baker tux game :-)
> I just hope you agree with me now, that the illicit reasons do exist.
Actually, I do want to do things right - just so long as it doesn't screw
things up for the majority of users - and now I understand what you are
talking about, I whole-heartedly agree as to the need.
However, I'm pretty much ignorant of the workings of autoconf/automake and
the manuals for them are *appaling* to read. If you can guide me as to what
I need to do, I'll be happy to do it just so long as Joe Q Public can still
type ./configure;make;make install and have it "just work".
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Bram S. <br...@ch...> - 2000-07-02 09:35:18
|
Steve Baker wrote: > I have one machine with an nVidia GeForce and another with a Voodoo-3 2000 - and > they share a NFS partition on my home fileserver. Hence, the exact same binaries > run on both machines - and I can compile on either one of them and run on the other. Wow, even better! Why just share sources, if you can share binaries as well? :-) Let me try again: How do you fancy a tuxkart against stable plib1.2, and one against unstable plib1.3? Or do you use the 'one plib per machine' paradigm here as well? > However, I'm pretty much ignorant of the workings of autoconf/automake and > the manuals for them are *appaling* to read. If you can guide me as to what > I need to do, I'll be happy to do it just so long as Joe Q Public can still > type ./configure;make;make install and have it "just work". Quite a challenge. I'll see what I can do, although I have only access to gmake here. Bram -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bram Stolk "Linux - Why use windows, if there is a door?" work: br...@sa... priv: br...@ch... |
|
From: Steve B. <sjb...@ai...> - 2000-07-02 17:28:27
|
Bram Stolk wrote:
>
> Steve Baker wrote:
>
> > I have one machine with an nVidia GeForce and another with a Voodoo-3 2000 - and
> > they share a NFS partition on my home fileserver. Hence, the exact same binaries
> > run on both machines - and I can compile on either one of them and run on the other.
>
> Wow, even better! Why just share sources, if you can share binaries as well? :-)
That is generally the goal here. If you have machines with the same CPU, you
should be able to do this...and you can! With the advent of a working GLX
protocol, it becomes essential that the OpenGL of one machine is compatible
with the other because OpenGL will be running on one machine - being sent
commands from the other. There are a few sneaky 'gotchas' in there because
of OpenGL runtime extension detection being rather ill-thought-out. With
the OpenGL ABI for Linux, all that is sorted out.
> Let me try again: How do you fancy a tuxkart against stable plib1.2, and one
> against unstable plib1.3? Or do you use the 'one plib per machine' paradigm
> here as well?
No - I guess that would be useful - although I tend to work with the latest PLIB
all the time and just compile (after a make clean) against the stable release
before I make a release. Since that's a rare event and I need to 'make clean'
to be really sure everything is going to work OK for the end user - it's not
really that much of a pain.
Anyway, your point is well taken - it's just that I don't have the necessary
skills to make it work.
> > However, I'm pretty much ignorant of the workings of autoconf/automake and
> > the manuals for them are *appaling* to read. If you can guide me as to what
> > I need to do, I'll be happy to do it just so long as Joe Q Public can still
> > type ./configure;make;make install and have it "just work".
>
> Quite a challenge.
> I'll see what I can do, although I have only access to gmake here.
OK...well if it's hard to you (who evidently knows this stuff) then it's
impossible for me. If you feel a burning need to do it - then I'll happily
make use of the results (in all of my projects hopefully) - but it is an
absolute requirement that Joe Public can type './configure ; make ; make install'
to do 'the usual thing'. That's become a de-facto standard for installing Linux
programs and if I deviate from that I'll get 1000 emails a week from people who
can't get it right and/or don't read the instructions. That's not an exaggeration
BTW.
I you don't want to do it, I'll understand - I don't feel a huge need for this -
although it would be useful.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X