Subject: module path

From: [email-masked]
Date: Thu, 5 Nov 1998 13:37:34 +0100

Is there any particular reason why the module path defaults
to /usr/local/libexec/fvwm/2.1.0? I liked it much more when
the default (with Imake) was the same directory as the fvwm2
executable was found in.

The problem is that the module path im my .fvwm2rc has not
been parsed when I start FvwmCpp. This way I have to link
said directory to my fvwm2 path (i.e. I have to change my
setup).

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: [email-masked] (Paul D. Smith)
Date: 05 Nov 1998 09:21:39 -0500

%% [email-masked] writes:

  dv> Is there any particular reason why the module path defaults to
  dv> /usr/local/libexec/fvwm/2.1.0? I liked it much more when the
  dv> default (with Imake) was the same directory as the fvwm2
  dv> executable was found in.

Was it?  That's not how any of my installations are set up, and I don't
recall changing this when installing fvwm.  In my setup fvwm2 is
installed into /usr/bin/X11 and the modules and system.fvwmrc files were
installed in /usr/lib/X11/fvwm.

  dv> The problem is that the module path im my .fvwm2rc has not been
  dv> parsed when I start FvwmCpp. This way I have to link said
  dv> directory to my fvwm2 path (i.e. I have to change my setup).

Yes, Dan also discussed moving things around.  As I mentioned in a
response to him, the new layout is the GNU standard.  The binaries are
in .../bin and any ancillary, "supporter" apps that can't/shouldn't be
invoked directly go in .../libexec.

Of course, you can always change the installation layout to anything you
want via one of the methods mentioned before (using options to configure
or writing a config.site file containing your preferences).

As I mentioned to Steve last week, though, it's a problem that modules
change directories every release.  Although removing the ModulePath from
your .fvwm2rc file fixes the simplest problems, it doesn't help when (a)
you _need_ to add module paths, and (b) you use that value for other
things (for example I have a little shell script I invoke at init time
that does an "ls" on the modules directory and creates a menu of modules
to invoke).

Here's a thought: maybe fvwm could define the builtin paths as
_environment_variables_ when it starts up.  Say FVWM_MODULEPATH or
something.  Then that environment variable can be used in the .fvwm2rc
file, like this:

  ModulePath /my/modules:$FVWM_MODULEPATH:/some/other/modules

This would also (of course) be exported to subshells.  Would this be
good enough for FvwmCpp (I don't use it so I don't know)?

Basically, I think it's OK to require people to change their setup
_once_ when they install Fvwm 2.2, but I don't think they should be
required to do so for _every_ new fvwm they install.

PS. Even though it's a pain, I do like having things install in
    different places with each release.  Don't know about you all but
    here I always have to maintain old versions and for Imake apps
    that's always impossible.  I really appreciate the GNU tools that
    allow concurrent, working installations.

-- 
-------------------------------------------------------------------------------
 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: [email-masked]
Date: Thu, 5 Nov 1998 15:45:00 +0100

> installed in /usr/lib/X11/fvwm.

Yup, it was. If FVWM_MODULEPATH wasn't defined, the current dir
was used. Now the default is taken instead.

> invoked directly go in .../libexec.

I understand the reasoning, but it effectively prevents me from
using a local installation as I do now (just copy the executables
somewhere in the path before the real binaries).

> or writing a config.site file containing your preferences).

Can I do it as an option to configure?

> you _need_ to add module paths,

I can add module paths, but not for the preprocessor modules or anything
started via command argument to fvwm2

> and (b) you use that value for other

Fvwm has been around so long, there are probably people who do this.

> good enough for FvwmCpp (I don't use it so I don't know)?

No. The resource file has not been parsed at this moment. FvwmCpp
is given as an option to fvwm2 before parsing the config file.

> required to do so for _every_ new fvwm they install.

OK

>     allow concurrent, working installations.

I rename the executables I want to keep.

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 05 Nov 1998 10:07:13 -0500

>> or writing a config.site file containing your preferences).

  dv> Can I do it as an option to configure?

Yes... I forget which option(s) are needed.  Maybe Dan can help (or look
in the list archives, I guess).

  >> something.

  dv> No. The resource file has not been parsed at this moment. FvwmCpp
  dv> is given as an option to fvwm2 before parsing the config file.

I wasn't clear.  I meant that fvwm2 could define that environment
variable (using putenv) _immediately_ upon startup, and it would contain
only the compiled-in value, not the entire ModulePath.  It could be done
first thing in main(), even.  It's a predefined value, after all, so
there's no need to read the config file to get it.

I guess I should have named the environment variable
FVWM_DEFAULTMODULEPATH or something, instead :).

The only question is whether FvwmCpp can make use of it; I guess that
depends on whether the FvwmCpp module is invoked via the shell and you
can use things like:

  -cmd 'FvwmCpp -DMPATH=\"$FVWM_DEFAULTMODULEPATH\" .fvwm2rc'

since cpp can't access values in the environment directly.

  >> allow concurrent, working installations.

  dv> I rename the executables I want to keep.

But then they don't work anymore, right?  I mean you have to rename them
back again.

We have a huge developer organization here and it's very nice if I can
install new tools and tell people who complain to just use the old
version ("run fvwm-2.0.46 instead of fvwm2") and it all just works.
These tools are all available on everyone's system via a large central
NFS-mounted filesystem.  That's what I mean by "concurrent, working
installations"; you can be running different versions at the same time
out of the same directory and they all work.

