plib-users

[Plib-users] Compiling the UL

[John R A. <jra...@at...>]

Hey, new to this list so i don't know how much activity occurs.  Hope there
is somebody out there that can help me.

Just got the PLIB today, compiled just the Utility Library because all I
need (currently) is the platform independent ulClock class.  Compiled the
UL, produced two header files and the library in the root dir of the
libraries folder (using .NET on Win32, btw).

So then I include "ul.h" somewhere in my project and put a ulClock class in
one of my own classes.  Compiles fine, except for a linker error in the
ulClock class.  It can't seem to find an implementation of timeGetTime()
(which is referenced in ulClock::getRawTime).

This is strange because timeGetTime is defined in mmsystem.h

Since I belive my system uses the performance timers, it's not a big deal
because I can just comment that line out and return 0.0 (yeah, I know it's a
hack, that's why I'm asking how to fix it).  Since my system will use
performance timers it will never get to my hack.

Anybody have any ideas / suggestions / comments?  Thanks for the library
whoever wrote it, re-inventing the wheel is tiring.

-crombie

Re: [Plib-users] How to determine surface material by ssgState texture filena me ?

[Steve B. <sjb...@ai...>]

McEvoy, Nick wrote:
> What is the best way to determine what type of 'surface' is under my players feet ?
> 
> My setup is follows:
> - I load a terrain (an AC3D model) with different textures, eg. grass, rock, ice.
> - I get the hits:   iNumHits = ssgIsect(reGetWorld(), &Sphere, InvMat, pHits)
> - I get the SimpleState of the hit leaf, eg.
> 
> ssgHit* h = &pHits[i];
> ssgState* pState = h->leaf->getState();
> if (pState->isA(ssgTypeSimpleState()))
> {
> 	char* sTexture = ((ssgSimpleState*)pState)->getTextureFilename();
> 
> 	// then depending on texture filename set different surface properties
> 	// - this would be a bunch of strcmp() ... too slow !!!
> }
> 
> But doing a bunch of string compares on the texture filename is going to be slow ... is it not !?
> 
> Is there a better way to do this ?

There is a user-settable integer field in the ssgState:

   void ssgState::setExternalPropertyIndex(int i)
   int  ssgState::getExternalPropertyIndex()

...you can use that to index into an array of external properties that 
you maintain.  In my games, I store properties like friction, 
bounciness, etc in a structure and make a ulList of those.

> Note: I had a quick look at the way TuxKart does it ... with a Material structure (ie. ssgState) ... but I don't quite follow how to apply these states when reading the AC3D model.
> 
> I have the vague idea that I should load the AC3D model using ssgLoaderOptions ... to handle ssgState ... and as each texture is read create my own ssgState (which I can then get in the hit leaf) ... but I'm still trying to work out how the loader options are supposed to work ... or am I barking up the wrong tree here.

The loader options allow you to have the file loader call your code 
whenever it wants to create a new ssgState - to give you the 
possibility to create your own ssgState instead of the loader doing
it for you.

That's one way to set the External Property Index - I also use it to
add features to the ssgState that the loader can't.  For example, AC3D
doesn't support non-repeating textures - so I look up the texture 
filename in my master materials table and set the 'wrap' flags myself.

This entire process is poorly documented right now - I kinda had the
idea that one day I'd wrap up a material file parser along with all
of this mechanism into an ssgAux thingy - but I havn't gotten around
to doing that yet.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

[Plib-users] RE: How to determine surface material by ssgState texture fi lename ?

[McEvoy, N. <nic...@ds...>]

Sorry I'm answering my own question ...

I think I now understand what TuxKart is doing (in Material.cxx).

The idea is:
- use ssgSetAppStateCallback() to register that you want to create your own ssgStates when the model is loaded.  So depending on the texture filename I create my own state (similar to TuxKart Material.h/cxx).

Then this is what I can get to in the ssgHit->leaf->getState() thus having a simple integer flag to tell me the material type (instead of having to do a strcmp on the filename).

Just brilliant !!!  :)

Sorry to trouble you all ... :)

Nick

[Plib-users] How to determine surface material by ssgState texture filena me ?

[McEvoy, N. <nic...@ds...>]

What is the best way to determine what type of 'surface' is under my players feet ?

My setup is follows:
- I load a terrain (an AC3D model) with different textures, eg. grass, rock, ice.
- I get the hits:   iNumHits = ssgIsect(reGetWorld(), &Sphere, InvMat, pHits)
- I get the SimpleState of the hit leaf, eg.

