Subject: FVWM CVS: fvwm steve

From: CVS <[email-masked]>
Date: Sun, 3 Jan 1999 13:22:51 -0600 (CST)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	steve	99/01/03 13:22:50

Modified files:
	modules        : ChangeLog 
	modules/FvwmCpp: FvwmCpp.c 

Log message:
Removed #ifdef defaulting FVWM_CPP to "/usr/lib/cpp", if the symbol
was not defined.  The symbol ought to be defined at build time, and if
not, an error should be emitted, rather than silently taking a wild
guess.

This is in response to Bug #95 (FvwmCpp doesn't know where cpp is),
which is a real bug, not a "feature request".  I can't reproduce the
bug, BTW.

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 4 Jan 1999 05:41:36 +0100

Hi Steve,

nice to see you back.

> which is a real bug, not a "feature request".  I can't reproduce the

Does this mean you think the bug is fixed?

Bye

Dominik

--
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Steve Robbins <[email-masked]>
Date: Mon, 4 Jan 1999 06:50:24 -0500 (EST)

> Does this mean you think the bug is fixed?

No, I'm not claiming the bug is fixed, just that I can't reproduce the
reported behaviour. 

On my system, the correct path for cpp *is* passed at compile time to
FvwmCpp.  It has been like this since the beginning. 

So, either the initial bug report was in error, or there is something very
weird going on with his make or shell that screws up the symbol define.  I
have already emailed the guy who filed the report for clarification.

The change I made yesterday means that someone with a similar situation
will fail to compile FvwmCpp, so we'll see a bug report earlier.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 04 Jan 1999 13:06:53 +0000

> Does this mean you think the bug is fixed?

The patch is good but unfortunately it doesn't fix my problem. I think
the problem lies in the configure script.  On my system cpp is not on
$PATH and it's not in /usr/lib or /lib. If I ask gcc where it thinks cpp
is I get the following:

->gcc -print-prog-name=cpp 
/opt/gcc/lib/gcc-lib/sparc-solaris/2.8.1/cpp

The configure script knows that cpp is invoked with "gcc -E" but the
chunk at line 3310 ignores that and tries to set FVWM_CPP by searching
for cpp in a few places.  It fails and then sets FVWM_CPP to /lib/cpp.

I can get things to work if I export FVWM_CPP before running
./configure.

Is the chunk that sets FVWM_CPP in our control?  If it is then getting
it to use the output of "gcc -print-prog-name=cpp" would work.

Failing that I noticed that in the Makefile for FvwmCpp the variable CPP
is set (to "gcc -E" in my case) could $CPP be passed into FvwmCpp.c
rather than $FVWM_CPP?  If it can does $FVWM_CPP have any use?

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 04 Jan 1999 13:26:48 -0500

%% Tim Phipps <[email-masked]> writes:

  tp> Is the chunk that sets FVWM_CPP in our control?  If it is then
  tp> getting it to use the output of "gcc -print-prog-name=cpp" would
  tp> work.

Yes, that's in our control.  I'll see what I can do.

It might be easier to have it use "gcc -E" instead, although we'd need
to make sure the full path is set for that.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 4 Jan 1999 19:58:54 +0100

> to make sure the full path is set for that.

Umm, and what would happen if you don't have gcc?

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 04 Jan 1999 14:27:21 -0500

>> to make sure the full path is set for that.

  dv> Umm, and what would happen if you don't have gcc?

I wasn't clear.

What I meant was, it might be simpler to just use whatever configure
finds as the preprocessor, verbatim.  If you have gcc, configure chooses
"gcc -E".  If you don't, it looks elsewhere.  If it can't find one,
configure will fail so that's a pretty good way to avoid this problem
for FvwmCpp in the future :)

The other suggestion was to do something like: if the preprocessor is
gcc -E, then use the "gcc -print-prog-name=cpp" command to find the full
path and use that for FVWM_CPP.  This seems more complicated.  Plus, I'm
not at all sure older versions of GCC support this option.

---

From: Steve Robbins <[email-masked]>
Date: Tue, 5 Jan 1999 07:28:42 -0500 (EST)

> it to use the output of "gcc -print-prog-name=cpp" would work.

This can be done.  

However, when gcc is upgraded, and the old version removed, FvwmCpp will
break. 

More importantly, it only helps those with (a very recent?) gcc.  A more
general solution is required.

One way to fix this is to document a requirement that "cpp" be available
on the path, or in one of /lib, /usr/lib, or /usr/local/lib.  If root is
installing, making a symlink is easy.  If it is a mortal, they may have to
fall back on using the "-cppprog" option with FvwmCpp. 

> rather than $FVWM_CPP?

The problem is that "cc -E" expects the input filename on the commandline,
whereas "cpp" will read from standard in.  As currently written, FvwmCpp
writes to stdin of cpp.  Changing it to write to a tempfile to run cpp on
is possible, but it is worth the trouble? 

