Subject: Notification: incoming/650

From: [email-masked]
Date: Wed, 6 Sep 2000 17:34:19 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/650

Message summary for PR#650
	From: [email-masked]
	Subject: FvwmConfigDefaults location hard-coded
	Date: Wed, 6 Sep 2000 17:34:17 -0500 (CDT)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Dan Espen <[email-masked]>
Date: Wed, 06 Sep 2000 22:03:33 -0400

[email-masked] writes:
> To: [email-masked]
> Full_Name: Bryan Henderson
> 
> Fvwm2 has a built-in Read command "Read FVWM_DATADIR/ConfigFwvmDefaults"
> where FVWM_DATADIR is the Fvwm data directory determined at build time.
> I'm not sure why, since FVWM_DATADIR is part of the default search path
> for Read commands, but this creates at the very least an annoying error

The search order for read commands starts with the user and then
the fvwm data directory.  The file ConfigFvwmDefaults isn't meant to
be changed by users, hence the full path.

> message unless you build Fvwm for specific file locations.  I prefer not
> to build file locations into my programs.
>
> One way around this, which I've done for myself, is to change it to
> "Read ConfigFwvmDefaults".  Another is to provide an environment variable
> FVWM_DATADIR.  This might help with other dependencies on this path too.

I agree that dependencies are bad.
I just did "configure --help".  It seems to me there are a lot of paths
built into fvwm.  Is this preference related to a real need?

> Incidentally, the error message in this case isn't quite right.  It says,
> "/blah/blah/blah/ConfigFwvmDefaults not found in /blah/blah/blah or
> ~~/.fvwm".  Because it's an absolute path, though, Fvwm didn't really 
> look in those directories.

That message has been that way since at least 2.0.47d (the oldest version
I keep around).  I remember once trying to clean it up.  I guess I gave up.

Maybe the message should read:

<file> not found in <userhome> or <fvwmdatadir>, not sure which

(Just kidding... sort of.)

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: [email-masked] (Bryan Henderson)
Date: Thu, 7 Sep 2000 11:33:54 -0700

>I agree that dependencies are bad.  I just did "configure --help".  It
>seems to me there are a lot of paths built into fvwm.

Those paths mainly just affect 'make' and 'make install'.  Some of them
are built into the code as last resort defaults, to which I have no 
objection.  I only use Fvwm simply, but so far the only path I have found
that I cannot choose at run time is the one to ConfigFwvmDefaults.

>Is this preference related to a real need?

It's real enough that I modified the source code to make an acceptable
version for me.  I build things like this with a dummy --prefix path
(it's a temporary directory) so that I can do a 'make install' without
modifying a running system, then install the built objects wherever
they make sense on various systems.  Usually, I set environment
variables in system profiles to tell the programs where their parts
are installed, but since I can't do that with Fvwm, I just copy the
necessary files into the ~/.fvwm's (and that only works because of the
slight modification I made to fvwm.c).

-- 
Bryan Henderson                                    Phone 415-505-3367
Olympia, Washington