ssgHit* h = &pHits[i];
ssgState* pState = h->leaf->getState();
if (pState->isA(ssgTypeSimpleState()))
{
	char* sTexture = ((ssgSimpleState*)pState)->getTextureFilename();

	// then depending on texture filename set different surface properties
	// - this would be a bunch of strcmp() ... too slow !!!
}

But doing a bunch of string compares on the texture filename is going to be slow ... is it not !?

Is there a better way to do this ?

Note: I had a quick look at the way TuxKart does it ... with a Material structure (ie. ssgState) ... but I don't quite follow how to apply these states when reading the AC3D model.

I have the vague idea that I should load the AC3D model using ssgLoaderOptions ... to handle ssgState ... and as each texture is read create my own ssgState (which I can then get in the hit leaf) ... but I'm still trying to work out how the loader options are supposed to work ... or am I barking up the wrong tree here.

Sorry if I sound a bit confused ... cause I am !  :)

Any suggestions ?

Nick

Re: [Plib-users] Water waves

[Steve B. <sjb...@ai...>]

Alf Inge Iversen wrote:
> I am currently evaluating different APIs for 3D graphics, and have found 
> PLIB very interesting. One of the interesting features is its ability to 
> generate water waves.
> 
> The wave functionality is though a bit simple, and I wonder if someone in 
> the PLIB project is working on methods to generate circular or curved 
> waves, to simulate waves caused by an object dropped into the water.

I have definite plans to do that (and also to deal with the V-shaped
'wake' left by an object being dragged through the water) - the idea
would be to have new 'wave train' objects derived from the basic
wave train class - containing different 'update' methods.

The water model also needs it's own intersection test routines...the
present ones that it inherits from the vertex table class are
hopelessly inefficient.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

[Plib-users] Water waves

[Alf I. I. <al...@au...>]

I am currently evaluating different APIs for 3D graphics, and have found 
PLIB very interesting. One of the interesting features is its ability to 
generate water waves.

The wave functionality is though a bit simple, and I wonder if someone in 
the PLIB project is working on methods to generate circular or curved 
waves, to simulate waves caused by an object dropped into the water.

Regards,
Alf Inge Iversen

Re: [Plib-users] ssgTexture

[Mat D. <mdd...@en...>]

nope, none.

m.

On Tuesday, November 26, 2002, at 08:24 PM, Curtis L. Olson wrote:

> Does plib produce any complaints when you load the texture?
>
> Curt.
>
>
> Mat Davidson writes:
>> Im having some trouble with ssgTexture and Im not sure what is
>> happening. Here is my code:
>>
>>
>> ssgSimpleState *faceState[6];
>> ssgTexture *tex;
>>
>> for( i=0 ; i<5 ; i++ )
>> {
>> 	faceState[i] = new ssgSimpleState;
>> 		/*
>> 	bmpImageLoad( gDataManager->facePath[i], &width, &height, &texBytes 
>> );
>> 	tex = new ssgTexture ( gDataManager->facePath[i], texBytes, width,
>> height, 0 );
>> 		*/
>> 	tex = new ssgTexture( gDataManager->facePath[i] );
>>
>> 	faceStates[i]-> setTexture( tex );
>> }
>>
>>
>> As you can see, Ive tried both my own loader code and ssgTexture() to
>> load the image.  Once the calls are made I make an ssgVTable, set its
>> state and params, give it to an ssgTransform, and then add it to my
>> sceneRoot.  The final product of this labor is a white square with no
>> texture.  Is there any kind of advice anyone can give me about how I
>> should deal with this, places to look, etc?
>>
>> mat.
>>
>> Im having some trouble with ssgTexture and Im not sure what is
>> happening. Here is my code:
>>
>>
>> ssgSimpleState *faceState[6];
>> ssgTexture *tex;
>>
>> for( i=0 ; i<5 ; i++ )
>> {
>> 	faceState[i] = new ssgSimpleState;
>> 		/*
>> 	bmpImageLoad( gDataManager->facePath[i], &width, &height,
>> 	&texBytes );
>> 	tex = new ssgTexture ( gDataManager->facePath[i], texBytes,
>> width, height, 0 );
>> 		*/
>> 	tex = new ssgTexture( gDataManager->facePath[i] );
>>
>> 	faceStates[i]-> setTexture( tex );
>> }
>>
>>
>> As you can see, Ive tried both my own loader code and ssgTexture() to
>> load the image.  Once the calls are made I make an ssgVTable, set its
>> state and params, give it to an ssgTransform, and then add it to my
>> sceneRoot.  The final product of this labor is a white square with no
>> texture.  Is there any kind of advice anyone can give me about how I
>> should deal with this, places to look, etc?
>>
>> mat.
>>
>
> -- 
> Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
> Twin Cities    cu...@me...                  cu...@fl...
> Minnesota      http://www.menet.umn.edu/~curt   
> http://www.flightgear.org
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] ssgTexture