---

From: Dan Espen <[email-masked]>
Date: Thu, 05 Nov 1998 11:05:04 -0500

> in the list archives, I guess).

Heres how  I'm running configure  to get fvwm2 and  the modules in the
same place:

#!/bin/ksh

export CC=gcc
export CXX=g++

../version-2_1_0/configure \
  --bindir=/opt/public/src/fvwm/2.1.0 \
  --libexecdir=/opt/public/src/ \
  --prefix=/opt/public \
  --x-libraries=/usr/openwin/lib:/opt/public/lib\
  --with-xpm-includes=/opt/public/include --with-xpm-library=/opt/public/lib

The "bindir" and the "libexecdir" are the crucial parts.

> since cpp can't access values in the environment directly.

I've  always used  a  shell called "fvwm2"  start  fvwm2.   It exports
variables for   my  users to  use in  their  .fvwm2rc  for ModulePath,
PixMapPath, and some of the reads for common config files.

Long term, I see PixMapPath and ModulePath being built in during install.
Setting either in the .fvwm2rc would only stick values in front of that.

>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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: [email-masked] (Paul D. Smith)
Date: 05 Nov 1998 12:13:07 -0500

%% Dan Espen <[email-masked]> writes:

  de> I've  always used  a  shell called "fvwm2"  start  fvwm2.   It exports
  de> variables for   my  users to  use in  their  .fvwm2rc  for ModulePath,
  de> PixMapPath, and some of the reads for common config files.

That'd work, but it'd be nice if fvwm2 provided that for you without a
wrapper.

  de> Long term, I see PixMapPath and ModulePath being built in during
  de> install.

?? They already are.  If you don't provide any value in your ~/.fvwm2rc
file you get the default.

The problem is there's no way to access that default from within your
config file (or anywhere else).

  de> Setting either in the .fvwm2rc would only stick values in front of
  de> that.

That would probably be sufficient for the modules list (I can't think of
a good reason you'd want to add values behind the default), but what
about other things that want to know where modules live, like my script
to construct a modules menu?

---

From: Dan Espen <[email-masked]>
Date: Thu, 05 Nov 1998 13:33:52 -0500

> That'd work, but it'd be nice if fvwm2 provided that for you without a

I agree that fvwm2 should provide these by default.

In my experience,  if I replace a UNIX  binary while others are  using
it, I can cause the other users problems.  (Core dumps.)

Since there is now way I can get other users out of fvwm2 to install a
new version of  fvwm2, I maintain that fvwm2  should always be invoked
from a shell in a multi-user environment.

> config file (or anywhere else).

Yes, and  I believe,  if you try  to augment  the ModulePath or PixMap
path, you  loose what's built in.  I  think we all agree, fvwm2 should
be exporting some variables.

> to construct a modules menu?

My plan, (I  keep coming  up with  plans),  was that  the module  menu
should  be built in.   You  wouldn't need to  construct  a menu.  This
module menu was the last step to get FvwmAnimate to zero configuration
lines.

(I agree that fvwm2 should export the module path,  so you could still
build your own menu.)

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 5 Nov 1998 14:46:34 -0500 (EST)

On Thu, 5 Nov 1998 [email-masked] wrote:

: Is there any particular reason why the module path defaults
: to /usr/local/libexec/fvwm/2.1.0? I liked it much more when
: the default (with Imake) was the same directory as the fvwm2
: executable was found in.

I do sort of like the "version" directory. It would allow for more than one
version installation, but then you would want a %version% tag in the
.fvwm2rc file as well as the %default% path also suggested.

Randall

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 5 Nov 1998 15:19:28 -0500 (EST)

On Thu, 5 Nov 1998, Dan Espen wrote:

: [email-masked] (Paul D. Smith) writes:
: > %% Dan Espen <[email-masked]> writes:
: > 
: >   de> I've  always used  a  shell called "fvwm2"  start  fvwm2.   It exports
: >   de> variables for   my  users to  use in  their  .fvwm2rc  for ModulePath,
: >   de> PixMapPath, and some of the reads for common config files.
: > 
: > That'd work, but it'd be nice if fvwm2 provided that for you without a
: > wrapper.

I see as wrapper as a workaround. I would prefer a more elegant solution.

: In my experience,  if I replace a UNIX  binary while others are  using
: it, I can cause the other users problems.  (Core dumps.)
: 
: Since there is now way I can get other users out of fvwm2 to install a
: new version of  fvwm2, I maintain that fvwm2  should always be invoked
: from a shell in a multi-user environment.

This is not true, I do this for high profile applications all the time;

mv important_app important_app.inuse; cp important_app.new important_app

The trick is not to change the inode of running programs. 

The script will only help if you do not change the inode of a running
program.

: Yes, and  I believe,  if you try  to augment  the ModulePath or PixMap
: path, you  loose what's built in.  I  think we all agree, fvwm2 should
: be exporting some variables.

Correct.

: My plan, (I  keep coming  up with  plans),  was that  the module  menu
: should  be built in.   You  wouldn't need to  construct  a menu.  This
: module menu was the last step to get FvwmAnimate to zero configuration
: lines.

I was thinking on these lines last week. It might be useful if fvwm could
go down its path and include anything it found. But then the user could get
way more choices (some buggy) then they really want.