What the gaugedesigner is capable of

krwright · Post by **krwright** » Sat Mar 17, 2007 9:47 pm

I was missing automake and libtool. Adding those two allowed the autogen and make...

BUT!

It didn't make any difference! Text is still under polygons.
I just ran cvs update -dP, and running autogen, make, etc. again.

Do I need to log out/in or restart for changes to take effect?

djandruczyk · Post by **djandruczyk** » Sun Mar 18, 2007 7:54 am

krwright wrote:I was missing automake and libtool. Adding those two allowed the autogen and make...

BUT!

It didn't make any difference! Text is still under polygons.
I just ran cvs update -dP, and running autogen, make, etc. again.

Do I need to log out/in or restart for changes to take effect?

Text SHOULD be on top. I verified it here, and my CVS tree is 100% up to date. the only possibility is that courceforge anonymous CVS is lagging the developer access (it happens from time to time, but is rarer these days)

I also checked webcvs (the web view) and hte code is correct there as well.

are you sure you ran "make installl" to put the new binaries in place??? If not you'd be executing the old ones, due to the fact that /opt/local/bin should be in the path before the current dir and if you ran "gaugedesigner" instead of /path/to/gaugedesigner it would choose the one in /opt/local, leading to your confusion.

krwright · Post by **krwright** » Mon Mar 19, 2007 7:14 am

I found the problem, though I don't understand the cause.
Looking at the output of the "sudo make install" run, install is putting ecerything into /usr/local/bin instead of /opt/local/bin.
Is that an environment setting or something? A parameter in the makefile?
Not really a huge issue, as I can just run it from there, but I was curious as to why that happened. Should I delete the version in /opt/local?
The version in /usr/local works as advertised, thank you.

djandruczyk · Post by **djandruczyk** » Mon Mar 19, 2007 7:22 am

krwright wrote:I found the problem, though I don't understand the cause.
Looking at the output of the "sudo make install" run, install is putting ecerything into /usr/local/bin instead of /opt/local/bin.
Is that an environment setting or something? A parameter in the makefile?
Not really a huge issue, as I can just run it from there, but I was curious as to why that happened. Should I delete the version in /opt/local?
The version in /usr/local works as advertised, thank you.

Well as per the OS-X installation howto you must have missed some details on a step:

Code: Select all

 tar xvzf megatunix-<TAB> 
 cd megatunix-<TAB> 
 ./configure --prefix=/opt/local   #<--- IMPORTANT
 make 
 sudo make install

The choice to use /opt/local on OS-X was that on my test system installing darwinports setup my path to have /opt/local/bin in there (no modification needed), whereas /usr/local/bin was NOT in my path, leading to additional steps..

In order to keep things consistent for OS-X people, I'd recommend you run "sudo make uninstall" in your current build tree to remove the stuff under /usr/local , and run "./configure --prefix=/opt/local ; sudo make install" which will reinstall on top of the old release in /opt/local

krwright · Post by **krwright** » Mon Mar 19, 2007 7:56 am

Ah!
So this "./configure --prefix=/opt/local" needs to be run each time I want to do a make and install. I did that for the initial install, but not for the CVS update.
Got it.

Worked perfectly - thank you for the aid! I really need to dig into *nix more...

djandruczyk · Post by **djandruczyk** » Mon Mar 19, 2007 8:17 am

krwright wrote:Ah!
So this "./configure --prefix=/opt/local" needs to be run each time I want to do a make and install. I did that for the initial install, but not for the CVS update.
Got it.

Worked perfectly - thank you for the aid! I really need to dig into *nix more...