[Curtis L. O. <cu...@me...>]

Does plib produce any complaints when you load the texture?

Curt.


Mat Davidson writes:
> Im having some trouble with ssgTexture and Im not sure what is 
> happening. Here is my code:
> 
> 
> ssgSimpleState *faceState[6];
> ssgTexture *tex;
> 
> for( i=0 ; i<5 ; i++ )
> {
> 	faceState[i] = new ssgSimpleState;
> 		/*
> 	bmpImageLoad( gDataManager->facePath[i], &width, &height, &texBytes );
> 	tex = new ssgTexture ( gDataManager->facePath[i], texBytes, width, 
> height, 0 );
> 		*/
> 	tex = new ssgTexture( gDataManager->facePath[i] );
> 
> 	faceStates[i]-> setTexture( tex );
> }
> 
> 
> As you can see, Ive tried both my own loader code and ssgTexture() to 
> load the image.  Once the calls are made I make an ssgVTable, set its 
> state and params, give it to an ssgTransform, and then add it to my 
> sceneRoot.  The final product of this labor is a white square with no 
> texture.  Is there any kind of advice anyone can give me about how I 
> should deal with this, places to look, etc?
> 
> mat.
> 
> Im having some trouble with ssgTexture and Im not sure what is
> happening. Here is my code:
> 
> 
> ssgSimpleState *faceState[6];
> ssgTexture *tex;
> 
> for( i=0 ; i<5 ; i++ )
> {
> 	faceState[i] = new ssgSimpleState;
> 		/*
> 	bmpImageLoad( gDataManager->facePath[i], &width, &height,
> 	&texBytes );
> 	tex = new ssgTexture ( gDataManager->facePath[i], texBytes,
> width, height, 0 );
> 		*/
> 	tex = new ssgTexture( gDataManager->facePath[i] );
> 
> 	faceStates[i]-> setTexture( tex );
> }
> 
> 
> As you can see, Ive tried both my own loader code and ssgTexture() to
> load the image.  Once the calls are made I make an ssgVTable, set its
> state and params, give it to an ssgTransform, and then add it to my
> sceneRoot.  The final product of this labor is a white square with no
> texture.  Is there any kind of advice anyone can give me about how I
> should deal with this, places to look, etc?
> 
> mat.
> 

-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-users] ssgTexture

[Mat D. <mdd...@en...>]

Im having some trouble with ssgTexture and Im not sure what is 
happening. Here is my code:


ssgSimpleState *faceState[6];
ssgTexture *tex;

for( i=0 ; i<5 ; i++ )
{
	faceState[i] = new ssgSimpleState;
		/*
	bmpImageLoad( gDataManager->facePath[i], &width, &height, &texBytes );
	tex = new ssgTexture ( gDataManager->facePath[i], texBytes, width, 
height, 0 );
		*/
	tex = new ssgTexture( gDataManager->facePath[i] );

	faceStates[i]-> setTexture( tex );
}


As you can see, Ive tried both my own loader code and ssgTexture() to 
load the image.  Once the calls are made I make an ssgVTable, set its 
state and params, give it to an ssgTransform, and then add it to my 
sceneRoot.  The final product of this labor is a white square with no 
texture.  Is there any kind of advice anyone can give me about how I 
should deal with this, places to look, etc?

mat.

New: [Plib-users] transparency

[SilvioCVdeAlmeida <scv...@gr...>]

Hello,

Regarding transparency handling, not strictly with PLIB:

There are cases when you absolutely need to sort elements
back-to-front, or you get a very distorced transparency
effect.

And worst, forget ssgLeaf, it looks like you have to
sort it on a per-face basis. Not to say on a per-vertex
basis, for degenerated cases like intercepting faces...

Is there a nice way to back-to-front sort with PLIB, with
the detail demanded by robust transparencing?

Thanks

