mesa3d-dev

[Mesa3d-dev] back to autoconf 2.13

[Sven M. H. <pe...@gm...>]

Greetings,

I have rearranged the configure.in to work with autoconf v2.13 again.
Unfortunately it is now no longer possible to use configure to compile a Mesa
with missing GLUT and/or demo source directories. However, one might consider
making those seperate packages, thus giving them their own configure script...
But that's another story.

Anyways, my first show at building died with cpp unable to find
GL/include/glcore.h, included from glheader.h. I have not been able to find
that file anywhere, however my old locate db indicated it used to reside
in the Mesa src/ dir. Am I missing something or is this a bug?


Regards,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] back to autoconf 2.13

[Keith W. <ke...@va...>]

"Sven M. Hallberg" wrote:
> 
> Greetings,
> 
> I have rearranged the configure.in to work with autoconf v2.13 again.
> Unfortunately it is now no longer possible to use configure to compile a Mesa
> with missing GLUT and/or demo source directories. However, one might consider
> making those seperate packages, thus giving them their own configure script...
> But that's another story.
> 
> Anyways, my first show at building died with cpp unable to find
> GL/include/glcore.h, included from glheader.h. I have not been able to find
> that file anywhere, however my old locate db indicated it used to reside
> in the Mesa src/ dir. Am I missing something or is this a bug?
> 
> Regards,
> Sven

You  probably need to do a 'cvs update -d' as it's in a new directory.

Keith

Re: [Mesa3d-dev] back to autoconf 2.13

[Brian P. <br...@va...>]

"Sven M. Hallberg" wrote:
> 
> Greetings,
> 
> I have rearranged the configure.in to work with autoconf v2.13 again.
> Unfortunately it is now no longer possible to use configure to compile a Mesa
> with missing GLUT and/or demo source directories. However, one might consider
> making those seperate packages, thus giving them their own configure script...
> But that's another story.

As sophisticated as autoconf is, I'm surprised that you can't
detect whether or not src-glut/, demos/, etc. exist at compile time.


> Anyways, my first show at building died with cpp unable to find
> GL/include/glcore.h, included from glheader.h. I have not been able to find
> that file anywhere, however my old locate db indicated it used to reside
> in the Mesa src/ dir. Am I missing something or is this a bug?

As Keith said, it's in Mesa/include/GL/internal/glcore.h.

-Brian

Re: [Mesa3d-dev] back to autoconf 2.13

[Sven M. H. <pe...@gm...>]

On Mon, Feb 12, 2001 at 12:17:20PM -0700, Brian Paul wrote:
> "Sven M. Hallberg" wrote:
> > 
> > Greetings,
> > 
> > I have rearranged the configure.in to work with autoconf v2.13 again.
> > Unfortunately it is now no longer possible to use configure to compile a Mesa
> > with missing GLUT and/or demo source directories. However, one might consider
> > making those seperate packages, thus giving them their own configure script...
> > But that's another story.
> 
> As sophisticated as autoconf is, I'm surprised that you can't
> detect whether or not src-glut/, demos/, etc. exist at compile time.

Well, the problem lies in dynamically generating the list of Makefiles to be
created, depending on which directories are present. With the current autoconf
you must pass the entire list to a single call of AC_OUTPUT. The only
way for a dynamic list is to use a variable and pass that one. I guess that
would work with autoconf, _but_ it doesn't with automake because automake
parses configure.in for the call to AC_OUTPUT and if it finds AC_OUTPUT($list)
assumes it should create a file $list.in. *g*

In the new autoconf you have the required flexibility because it uses
a dynamic list internally, i.e. you specify any files to be created by means
of repetitive calls to a certain macro (AC_CONFIG_FILES I think) and call
AC_OUTPUT without any arguments. The new automake is of course aware of
AC_CONFIG_FILES.


> > Anyways, my first show at building died with cpp unable to find
> > GL/include/glcore.h, included from glheader.h. I have not been able to find
> > that file anywhere, however my old locate db indicated it used to reside
> > in the Mesa src/ dir. Am I missing something or is this a bug?
> 
> As Keith said, it's in Mesa/include/GL/internal/glcore.h.

Yes, wasn't able to reach the CVS server last weekend, updating right now.
Just missed that CVS switch. Actually the compile is running now and everything
appears to be fine, at least as far as the include error is concerned.


-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] back to autoconf 2.13

[Brian P. <br...@va...>]

"Sven M. Hallberg" wrote:
> 
> On Mon, Feb 12, 2001 at 12:17:20PM -0700, Brian Paul wrote:
> > "Sven M. Hallberg" wrote:
> > >
> > > Greetings,
> > >
> > > I have rearranged the configure.in to work with autoconf v2.13 again.
> > > Unfortunately it is now no longer possible to use configure to compile a Mesa
> > > with missing GLUT and/or demo source directories. However, one might consider
> > > making those seperate packages, thus giving them their own configure script...
> > > But that's another story.
> >
> > As sophisticated as autoconf is, I'm surprised that you can't
> > detect whether or not src-glut/, demos/, etc. exist at compile time.
> 
> Well, the problem lies in dynamically generating the list of Makefiles to be
> created, depending on which directories are present. With the current autoconf
> you must pass the entire list to a single call of AC_OUTPUT. The only
> way for a dynamic list is to use a variable and pass that one. I guess that
> would work with autoconf, _but_ it doesn't with automake because automake
> parses configure.in for the call to AC_OUTPUT and if it finds AC_OUTPUT($list)
> assumes it should create a file $list.in. *g*
> 
> In the new autoconf you have the required flexibility because it uses
> a dynamic list internally, i.e. you specify any files to be created by means
> of repetitive calls to a certain macro (AC_CONFIG_FILES I think) and call
> AC_OUTPUT without any arguments. The new automake is of course aware of
> AC_CONFIG_FILES.

You had suggested putting all the demo directories under a new demo/
subdirectory.  How would that work?

-Brian

Re: [Mesa3d-dev] back to autoconf 2.13

[Sven M. H. <pe...@gm...>]

On Fri, Feb 16, 2001 at 08:30:14AM -0700, Brian Paul wrote:
> > Well, the problem lies in dynamically generating the list of Makefiles to be
> > created, depending on which directories are present. With the current autoconf
> > you must pass the entire list to a single call of AC_OUTPUT. The only
> > way for a dynamic list is to use a variable and pass that one. I guess that
> > would work with autoconf, _but_ it doesn't with automake because automake
> > parses configure.in for the call to AC_OUTPUT and if it finds AC_OUTPUT($list)
> > assumes it should create a file $list.in. *g*
> > 
> > In the new autoconf you have the required flexibility because it uses
> > a dynamic list internally, i.e. you specify any files to be created by means
> > of repetitive calls to a certain macro (AC_CONFIG_FILES I think) and call
> > AC_OUTPUT without any arguments. The new automake is of course aware of
> > AC_CONFIG_FILES.
> 
> You had suggested putting all the demo directories under a new demo/
> subdirectory.  How would that work?

You mean, whether that would solve the problem? No, because a) you still
need to dynamically decide whether demo/Makefile should be created or not and
b) there are still src-glu and src-glut.

The suggestion to move all the demos under one common subdir was made because
one plausible way to fix the problem cleanly is to make two seperate
packages (in autoconf's sense) "Mesa-demos", "Mesa-GLUT", and "Mesa-GLU". Those
would have their own configure script and be placed in subdirs of the Mesa
sources. Their configure scripts would be invoked by the top-level configure.
That way it's also easy to distribute them seperately from Mesa itself (I think
that's already being done with the demos, right?). It's just a matter of what
you put in the tarball.

-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]