glean-dev — Glean development discussions

Re: [glean-dev] Glean for BeOS

[Adam H. <ad...@ne...>]

On Mon, Jan 24, 2000 at 07:15:36PM -0800, ak...@po... wrote:
> Adam, unless you'd like to do the honors, I'll also move the data from
> teapot.data into tteapot.cpp.  I think it's important that glean be
> self-contained, so that testers can run it without having to be in a
> particular directory.  (And also so that the binaries can be copied
> and passed along freely, without the person doing the copying having
> to know that certain data files must also be included.)

	Go right ahead--that particular stack of code is from a few
different places within Be's GLTeapot Demo, so it is more
functional then pretty.

-- 
Adam Haberlach             |"perl cannot be taught. It is an art
ad...@ne...        |  form unto itself."
http://www.newsnipple.com/ |                         --Jason Hoos

Re: [glean-dev] Glean for BeOS

[<ak...@po...>]

The changes look good on Linux.  Everything compiles, runs, and yields
the same results as the previous version.  I'll make a few cosmetic
changes to common.mak (so that the comments match the code).

Adam, unless you'd like to do the honors, I'll also move the data from
teapot.data into tteapot.cpp.  I think it's important that glean be
self-contained, so that testers can run it without having to be in a
particular directory.  (And also so that the binaries can be copied
and passed along freely, without the person doing the copying having
to know that certain data files must also be included.)

Allen

Re: [glean-dev] Glean for BeOS

[<ak...@po...>]

On Mon, Jan 24, 2000 at 05:06:19PM -0800, Adam Haberlach wrote:
| 	I have just checked in a batch of changes that should
| add support for BeOS without breaking support for Unices.

Thanks; I'll check them out on Linux.

| 	Also, the tools don't build or work at the moment
| since they seem to use Glut.  I'll take a look or two into
| fixing them.

If you choose to eliminate the use of Glut, you'll need to provide a
portable hierarchical menu system to replace it.  :-)

Allen

[glean-dev] Glean for BeOS

[Adam H. <ad...@ne...>]

	I have just checked in a batch of changes that should
add support for BeOS without breaking support for Unices.  I
ended up adding a PLATFORM variable to the common.mak, which
changes several of the common defines.

	I also have not tested this on any other platform, so
I may have inadvertantly broken things for others--go ahead
and yell at me, back out my code, or hack around it.

	Also, the tools don't build or work at the moment
since they seem to use Glut.  I'll take a look or two into
fixing them.

-- 
Adam Haberlach             |"Your stdio isn't very std.
ad...@ne...        |  Your stdio looks like linux."
http://www.newsnipple.com/ |       -- Larry Wall, Perl5 Configure

Re: [glean-dev] Makefile problems?

[Johan S. <joh...@gl...>]

Hi,

> I just grabbed the zip file from SourceForge and unzipped it, and all
> the Win32 makefiles look fine to me -- CR/LF at end-of-line just like
> they should be.  However, I checked this on Linux, not on Windows.  Is
> it possible that WinZip (or whatever other package you're using) is
> doing some sort of CR/LF translation by default?  Maybe because the
> archive isn't marked as being created by Windows or DOS?

I just tested it on Windows and everything looks fine. I checked
my version of WinZip and it says it only does CR/LF translation on
tar archives. I have no idea what could be the problem ...

> |                                  ...and then that .STRICT : directive at
> | the top I just had to remove to convince it to build at all.
> 
> I'm clueless about .STRICT .  I'll have to defer to Johan on that one.

.STRICT ? I assume you mean the .SILENT at the top of each makefile.
It's just a nmake directive that suppresses display of executed
commands. I added that to make the output more readable. I don't
really see why this would cause any problems. Brian, could you be
more specific about what went wrong ?

The Win32 makefiles are derived from makefiles exported by VC6 from
a workspace I originaly used. I switched to makefiles because I was
unable to get VC6 to build all the projects in the workspace in the
correct order.

As Allen mentions in another e-mail, the win32 makefiles have to be
manually updated when a test (or any other source file) is added.
I've looked into this, but unfortunately I haven't found a way to
tell nmake to build all .cpp files in a directory (yet).
Has anybody got any ideas how to do this ?


Johan.

Re: [glean-dev] Makefile problems?

[<ak...@po...>]

On Sat, Jan 22, 2000 at 09:49:06AM -0600, Cass Everitt wrote:

| Of course there's nothing that prohibits using MSVC++ project
| features for build management.  It makes it more difficult to keep
| the build mechanism in sync with the source tree when there are
| multiple parallel build mechanisms.

That's true, however, much of the target audience for glean uses
Visual Studio rather than the CygWin tools.  As a consequence I don't
want to *require* that people use CygWin to build glean.

| Is it acceptable to have a "primary" build mechanism that is always
| kept in sync with the development source tree, then sync the other
| build mechanisms with the source tree as necessary (like on release
| versions)?

We'll probably be able to do something like that.  (Although
personally, I *really* don't want to spend more time on infrastructure
issues.  I've been doing almost nothing else since the first release
of glean, and it's long past time to start concentrating on writing
new tests.  I have a backlog of those to write.)