____________________________________________________
SilvioCVdeAlmeida 2002.11.22
scv...@gr...

R: [Plib-users] transparency

[Paolo L. <p.l...@ci...>]

Mat Davidson wrote:

> Ive tried every-which-way to use loader code to get textures into my
> project and its just not happening.  What I really need is a way to get
> textures into my project through plib that have alpha channels.  Is
> there a way to do this in plib?

Once loaded a .rgb or .rgba texture with alpha channel in a state, this code
works for me:

void enable_transparency( ssgLeaf *node )
{
	ssgSimpleState *state = (ssgSimpleState *)node->getState();
	state->enable( GL_BLEND );
	state->setTranslucent();
}

For simple blending function I also set:

	state->disable( GL_ALPHA_TEST );

Greetings -

Paolo Leoncini

-------------------------------------------------------------------------
Paolo Leoncini						phone:  +39 (0823) 623134
Visualization & Virtual Reality			fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches	mailto:p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		http://www.cira.it>

Re: [Plib-users] transparency

[Norman V. <nh...@ca...>]

Mat Davidson writes:
> 
> Ive tried every-which-way to use loader code to get textures into my 
> project and its just not happening.  What I really need is a way to get 
> textures into my project through plib that have alpha channels.  Is 
> there a way to do this in plib?  all I can load now are bmp and rgb 
> files.  "rpg" files are a total pain, I don't have a decent way to edit 
> or create them (photoshop7 doesn't handle them).  Any ideas?

sure
http://www.google.com/search?sourceid=navclient&q=photoshop+%2Ergb+plugin

I know this one works
http://romka.demonews.com/graphics/tools/index_eng.htm

[Plib-users] transparency

[Mat D. <mdd...@en...>]

Hey guys-

Ive tried every-which-way to use loader code to get textures into my 
project and its just not happening.  What I really need is a way to get 
textures into my project through plib that have alpha channels.  Is 
there a way to do this in plib?  all I can load now are bmp and rgb 
files.  "rpg" files are a total pain, I don't have a decent way to edit 
or create them (photoshop7 doesn't handle them).  Any ideas?

m.

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Sebastian Ude wrote:
> 
> On Tue, 19 Nov 2002, cho...@at... (C. Hotchkiss) wrote:
> ...
>>Did that and got an interesting, but different result. Patching goes 
>>smoothly. But, when I then run ./configure, it gets to:
>>   ...
>>   checking for ulInit in -lplibul... no
>>   configure: error: there seems to be a problem with the PLIB libraries.
> 
> 
> Could you send me the content of the 'config.log' file that should have
> been created in the plib_examples-1.6.1 directory during the failed
> configure run ?
> 
The problem cleared up when I did a make/clean on my PLIB library. 
Thought I had earlier, but evidently not since the compiler last 
upgraded. A minor embarrassment.

Make on the examples didn't complete. I died on a problem with water.cxx 
that is, Norman tells me, a known problem. So, later today I'll apply 
the patch that excludes water and proceed.

Regards,

Charlie H.

-- 
"You're not drunk if you can lie on the floor without holding on."
                      ---Dean Martin

Re: [Plib-users] Example config problem

[Sebastian U. <ud...@ha...>]

On Tue, 19 Nov 2002, cho...@at... (C. Hotchkiss) wrote:
> Date: Tue, 19 Nov 2002 15:32:04 -0800
> To: pli...@li...
> From: cho...@at... (C. Hotchkiss)
> Reply-To: pli...@li...
> Subject: Re: [Plib-users] Example config problem

[...]

> > All I can recommend (again) is that you apply the patch I created for
> > you over a *clean* plib_examples-1.6.1 tree and try to run ./configure
> > afterwards. Doing so should at least allow you to compile the example
> > programs for now, independently of your autoconf problem.
>
> Did that and got an interesting, but different result. Patching goes 
> smoothly. But, when I then run ./configure, it gets to:
>    ...
>    checking for ulInit in -lplibul... no
>    configure: error: there seems to be a problem with the PLIB libraries.

Could you send me the content of the 'config.log' file that should have
been created in the plib_examples-1.6.1 directory during the failed
configure run ?


- Sebastian

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Norman Vine wrote:
>...
> 
> Something is definately hosed with your installation in that
> after adding the AC_PREREQ(2.13)  autom4te.cfg shouldn't
> even be needed never mind causing an error as this was introduced
> with automake 1.5 and autoconf 2.13 should be calling automake 1.4
> 
Hmm. That suggests an experiment. Might try renaming the development 
version to see if it is getting called even though it shouldn't.

> FYI automake 1.5 is the future but it is INCOMPATABLE with
> earlier versions and has been causing lots of grief 

As I read it the version I have is 1.7.1-1 (devel) and 1.4p5-5 (stable) 
and the compiler is 3.2-3.

> 
> If you want you can send me < NOT the list > the output of 
> 
> cygcheck -s -v -r
> and
> mount
> 
> and I 'might' be able to spot the problem

I am attaching the results of piping the commands as you requested into 
  text files. Besides giving the versions above it shows nothing about 
plib. Is that because plib is not part of the distribution of cygwin?

Just finished with doing ./config on a clean example directory and the 
patch applied after doing a make clean/make/make install on plib. This 
allowed ./configure to run to completion. I just started a make on the 
examples and that is running fine.

Doesn't necessarily fix the autoconf issue, but it is a very welcome 
state to be in.

Regards,

Charlie H.
-- 
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Example config problem

[Norman V. <nh...@ca...>]

C. Hotchkiss writes:
> > > > 
> > All I can recommend (again) is that you apply the patch I created for you
> > over a *clean* plib_examples-1.6.1 tree and try to run ./configure
> > afterwards. Doing so should at least allow you to compile the example
> > programs for now, independently of your autoconf problem.
> > 
> 
> Did that and got an interesting, but different result. Patching goes 
> smoothly. But, when I then run ./configure, it gets to:
>    ...
>    checking for ulInit in -lplibul... no
>    configure: error: there seems to be a problem with the PLIB libraries.
> 
> I downloaded the stable version (1.6.0) and it builds and installs 
> without a hint of trouble using the steps specified in the installation 
> instructions.

Charlie

Did you upgrade your compiler ?

If so you are using gcc 3.2 which is incompatable with 
gcc 2.95 libraries.

Two ways around this

1) remake PLIB with the new compiler
%  cd PLIB
% make clean
% make
% make install

and try again

2) use this configure command
% cd PLIB_EXAMPLES
% CC=c++-2 CXX=c++-2 ./configure
% make clean
% make