I'm more inclined to require cpp be on the path (or in some lib
directory).  I'm willing to make the changes in this direction, unless
someone is inspired enough to rewrite FvwmCpp.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 05 Jan 1999 14:23:52 +0000

> is possible, but it is worth the trouble?

Not only that but gcc -E complains if the file name does not have a .c
at the end.  Looks like we need a real cpp.

> someone is inspired enough to rewrite FvwmCpp.

You don't have to change anything. If cpp is on the path at configure
time it does get into FvwmCpp.  You could change the configure script to
not fall back to /lib/cpp if it can't find cpp, but I don't know if
configure should halt at that point or wait until FvwmCpp is compiled to
give an error.

Cheers,
Tim.

---

From: [email-masked]
Date: Tue, 5 Jan 1999 09:45:11 -0500 (EST)

> configure should halt at that point or wait until FvwmCpp is compiled to

How about:

	./configure --with-cpp=/some/nonstandard/location/cpp

(IN other words, punt to the user)

-- 
Larry Gensch					      [email-masked]

               "May I have ten thousand marbles, please?"

---

From: [email-masked] (Paul D. Smith)
Date: 05 Jan 1999 10:34:44 -0500

>> is possible, but it is worth the trouble?

  tp> Not only that but gcc -E complains if the file name does not have a .c
  tp> at the end.  Looks like we need a real cpp.

Bother.  I just spent a half-hour getting configure to find gcc :(

What it does now is (1) look for cpp as it used to (it now also looks in
/usr/ccs/lib, which is where Solaris likes to keep cpp), (2) if it's not
found it looks up the configure CPP contents and uses the complete path
to it.

So, when I fake it out to not find cpp it uses "/usr/local/bin/gcc -E".
As you say, this won't work because it expects a command line filename.

However, I just tried and this: "/usr/local/bin/gcc -E -" does take text
from stdin, and obviously there's no filename problem here (if there
were, you could always use "-x c").

This also avoids the version problem that the complete path to GCC's cpp
gives.  Of course if you move your gcc, that's another problem :).

So, it looks like we have two choices:

  1) Add yet another test to see if FVWM_CPP will actually work as
     found, and try adding the "-" option and retesting if it fails the
     first time.

  2) Forget the gcc -E thing altogether and go back to the "old way",
     but make more noise if cpp can't be found (see below).

I don't use FvwmCpp myself so this is a bit difficult for me to test
robustly.

  tp> You don't have to change anything. If cpp is on the path at
  tp> configure time it does get into FvwmCpp.  You could change the
  tp> configure script to not fall back to /lib/cpp if it can't find
  tp> cpp, but I don't know if configure should halt at that point or
  tp> wait until FvwmCpp is compiled to give an error.

Configure should halt.

Alternatively, we could have configure print a message and then not
compile FvwmCpp (but do everything else).

But there's no way a successful configure should result in compile
errors during the build if we can help it.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 05 Jan 1999 15:54:23 +0000

>      but make more noise if cpp can't be found (see below).

I vote for 2) as it's the least change.  With the "gcc -E" thing you
will have to make sure the makefile puts quotes around the
-DFVWM_CPP=$(FVWM_CPP} bit otherwise the spaces confuse the compiler.

Cheers,
Tim.

---

From: Steve Robbins <[email-masked]>
Date: Tue, 5 Jan 1999 18:58:40 -0500 (EST)

>      but make more noise if cpp can't be found (see below).

I think #2, since "cc -E -" ain't portable.  ;-(

> compile FvwmCpp (but do everything else).

No.  Configure should complain that it can't find cpp, *but* you can still
compile and use FvwmCpp.  It has a command-line option -cppprog to specify
the cpp program.

--
Steve Robbins                              <[email-masked]>

Well, you tried it just once, and found it alright for kicks,
Now you found out that it's a habit that sticks,
And you're an orgasm addict.

---

From: Steve Robbins <[email-masked]>
Date: Tue, 5 Jan 1999 18:59:50 -0500 (EST)

On Tue, 5 Jan 1999, Tim Phipps wrote:

> not fall back to /lib/cpp if it can't find cpp, 

Yes, that's the change I meant.  That, and documentation clarification.

I'd rather have one of your minutes
than a year with all the hours in it.

---

From: [email-masked] (Paul D. Smith)
Date: 05 Jan 1999 21:42:42 -0500

%% Steve Robbins <[email-masked]> writes:

  >> but make more noise if cpp can't be found (see below).

  sr> I think #2, since "cc -E -" ain't portable.  ;-(

I know, that's why I said we'd have to test it again after adding that,
to be sure it still worked.

Anyway, I greatly prefer the less difficult way, myself :)