With respect to Adam's problems on BeOS, I'm hoping that all we need
is a new BeOS-specific common.mak file that sets the include path
appropriately for BeOS.  That should solve the problem with
conflicting header filenames.

BTW, a reference to the following page appeared on the linux-kernel
list today:

	http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html

It has some interesting observations on why recursive invocation of
make is a bad thing.

Allen

Re: [glean-dev] Makefile problems?

[Adam H. <ad...@ne...>]

On Sat, Jan 22, 2000 at 09:49:06AM -0600, Cass Everitt wrote:

> In particular, we use gnumake specific features as well as things like find
> and sed to automatically build dependencies (if desired).  Are
> cygwin-like tools available on beos and mac?

On BeOS, at least, almost all of the tools are straight GNU ports
by default, and there are quite a few others at GeekGadgets
(http://www.ninemoons.com)

-- 
Adam Haberlach             |"Be a realist. The glass is twice
ad...@ne...        |  as large as it needs to be."
http://www.newsnipple.com/ |                        --Greg Kaiser

Re: [glean-dev] Makefile problems?

[Cass E. <ca...@r3...>]

ak...@po... wrote:
> 
> On Fri, Jan 21, 2000 at 10:44:45PM -0500, Cass W. Everitt wrote:
> |
> |   We regularly build the same source tree under Win32 and Linux, and
> | have built a set of GNU Makefile facilities called "makeLib" using this
> | approach, we have very simple makefiles.
> 
> Looks good, though I'm not sure we can assume that folks running on
> Windows are using GNU make (rather than nmake, or the builtin project
> management features of Visual Studio).  I'm open to suggestions from
> the folks on this mailing list...
> 

  Of course there's nothing that prohibits using MSVC++ project features
for build management.  It makes it more difficult to keep the build
mechanism
in sync with the source tree when there are multiple parallel build
mechanisms.

Since our target platforms have only been unix/linux and win32, gnumake
was
a logical choice.  I have absolutely no experience building on beos or
mac,
so I don't know whether our makeLib could be adapted to support those
platforms.

In particular, we use gnumake specific features as well as things like
find
and sed to automatically build dependencies (if desired).  Are
cygwin-like
tools available on beos and mac?

Is it acceptable to have a "primary" build mechanism that is always kept
in
sync with the development source tree, then sync the other build
mechanisms
with the source tree as necessary (like on release versions)?


								Cass

Re: [glean-dev] Makefile problems?

[<ak...@po...>]

On Fri, Jan 21, 2000 at 10:44:45PM -0500, Cass W. Everitt wrote:
| 
|   We regularly build the same source tree under Win32 and Linux, and
| have built a set of GNU Makefile facilities called "makeLib" using this
| approach, we have very simple makefiles.

Looks good, though I'm not sure we can assume that folks running on
Windows are using GNU make (rather than nmake, or the builtin project
management features of Visual Studio).  I'm open to suggestions from
the folks on this mailing list...

Allen

Re: [glean-dev] Makefile problems?

[Cass W. E. <ca...@r3...>]

ak...@po... wrote:
> 
> | I may look into doing a bit of major work on the Makefiles...
> 
> Sounds like it might be necessary.  Let's make a separate version for
> BeOS, though; sharing Makefiles across different operating systems is
> *very* difficult if all developers don't have access to all the
> operating systems so that they can verify changes.
> 

  We regularly build the same source tree under Win32 and Linux, and
have built a set of GNU Makefile facilities called "makeLib" using this
approach, we have very simple makefiles.

Here's an example of a makefile that builds a library called 
libsoftLibOpenGL.so or softLibOpenGL.dll depending on the build
platform, and has dependencies on the "cost" package. 
---
TOPDIR := ../..

PACKAGE_DEPENDENCIES := cost

SUBDIRS := mappers nids

LIBTARGETS := softLibOpenGL

include $(MAKELIB_HOME)/all.mk
---

Here's an example of a makefile that builds an executable called 
display_nexrad_sites.  It has package dependencies of cost, softLib,
mysql (client libs), glut, and gl (glu is implicitly included with
the gl package). Packages are defined in MakeLib and are user overridable.

---
PACKAGE_DEPENDENCIES := cost softLib mysql glut gl
 
BINTARGETS := display_nexrad_sites

include $(MAKELIB_HOME)/all.mk
---

We did a lot of work to try to make makeLib as configurable and
simple as possible while supporting platform independence.  We currently
use it to build using gnu compilers on linux and the MSVC++ on Win32.
We've found it helpful to not have to supply two sets of makefiles, but
it does require installing the cygwin tools. 

We have pretty much made a commitment to provide this as open source,
and it would probably be pretty easy for us to convert the glean makefiles
to use makeLib.  Would that be a worthwhile effort?

							Cass

-- 
----------------------------------------------------------
Cass W. Everitt			Objectecture, Inc.
Ph:  256/772-2365 		112 Ketchum Way
http://www.r3.nu/		Madison, AL 35758

Re: [glean-dev] Makefile problems?

[<ak...@po...>]

On Fri, Jan 21, 2000 at 01:12:37PM -0800, Adam Haberlach wrote:
| 
| chumbucket:/boot/home:make -v
| GNU Make version 3.77, by Richard Stallman and Roland McGrath.

That's the same version I'm running.

| I may look into doing a bit of major work on the Makefiles...

Sounds like it might be necessary.  Let's make a separate version for
BeOS, though; sharing Makefiles across different operating systems is
*very* difficult if all developers don't have access to all the
operating systems so that they can verify changes.

Allen

Re: [glean-dev] Makefile problems?

[Adam H. <ad...@ne...>]

On Fri, Jan 21, 2000 at 11:23:00AM -0800, ak...@po... wrote:
> On Fri, Jan 21, 2000 at 11:09:07AM -0800, Adam Haberlach wrote:
> | When I do makes, I get a lot of the following error:
> | 
> | /bin/sh: -c: line 1: syntax error near unexpected token `;'
> | /bin/sh: -c: line 1: `for d in ; do (cd $d; /bin/make all); done '
> | make: *** [all_dirs] Error 2
> | 
> | In fact, I seem to get it for every directory--am I the only one (it could
> | be a BeOS thing)?  I don't seem to be enough of a makefile wizard to fix this
> | myself.
> 
> Are you using GNU make?  The Linux Makefiles depend on several
> features of GNU make, so that might be the cause of some of your
> problems.  Otherwise, the only thing that occurs to me is that the
> GLEAN_ROOT environment variable might not be set correctly.

chumbucket:/boot/home:make -v
GNU Make version 3.77, by Richard Stallman and Roland McGrath.

I may look into doing a bit of major work on the Makefiles--I mainly
wanted to see if there were any major Make gurus out there.

-- 
Adam Haberlach             |"No, no. I never drink. Well, perhaps a very small
ad...@ne...        | single-malt scotch--neat."
http://www.newsnipple.com/ | Jean-Luis Gasse, Red Herring, December 1996

Re: [glean-dev] Makefile problems?

[<ak...@po...>]

On Fri, Jan 21, 2000 at 03:05:59PM -0600, Brian Sharp wrote:
| 
| On the topic of makefiles, I'll jump in with a barely-related comment...
| when I snagged glean and built it for Win32, I had to make a number of
| modifications to the makefiles to coax it into building.  The first was
| that they seem to be stored with Unix newlines in them...

I just grabbed the zip file from SourceForge and unzipped it, and all
the Win32 makefiles look fine to me -- CR/LF at end-of-line just like
they should be.  However, I checked this on Linux, not on Windows.  Is
it possible that WinZip (or whatever other package you're using) is
doing some sort of CR/LF translation by default?  Maybe because the
archive isn't marked as being created by Windows or DOS?

|                                  ...and then that .STRICT : directive at
| the top I just had to remove to convince it to build at all.

I'm clueless about .STRICT .  I'll have to defer to Johan on that one.

Allen

Re: [glean-dev] Makefile problems?

[Brian S. <bs...@ac...>]

At 11:23 AM 1/21/00 -0800, you wrote:
>There is some risk to using separate Makefiles -- the Makefiles can
>get out of sync with the source if someone who contributes a test
>forgets to update the Makefiles for all the operating systems other
>than the one s/he is using.  (On the flip side, changing the other
>Makefiles might introduce syntax errors, but I think that's a risk
>we'll have to take.)  This is not a problem for the original Linux
>Makefiles, because they scan the directory for .cpp files and set up
>all the dependencies automatically.

On the topic of makefiles, I'll jump in with a barely-related comment...
when I snagged glean and built it for Win32, I had to make a number of
modifications to the makefiles to coax it into building.  The first was
that they seem to be stored with Unix newlines in them, which was giving
MSVC 6's nmake a really rough time, and then that .STRICT : directive at
the top I just had to remove to convince it to build at all.

It's been a week or two since I did it, but it sure took a lot of work.
Maybe it worked with MSVC 5 or something?

-Brian
------
3dfx Interactive           "billowing out to somewhere"
Graphics Guru & Pianist-At-Large           - Tori Amos
I speak for myself, not my company.
http://www.cs.dartmouth.edu/~bsharp/

Re: [glean-dev] Makefile problems?

[<ak...@po...>]

On Fri, Jan 21, 2000 at 11:09:07AM -0800, Adam Haberlach wrote:
| When I do makes, I get a lot of the following error:
| 
| /bin/sh: -c: line 1: syntax error near unexpected token `;'
| /bin/sh: -c: line 1: `for d in ; do (cd $d; /bin/make all); done '
| make: *** [all_dirs] Error 2
| 
| In fact, I seem to get it for every directory--am I the only one (it could
| be a BeOS thing)?  I don't seem to be enough of a makefile wizard to fix this
| myself.

Are you using GNU make?  The Linux Makefiles depend on several
features of GNU make, so that might be the cause of some of your
problems.  Otherwise, the only thing that occurs to me is that the
GLEAN_ROOT environment variable might not be set correctly.

| While we are on the subject of makefiles, how should I handle BeOS vs. Linux
| in the build process?  There are several differences (mainly in the libraries
| included) that need to be addressed...

There's no organized approach to this at the moment, so the best
solution might be to supply separate Makefiles for BeOS.  That's what
we did for Windows.  (See $GLEAN_ROOT/make/common.win and the
makefile.win files in all the subdirectories.) You can put common
stuff for all compilations in common.beos, and individual changes in
various makefile.beos files.

There is some risk to using separate Makefiles -- the Makefiles can
get out of sync with the source if someone who contributes a test
forgets to update the Makefiles for all the operating systems other
than the one s/he is using.  (On the flip side, changing the other
Makefiles might introduce syntax errors, but I think that's a risk
we'll have to take.)  This is not a problem for the original Linux
Makefiles, because they scan the directory for .cpp files and set up
all the dependencies automatically.

Allen

[glean-dev] Makefile problems?

[Adam H. <ad...@ne...>]

When I do makes, I get a lot of the following error:

/bin/sh: -c: line 1: syntax error near unexpected token `;'
/bin/sh: -c: line 1: `for d in ; do (cd $d; /bin/make all); done '
make: *** [all_dirs] Error 2

In fact, I seem to get it for every directory--am I the only one (it could
be a BeOS thing)?  I don't seem to be enough of a makefile wizard to fix this
myself.

While we are on the subject of makefiles, how should I handle BeOS vs. Linux
in the build process?  There are several differences (mainly in the libraries
included) that need to be addressed...


-- 
Adam Haberlach             |BeOS: it's nothing that somebody hasn't done before.
ad...@ne...        | Until now, something that nobody has done right.
http://www.newsnipple.com/ | 				--Me

[Glean-dev] Welcome To "glean-announce"!

[<gle...@so...>]

Welcome to the gle...@li... mailing list!

To post to this list, send your email to:

  gle...@li...

General information about the mailing list is at:

  http://lists.sourceforge.net/mailman/listinfo/glean-announce

If you ever want to unsubscribe or change your options (eg, switch to
or from digest mode, change your password, etc.), visit your
subscription page at:

  http://lists.sourceforge.net/mailman/options/glean-announce/gle...@li...


You can also make such adjustments via email by sending a message to:

  gle...@li...

with the word `help' in the subject or body (don't include the
quotes), and you will get back a message with instructions.

You must know your password to change your options (including changing
the password, itself) or to unsubscribe.  It is:

  kMlE

If you forget your password, don't worry, you will receive a monthly
reminder telling you what all your lists.sourceforge.net mailing list
passwords are, and how to unsubscribe or change your options.  There
is also a button on your options page that will email your current
password to you.

You may also have your password mailed to you automatically off of the
Web page noted above.