HTH

< I would do (1) and move up to gcc 3.2 >

Norman

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Sebastian Ude wrote:
> ...
>>
>>Suggestions? Sebastian?
> 
> 
> I'm afraid no, especially since I don't have access to a cygwin environment
> at the moment.
> 
> All I can recommend (again) is that you apply the patch I created for you
> over a *clean* plib_examples-1.6.1 tree and try to run ./configure
> afterwards. Doing so should at least allow you to compile the example
> programs for now, independently of your autoconf problem.
> 

Did that and got an interesting, but different result. Patching goes 
smoothly. But, when I then run ./configure, it gets to:
   ...
   checking for ulInit in -lplibul... no
   configure: error: there seems to be a problem with the PLIB libraries.

I downloaded the stable version (1.6.0) and it builds and installs 
without a hint of trouble using the steps specified in the installation 
instructions.

At this point I seem to have autoconf looking in the wrong place for 
autom4te.cfg and the ./configure for the examples doesn't like the PLIB 
installation.

It is beginning to look as though I need to do a clean Cygwin install 
and build it all from scratch. Then again, that might just be the 
problem - my installation is clean from 1.6.0 and hasn't inherited 
debris left over from earlier installations.

Regards,

Charlie H.

-- 
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Example config problem

[Norman V. <nh...@ca...>]

C. Hotchkiss writes:
> 
> Norman Vine wrote:
>> > 
> > This sounds as if you are missing something required for 
> > the 'devel' version of autoconf or perhaps a 'perl' problem
> > 
> > as a work around ..
> > try adding the AC_PREREQ(2.13) line as below to your configure.in file
> > and then rerun 
> > 
> > aclocal
> > automake -a
> > autoconf
> > ./configure
> 
> No change in effect. autoconf still complains about autom4te.cfg being 
> missing at line 428.
> 
> It puzzles me that I can build plib without a hitch and the examples 
> dies on this. Shall I scrape off cygwin and then clean install it, Plib 
> and then the examples?
> 
> I only hope this improves things for anyone taking an interest in using 
> both Plib and Cygwin.

Something is definately hosed with your installation in that
after adding the AC_PREREQ(2.13)  autom4te.cfg shouldn't
even be needed never mind causing an error as this was introduced
with automake 1.5 and autoconf 2.13 should be calling automake 1.4