Since you are using CVS (most users won't), your command is slightly different.

When you update your CVS tree to match mine (i..e if I put in a bugfix), you would run "./autogen.sh --prefix=/opt/local". As autogen.sh feeds whatever options given to it to ./configure when IT runs it.

If you run "make clean" the "prefix" you defined previous is lost and it goes back to the default.

Linux users don't need to use the --prefix=... stuff (unless they want to force it),, as nearly every linux distro has /usr/local/bin in the path. I used the above syntax for OS-X as in my case after darwinports was installed, /opt/local/bin was in the path but /usr/local/bin was NOT, hence my decision to tell megatunix to install into a location in the system wide path so as to eliminate steps that might confuse new users.

krwright · Post by **krwright** » Mon Mar 19, 2007 9:36 am

Well, dang it.
*Now* it says "Can't locate primary glade file!!!!" when I try to run guagedesigner in xterm.
Now what did I foul up?

djandruczyk · Post by **djandruczyk** » Mon Mar 19, 2007 9:48 am

krwright wrote:Well, dang it.
*Now* it says "Can't locate primary glade file!!!!" when I try to run guagedesigner in xterm.
Now what did I foul up?

OK, you still have two releases installed..
Easy fix.

open terminal
Remove all old megatunix stuff:

Code: Select all

sudo rm -rf /usr/local/bin/megatunix \
/usr/local/bin/gaugedesigner \
/usr/local/bin/dashdesigner \
/usr/local/share/MegaTunix \
/opt/local/bin/megatunix \
/opt/local/bin/gaugedesigner \
/opt/local/bin/dashdesigner \
/opt/local/share/MegaTunix

Reinstall megatunix (you have CVS)

Code: Select all

cd cvs/MegaTunix ; ./configure --prefix=/opt/local ; make ; sudo make install

This should resolve your issue.

The problem is that you had two versions of megatunix partially installed into TWO DIFFERENT places, and one set of it's config files was missing (either /opt/local/share/MegaTunix, or /usr/local/share/MegaTunix), and since the path is hardcoded into the executable during build it complained when you tried to run it and it couldn't find it's needed files.

Running the above commands to clean out ALL of the existing megatunix files and reinstalling it cleanly should clear up all your issues.

krwright · Post by **krwright** » Mon Mar 19, 2007 12:28 pm

Nope no good. Deleted all, installed from CVS - same error.
Did a fresh install from the 0.9.10 tarball, and that works fine.

Installing the CVS version over the working one kills it.
Reinstalling from the tarball over the dead one fixes it.

I may have fouled-up CVS data. I'll try an update, or delete the CVS folder and start over when I get home this evening.

djandruczyk · Post by **djandruczyk** » Mon Mar 19, 2007 12:36 pm

krwright wrote:Nope no good. Deleted all, installed from CVS - same error.
Did a fresh install from the 0.9.10 tarball, and that works fine.

Installing the CVS version over the working one kills it.
Reinstalling from the tarball over the dead one fixes it.

I may have fouled-up CVS data. I'll try an update, or delete the CVS folder and start over when I get home this evening.

That error means that the files megatunix needs are are NOT in a place where they can be found. It may happen if you have a certain version of automake (2.59, vs 2.6x)

Make sure autoconf and automake is current on your system, as autogen.sh RECREATES the "./configure" script and if your autoconf/automake is out of date it can break things.

krwright · Post by **krwright** » Mon Mar 19, 2007 1:49 pm

djandruczyk wrote: That error means that the files megatunix needs are are NOT in a place where they can be found. It may happen if you have a certain version of automake (2.59, vs 2.6x)

Make sure autoconf and automake is current on your system, as autogen.sh RECREATES the "./configure" script and if your autoconf/automake is out of date it can break things.

I have autoconf 2.61 and automake 1.10, same as yours. Updated them via port several days ago.
It all worked fine when the CVS updated version was being installed in /usr/lib/, it was just in the wrong place.

I finally figured out how to tweak X11's PATH - it doesn't look at .profile, it looks at .bashrc. All you have to do is put a "source ~/.profile" in .basrc. Maybe I should just let everything install there and add the directories to the path.

krwright · Post by **krwright** » Tue Mar 20, 2007 7:33 am

OK, I finally got it.
I cleaned out all the old MegaTunix stuff, did a clean install of 0.9.10 (worked), then deleted all the CVS stuff and did the CVS setup from scratch. Ran into the "PKG_CHECK_MODULES" error again, so I uninstalled and reinstalled (via Darwinports) a lot of stuff: automake, autoconf, gtk2, gtkglext, libglade, libtool, xft2, and pkgconfig. The error turned out to be caused by pkgconfig. A little Googling turned that up after I had don all the others.
The text is definitely above the polygons now.

I should be good to go from here. Thanks for all the assistance to the *nix n00b.