Celestia Forums

I have successfully compiled celestia CVS on my SuSE 9.3 linux box running the KDE 3.4 desktop. I asked a somewhat similar question months ago and got no response so I'll try again:

After I compile the CVS is there any way I can get it to run from its build directory rather than having to install it with "make install"? I would like to be able to test the CVS version without screwing up my install of the stable version. In other words, I would like to be able to get both the stable release of celestia and the CVS version working on my system at the same time. Can this be done and how?

I am running from KDE 3.4. My standard configure script for compiling the CVS (after running make -f Makefile.cvs) is as follows:

./configure --with-kde --with-lua-inc=/usr/include/lua --with-lua-libs=/usr/lib --prefix=/opt/kde3

toadatrix wrote:I have successfully compiled celestia CVS on my SuSE 9.3 linux box running the KDE 3.4 desktop. I asked a somewhat similar question months ago and got no response so I'll try again:

After I compile the CVS is there any way I can get it to run from its build directory rather than having to install it with "make install"? I would like to be able to test the CVS version without screwing up my install of the stable version. In other words, I would like to be able to get both the stable release of celestia and the CVS version working on my system at the same time. Can this be done and how?

I am running from KDE 3.4. My standard configure script for compiling the CVS (after running make -f Makefile.cvs) is as follows:

./configure --with-kde --with-lua-inc=/usr/include/lua --with-lua-libs=/usr/lib --prefix=/opt/kde3

I do that all the time (Suse 9.0, 9.1,9.2 on various machines), whenever there were changes.

You do your full 'make install' once, then your textures etc. will be located in /usr/local/share/celestia.

After making a new celestia in your 'build-celestia' directory, you may of course run it directly from that directory, as long as this new executable was also configured to look for textures etc in /usr/local/share/celestia.

What I do is to update from CVS always into the same 'celestia' directory, the contents of which I never touch. Then I sync-copy the differences relative to my actual build-celestia directory with 'rsync' (in a Makefile). Hitting make in the build-celestia directory then does not need new configuration each time and also recompiles only the files that have changed. This way the whole procedure of CVS updating +rebuilding takes only 1-2 minutes on my machine and is fully automatized.


Bye Fridger

Thanks Fridger, I understand most of what you are saying but I am still somewhat new to linux. Could you please explain to a linux newbie how you sync-copy differences between the CVS and build directories using "rsync" in a Makefile? It sounds like you have built a special Makefile, or at least edited the one that comes with celesita's CVS. I can see how I would do the rsync manually, but I don't know how to automate the process as you decribe. Please explain and thanks once again.

toadatrix wrote:Thanks Fridger, I understand most of what you are saying but I am still somewhat new to linux. Could you please explain to a linux newbie how you sync-copy differences between the CVS and build directories using "rsync" in a Makefile? It sounds like you have built a special Makefile, or at least edited the one that comes with celesita's CVS. I can see how I would do the rsync manually, but I don't know how to automate the process as you decribe. Please explain and thanks once again.

OK, here we go:

The 'virgin' celestia directory (that exclusively gets the CVS updates, but is never touched) is a subdir of Sandbox:

/usr/local/cvs/Sandbox/celestia

in Sandbox there is also the following Makefile that triggers the 'sync-copy' (using the standard application 'rsync'):


*******************Makefile****************


The various celestia build directories are on the same level as Sandbox: There is one for celestia-kde, celestia-gnome and celestia-gtk.

i.e

/usr/local/cvs/celestia-kde
/usr/local/cvs/celestia-gnome
/usr/local/celestia-gtk

Suppose after updating Sandbox/celestia from CVS, I want to rebuild celestia-kde, all I do is type

make kde

in Sandbox and then

cd ../celestia-kde
make

That's all. I then can try out the new celestia executable directly in celestia-kde. Same for the other builds (remember I am a celestia developer, so I got to try all of them )

Exactly the same procedure I apply in Windows-XP, where I run CYGWIN-Linux on top of XP. The updating is done identically under CYGWIN-Linux, while the recompilation is left to the native Windows Microsoft C++ compiler.

Bye Fridger

PS: I hope you know that Makefiles need a TAB at the beginning of each command line (no spaces!!!!)
eg (cf above):

kde:
<TAB>rsync .....

Fridger,

I got it to work, well sort of. I changed your script as I am only interested in compiling for one desktop (KDE). Here is my modified script:

celestia:
rsync -avur --exclude ??*~?? --exclude ??*.dsw?? ~/CVS/celestia/ ~/Software/celestia-cvs

all: celestia

(Note: rsync line starts with TAB character)

I got it to run once and transfer everything from my virgin CVS of ~/CVS/celestia to my build and test directory of ~/Software/celestia-cvs. The problem is that I can't get it to run a second time. Everytime I try and run it I get a message saying "celestia is uptodate". That's the case even if I completely delete the contents of ~/Software/celestia-cvs.

How can I reset the thing to get it rerun as if I had never done the first transfer? I did some searching with Google, but couldn't find an answer to this.

Also, should my script work whether I do either of the following:

make celestia

OR

make -f Makefile

Thanks for helping to educate. Its a neat tool if I can get more comfortable with it.

toadatrix wrote:Fridger,

I got it to work, well sort of. I changed your script as I am only interested in compiling for one desktop (KDE). Here is my modified script:

celestia:
rsync -avur --exclude ??*~?? --exclude ??*.dsw?? ~/CVS/celestia/ ~/Software/celestia-cvs