FYI automake 1.5 is the future but it is INCOMPATABLE with
earlier versions and has been causing lots of grief 

If you want you can send me < NOT the list > the output of 

cygcheck -s -v -r
and
mount

and I 'might' be able to spot the problem

On the other hand if you are on a FAST pipe and don't have a lot
of 'locally generated' Cygwin files you could just delete your 
Cygwin tree and start over with the latest

Norman

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Norman Vine wrote:
>...
> Hmm...
> 
> This sounds as if you are missing something required for 
> the 'devel' version of autoconf or perhaps a 'perl' problem
> 
> as a work around ..
> try adding the AC_PREREQ(2.13) line as below to your configure.in file
> and then rerun 
> 
> aclocal
> automake -a
> autoconf
> ./configure

No change in effect. autoconf still complains about autom4te.cfg being 
missing at line 428.

It puzzles me that I can build plib without a hitch and the examples 
dies on this. Shall I scrape off cygwin and then clean install it, Plib 
and then the examples?

I only hope this improves things for anyone taking an interest in using 
both Plib and Cygwin.

Regards,

Charlie H.
-- 
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Example config problem

[Sebastian U. <ud...@ha...>]

On Tue, 19 Nov 2002, cho...@at... (C. Hotchkiss) wrote:
> Date: Tue, 19 Nov 2002 10:53:45 -0800
> To: pli...@li...
> From: cho...@at... (C. Hotchkiss)
> Reply-To: pli...@li...
> Subject: Re: [Plib-users] Example config problem

[...]

> BTW, I tried re-running cygwin's setup, but nothing showed as missing or
> needing update. All files were either "keep" or "skip".
>
> Suggestions? Sebastian?

I'm afraid no, especially since I don't have access to a cygwin environment
at the moment.

All I can recommend (again) is that you apply the patch I created for you
over a *clean* plib_examples-1.6.1 tree and try to run ./configure
afterwards. Doing so should at least allow you to compile the example
programs for now, independently of your autoconf problem.


- Sebastian

Re: [Plib-users] Example config problem

[Norman V. <nh...@ca...>]

C. Hotchkiss writes:
> 
> Norman Vine wrote:
>  > ... I downloaded the examples tarball and did a
>  >
>  > aclocal automake -a autoconf ./configure make
>  >
>  > and things compiled < except for a problem with multi-texture calls >
>  >
> 
> I'm wondering if the problem is a cygwin setup or config issue.
> 
> Not being too sure of what state my plib examples directory was in after 
> all the attempts to fix the problem I blew it away and did a clean 
> install of the examples tar ball. Then I followed your sequence.
> 
> As before, the incantations supplied recreate the previously missing 
> files were generated (as expected), but again autoconf dies complaining 
> that autom4te.cfg or its directory is missing.

Hmm...

This sounds as if you are missing something required for 
the 'devel' version of autoconf or perhaps a 'perl' problem

as a work around ..
try adding the AC_PREREQ(2.13) line as below to your configure.in file
and then rerun 

aclocal
automake -a
autoconf
./configure

==== cut ====
dnl Process this file with autoconf to produce a configure script.

AC_INIT(src/js/js_demo.cxx)
AM_INIT_AUTOMAKE(plib_examples, 1.6.1)

AC_PREREQ(2.13)

.......

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Norman Vine wrote:
 > ... I downloaded the examples tarball and did a
 >
 > aclocal automake -a autoconf ./configure make
 >
 > and things compiled < except for a problem with multi-texture calls >
 >
 >
 > So it does work with a current Cygwin Installation and with BOTH the
 > devel and and stable versions of autoconf without any user
 > intervention !!!
 >

Norm,

I'm wondering if the problem is a cygwin setup or config issue.

Not being too sure of what state my plib examples directory was in after 
all the attempts to fix the problem I blew it away and did a clean 
install of the examples tar ball. Then I followed your sequence.

As before, the incantations supplied recreate the previously missing 
files were generated (as expected), but again autoconf dies complaining 
that autom4te.cfg or its directory is missing.

Looking around, I found there is a directory 
"/user/local/share/autoconf", but no cfgfile is there. Further searching 
   found a file named autom4te.cfg in the directory path 
/usr/autotool/devel/share/autoconf. Am I supposed to copy that into 
/user/local/share/autconf? The path suggests that it would not be 
searched by default.

BTW, I tried re-running cygwin's setup, but nothing showed as missing or
needing update. All files were either "keep" or "skip".

Suggestions? Sebastian?

Charlie H.
-- 
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Example config problem

[Norman V. <nh...@ca...>]

Sebastian Ude writes:
> 
> 
> On Mon, 18 Nov 2002, cho...@at... (C. Hotchkiss) wrote:
> >  >...
> > > Hmm ... fix your Cygwin :)
> >
> > Did that.  When updating cygwin I noticed that autoconf exists in both
> > stable and devel versions. I went ahead and let it install both. Now I'm
> > not so sure that was a good idea. It doesn't strike me that you are
> > using the development version of autoconf. Anyhow, should I edit the
> > file tree to move stable autoconf stuff where it apparently is expected?
> 
> I do not have much experience with Cygwin - just make sure that you have
> only ONE autoconf version installed.

Cygwin has a mechanism for dealing with a devel and a stable version
of the autotools.  This is normally transparent to the user

FWIW - either work for PLIB


> So even though the immediate issue that prevents you from building the
> examples is your broken autoconf version - 

NO 

If Charlie used the Cygwin setup program to get BOTH the
Devel and the Stable version of the gnu autotools then his
autoconf is NOT broken 

I downloaded the examples tarball and did a

aclocal
automake -a
autoconf
./configure
make

and things compiled 
< except for a problem with multi-texture calls >

So it does work with a current Cygwin Installation and
with BOTH the devel and and stable versions of autoconf
without any user intervention !!!

I haven't tried the autoconf patch

Norman

Re: [Plib-users] Example config problem

[Sebastian U. <ud...@ha...>]

On Mon, 18 Nov 2002, cho...@at... (C. Hotchkiss) wrote:
> Date: Mon, 18 Nov 2002 22:57:23 -0800
> To: pli...@li...
> From: cho...@at... (C. Hotchkiss)
> Reply-To: pli...@li...
> Subject: Re: [Plib-users] Example config problem
>
> Sebastian,
>
>  >...
> > Hmm ... fix your Cygwin :)
>
> Did that.  When updating cygwin I noticed that autoconf exists in both
> stable and devel versions. I went ahead and let it install both. Now I'm
> not so sure that was a good idea. It doesn't strike me that you are
> using the development version of autoconf. Anyhow, should I edit the
> file tree to move stable autoconf stuff where it apparently is expected?

I do not have much experience with Cygwin - just make sure that you have
only ONE autoconf version installed.


> Also. At this point I retried your original command sequence and
> autoconf still coughs a hairball about the missing .cfg file. Ditto make.
>
> > and in the meantime, get this patch that I just
> > created which adds the missing files:
> >
> > http://www.ude.handshake.de/plib_examples-1.6.1-autoconf.patch.gz
>
> Not succeeding with getting results from updating cygwin I put the patch
> file in the directory "/home/plib_examples-1.6.1", which is where the
> examples were unpacked. Was that the wrong location? Would you like
> another? BTW, you didn't say where to save the patch file.

.. because it does not matter.


> > To apply, cd into a vanilla plib_examples-1.6.1 directory and type:
> >
> > gzip -cd /path/to/plib_examples-1.6.1-autoconf.patch.gz | patch -p1
>
> Didn't work. In /home/plib_examples-1.6.1 I entered
>
> gzip -cd /home/plib_examples-1.6.1-autoconf.patch.gz | patch -p1

Didn't you just say that you put the patch into the directory
/home/plib_examples-1.6.1 ?

So I guess you should better have typed:

gzip -cd /home/plib_examples-1.6.1/plib_examples-1.6.1-autoconf.patch.gz\
| patch -p1


> patch complained that it cannot find the file to patch. It then prompts
> for the file. This repeats for several make files that I know
> ../configure did create (they show up on directory checks.) Is this patch
> looking for the original example tar ball?

Excactly. As I said, cd into a vanilla (i.e. "virgin") plib_examples-1.6.1
tree and apply the patch as described before.

If you still experience problems with a fresh source tree, just shoot me
another mail.


> I hope this continues to be at least a mildly interesting challenge for
> you as I hate exercising people on simple problems.

No - it is our fault that the plib_examples-1.6.1 release is broken and
that we have not yet published a bugfix release, so we are more than happy
to assist you in getting the examples to compile.


> It is an education for me in the assumptions that plib developers made in
> setting up the examples.

I see - but what assumptions are you referring to ?