all: celestia

(Note: rsync line starts with TAB character)

I got it to run once and transfer everything from my virgin CVS of ~/CVS/celestia to my build and test directory of ~/Software/celestia-cvs. The problem is that I can't get it to run a second time. Everytime I try and run it I get a message saying "celestia is uptodate". That's the case even if I completely delete the contents of ~/Software/celestia-cvs.

How can I reset the thing to get it rerun as if I had never done the first transfer? I did some searching with Google, but couldn't find an answer to this.

Also, should my script work whether I do either of the following:

make celestia

OR

make -f Makefile

Thanks for helping to educate. Its a neat tool if I can get more comfortable with it.

The basic idea of 'make' is to act only if there is anything left to do . After rsync has updated celestia-kde from sandbox/celestia there is nothing left to do. So no restart.

'make' is not for playing. It's for working...

if you modify some source files in celestia-kde by hand, then make will act again, of course.

It should work if you just type 'make' in your case. Or make -f Makefile. Or make all.

Good luck

Bye Fridger

Thanks again Fridger. With your help I got the rsync working. Now my problem is finding the right combination of ./configure parameters in compiling that will celestia to run from its build directory. As stated above, I would normally compile for a "real install" using the following:

./configure --with-kde --with-lua-inc=/usr/include/lua --with-lua-libs=/usr/lib --prefix=/opt/kde3

Now if I am building the cvs version of celestia in:
/home/myname/Software/celestia-cvs
How would I adjust the ./configure parameters I normally use to get celestia working? I tried using --datadir=/opt/kde3 while leaving out the --prefix command, but that didn't work. I tried a couple of other things and all I see is the celestia splash screen for about 1 second and the program exits.

Thanks.

toadatrix wrote:Thanks again Fridger. With your help I got the rsync working. Now my problem is finding the right combination of ./configure parameters in compiling that will celestia to run from its build directory. As stated above, I would normally compile for a "real install" using the following:

./configure --with-kde --with-lua-inc=/usr/include/lua --with-lua-libs=/usr/lib --prefix=/opt/kde3

Now if I am building the cvs version of celestia in:
/home/myname/Software/celestia-cvs
How would I adjust the ./configure parameters I normally use to get celestia working? I tried using --datadir=/opt/kde3 while leaving out the --prefix command, but that didn't work. I tried a couple of other things and all I see is the celestia splash screen for about 1 second and the program exits.

Thanks.

Well for the (once for all) configuration and first execution I use some trivial little shell scripts that reside in the Sandbox directory (where celestia and Makefile are also located).

That script would be executed only once after a /complete/ rebuild of Sandbox/celestia from CVS. Remember at that point the ./configure scripts are not yet generated!

----------------cel-kde-------------------

---------------------------------------------------------
Don't forget to make that script executable (as root)

> chmod u+x cel-kde

Then you start cel-kde just by typing its name in your shell, after a 'cd Sandbox', of course.

If you want to find out where all files will be installed before actually installing them, you just 'dry-run' the install process via

make -n install

Then you can see where everything goes...

Good luck, you are almost there

Bye Fridger

Fridger,

Thanks for your continued patience and help, but I must be missing something. I thought that the whole purpose of the excerise was to be able to run celestia from its build directory. What you are suggesting seems to require me to do a "make install", presumably as root. I was hoping that I could just build celestia and run ii after compiling it with "make" and not have to do a "make install". Certainly I can do this with many other programs. I thought the problem with celestia if I did that was that it didn't know where to look for its texture files. Can what I want to do be done? Thanks.

toadatrix wrote:Fridger,

Thanks for your continued patience and help, but I must be missing something. I thought that the whole purpose of the excerise was to be able to run celestia from its build directory. What you are suggesting seems to require me to do a "make install", presumably as root. I was hoping that I could just build celestia and run ii after compiling it with "make" and not have to do a "make install". Certainly I can do this with many other programs. I thought the problem with celestia if I did that was that it didn't know where to look for its texture files. Can what I want to do be done? Thanks.

As I stated in my post above

t00fri wrote:Well for the (once for all) configuration and first execution I use some trivial little shell scripts

The script cel-kde I have described to you sets up a clean starting configuration, each time you call it:

i) It erases the old build-celestia (if it existed)
and replaces it by a (yet un-configured) 'virgin' CVS copy from Sandbox/celestia.

ii) configures the new build-celestia to default install directories. From there on, no new configuration is necessary anymore until you feel you want to restart entirely from scratch for whatever reasons!

iii) recompiles the entire source code, while normally only those files that changed after a CVS update would be recompiled via 'make'.

Note: 'make' examines the 'time stamps' on the source files and object files (*.o) . It only acts on those files that are "out-of-date"! If everything is "up-to-date", 'make' does not do anything.

After calling that 'cel-kde' script once and optionally doing a full install thereafter, you proceed from there on after each CVS update only with 'make Celestia', as we discussed previously. After recompilation ('make') you can always execute the new 'celestia' in the build-celestia directory, of course. The reason is that we configured that executable to look for its data directory in the default place, i.e. in /usr/local/share/celestia.

I thought that was obvious...

In summary:

'make Celestia' is for "every-day" CVS updating.
'cel-kde' is for restoring a fresh build-configuration, configuration of the respective source code and a /full/ compile.

Bye Fridger

Thanks, I finally understand it. Don't know why I was so dense about it before. Anyway, I really appreciate your help with this and thanks again.