Perhaps I should have told you that if the examples release would not be
broken, there would not be any dependency on a particular autoconf version
- actually, you would not need autoconf at all to compile the package.

But actually, as you recognized, the tarball is missing some files that
can, however, easily be re-created, provided that you have a sane autoconf
setup.

So even though the immediate issue that prevents you from building the
examples is your broken autoconf version - which I strongly recommend you
to fix -, the actual *root* of the problem is the fact that we made up a
broken tarball.


To Steve:

Back some time ago I sent you a couple of e-mails explaining why the
configure helper scripts did not make it into the release tarball (no, the
root of all evil was not my change to the top-level Makefile.am you were
referring to ...) and showing possible ways to solve the problem. However,
I have not (feel free to correct me in case I am wrong) got a reply from
you yet.

I realize that you may have been busy with work - so I was, aside from the
fact that I was away from my computer for a couple of weeks lately, but as
you see it is really annoying for users to fiddle around with the missing
files problem. Thus, I am forwarding you again my mail from Sep 12; it
would be nice of you could take a stand on the issue.


Thanks in advance,

- Sebastian


Date: Thu, 12 Sep 2002 02:16:17 +0200
From: Sebastian Ude <ud...@ha...>
To: pli...@li...
Subject: Re: [Plib-users] The examples
Reply-To: ud...@ha...
In-Reply-To: <3D7...@ai...>
References: <3D7...@ai...>
X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit



On Wed, 11 Sep 2002, sjb...@ai... (Steve Baker) wrote:
> Date: Wed, 11 Sep 2002 18:36:00 -0500
> To: pli...@li...
> From: sjb...@ai... (Steve Baker)
> Reply-To: pli...@li...
> Subject: Re: [Plib-users] The examples
>
> Sebastian Ude wrote:
>
> > Again - argh ! From the automake manual:
>
> Well, on the theory of "Go With What Works" - and "Don't F**k With What
> You Don't Understand"...perhaps you'd be so kind as to put the
> Makefile.am's back to where they work - then I'll do another quick
> Examples/Demo's release.
>
> We can figure out what's really wrong later - but it's important that
> everyone can download working examples/demos.
>
> Thanks!

I am sorry Steve, but you can't blame the missing configure helper scripts
on me, and what you suggest does NOT solve the problem.

Look - mkinstalldirs, config.sub, config.guess and install.sh are not
listed the top-level Makefile.am; and not because I removed them, but
because they have never been in there (check the CVS archive, if you want)
!

So how did the files make into the plib-1.6.0.tar.gz tarball, then ? The
answer is simple: Because autoconf has always _automatically_ added these
files to the distribution. I verified it, it really does.

If the files were not added to the distribution, the reason for that was
that they were not in the directory prior to the 'make dist' ! In this
case, it does not help AT ALL to (re-)add anything to Makefile.am; the
build system just can't add a non-existing file to the distribution.


The question we need to ask is why the files were missing in the "examples"
directory, and the answer is that autoconf does NOT install the
'mkinstalldirs', 'missing', 'install-sh', 'config.sub', 'config.guess' in
the current directory if it finds them in '..'.

Try it - take a fresh PLIB CVS tree, run ./autogen.sh from the top-level
plib directory. autoconf will install the configure helper scripts to the
top-level plib dir.

Now, cd to 'examples' and run ./autogen.sh from there as well. autoconf
finds the helper scripts in '..' and does NOT install them to the
'examples' directory again.


As you see, everything works as long as you keep the directory hirarchie -
but if you distribute the 'examples' directory seperately, the example's
configure script won't find its helper scripts in '..' as it expected ->
BUMMER !

That's just the behaviour of autoconf. As you can see, the problem has
*nothing* to do with me removing the helper scripts from the examples
Makefile.am file, which I think was a good move by the way, because it is
just unnecessary to list them there.

Again - re-adding them would not help a single bit, because the problem is
not that the build system does not know about the scripts, but that the
build-system can't add non-existing files to the distribution.


Perhaps you'd be so kind as to do a bit of research in the future prior to
blaming me for problems that I am not responsible for.

Thanks.


The solution of the problem is - if it is not obvious - either to remove
the scripts from the top-level plib directory prior to excecuting
'autogen.sh' from the examples directory in order to make the distribution,
or to move the 'examples' dir out of the plib source tree. In both cases,
'autoconf' won't find the helper scripts in '..', which is what we want to
achieve.


- Sebastian