Subject: Notification: incoming/121

From: [email-masked]
Date: Mon, 11 Jan 1999 12:58:14 -0600 (CST)

FVWM Bug Tracking notification

new message incoming/121

Message summary for PR#121
	From: [email-masked]
	Subject: Fvwm needs a shared module lib
	Date: Mon, 11 Jan 1999 12:58:12 -0600 (CST)
	0 replies 	0 followups

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

---

From: Dan Espen <[email-masked]>
Date: Tue, 12 Jan 1999 08:44:47 -0500

[email-masked] writes:
> Full_Name: Paul D. Smith
> Fvwm should create a library of functions for modules to use, and
> should install it when asked.  The library should be created both
> as a static and shared library (using the normal autoconf flags
> to control this).
> 
> Headers should be installed as well.  This leads to a slight problem:
> all the modules and headers right now rely on config.h which means
> that would have to be installed too.  Obviously you couldn't install it
> in /usr/local/include, so it would have to be installed in the FVWM
> module directory.  That may or may not be what the user wants!
> 
> Or, we could rename config.h to fvwmconfig.h or something and just
> install it.

Wouldn't it be simpler to just deal with the shared library which
has apparent benefits, and forget about the headers.

I don't have any "private" modules that would give me a need for
installing header files, but I don't think its clear that you would
install fvwm2, (including the headers), and then start compiling
your private modules.

Or maybe I'm missing the point?

> --

--
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.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: 12 Jan 1999 09:41:30 -0500

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

  de> Wouldn't it be simpler to just deal with the shared library which
  de> has apparent benefits, and forget about the headers.

  de> I don't have any "private" modules that would give me a need for
  de> installing header files, but I don't think its clear that you would
  de> install fvwm2, (including the headers), and then start compiling
  de> your private modules.

So... how would you compile private modules?  The other option is to
require a complete build of the fvwm2 tree available when you want to
compile a module.  Also this can get a little trickier if you're using
remote builds, because then some of the source (like config.h) is
available in the remote directory while the rest (fvwmlib.h) is
in the source tree.

I've dealt with a number of packages that require you to have the full
source tree around to compile against the library, and I always think
it's a big pain.  But, esp. given the number of external modules we
currently have :), I wouldn't put this high on anyone's TODO list.  I
just was thinking about it and wanted to get it into the bug database
for future reference.

-- 
-------------------------------------------------------------------------------
 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: Steve Robbins <[email-masked]>
Date: Tue, 12 Jan 1999 18:45:07 -0500 (EST)

> > as a static and shared library (using the normal autoconf flags

I was thinking about this this morning.  We already build (though not
install) libfvwm.  We could just dump the module functions in there, no?
Or is there an advantage to a separate libfvwm_module?  (Most modules
would be linking with libfvwm, anyway)

--
Steve Robbins                              <[email-masked]>

I was looking back to see
if you were looking back at me
to see me looking back at you.

---

From: [email-masked] (Paul D. Smith)
Date: 12 Jan 1999 19:29:19 -0500

>> > as a static and shared library (using the normal autoconf flags

  sr> I was thinking about this this morning.  We already build (though not
  sr> install) libfvwm.  We could just dump the module functions in there, no?
  sr> Or is there an advantage to a separate libfvwm_module?  (Most modules
  sr> would be linking with libfvwm, anyway)

No, libfvwm is fine and exactly what I was thinking.  Not sure how much
stuff in the current libfvwm is there only for fvwm and not for the
modules; if there's any significant amount we should consider moving it
to some fvwm-only library and out of the common one.

 a) It needs more stuff in it; I'm sure there're are more "common"
    functions we could collect that would make writing modules even
    simpler and more coherent.

 b) It needs to be able to be made shared lib--libtool, I assume, once
    2.2 is gone.

 c) The header file(s) issue needs to be addressed.

This is really what that bug was attempting to lay out, as a placeholder.

---

From: Steve Robbins <[email-masked]>
Date: Wed, 13 Jan 1999 08:40:27 -0500 (EST)

> to some fvwm-only library and out of the common one.

Mmm.  Even if 80% of libfvwm is only used by fvwm proper, I don't think it
is a problem.  

There are two cases.  If the lib is static, then the linker will only pull
out what the module needs, so it makes no difference in module size, etc. 
If the lib is shared, it will be loaded into mem by fvwm anyway, so again
it doesn't impact on performance, right? 

>     simpler and more coherent.

Yeah, this project has been at the back of my mind for some time now.
 
>  c) The header file(s) issue needs to be addressed.

I don't think that "config.h" is the problem, actually: that file mostly
contains system-compatibility stuff.  If I were building a module outside
of fvwm, I'd have it autoconf'd, and would have my own config.h. 

The headers that need to be installed would be some or all of libs/*.h and
fvwm/*.h.  It would be best, of course, if the installable ones were all
in libs/ but for some reason "module.h" is in fvwm/.

The revolution will not be televised.

---

From: Chris Rankin <[email-masked]>
Date: Wed, 13 Jan 1999 09:04:42 -0500 (EST)

> of fvwm, I'd have it autoconf'd, and would have my own config.h. 

Then I suspect that you would be part of a very small minority. The
average user would expect to be able to #include the header file and
go, not have to generate an extra header manually and especially not
have to learn about autoconf.

Is there a way that "make install" could generate a new fvwmlib.h
header using the current config.h and the preprocessor or some other
tool? I've seen a lot of packages that seem to generate header files
out of fragments at configure time. Is this any different?

Chris.

---

From: Dan Espen <[email-masked]>
Date: Wed, 13 Jan 1999 09:14:35 -0500

> of fvwm, I'd have it autoconf'd, and would have my own config.h. 

I still don't see the need  to install the  headers, I still think the
timing  is wrong, and  I don't see why  a  private module can't have a
make file that points into the fvwm2 source tree of the day.

However,    if   the   fvwm       headers    were      installed    as
<prefix>/include/fvwm/config.h, etc.    the header name   conflict for
config.h wouldn't be an issue.  We would need  to make a corresponding
change inside  of fvwm2, to match   the new way of  including headers,
Ie. "#include <fvwm/config.h>".

---

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

de> I still don't see the need to install the headers, I still think
  de> the timing is wrong,

Note I'm not suggesting this be done soon, before 2.2.  This is "future
stuff".

I'd love to see a shared libfvwm.so for 2.3, but anything beyond that I
don't know.  The fact is we don't _have_ tons of extra modules being
developed, so this isn't a critical issue by any stretch.

  de> and I don't see why a private module can't have a make file that
  de> points into the fvwm2 source tree of the day.

By "private" I mean a module which isn't distributed by fvwm.  It could
well be distributed by someone else and be incredibly popular
(like tkgoodstuff).

The problem with requiring that it use a source tree is that then, to
build and install it, you need the source to fvwm2.  That can be a pain:
maybe you installed fvwm2 last year and the source is long gone: now you
have to grab a new copy and build (or at least configure) that before
you can build the cool new module.

As I said, I've used a number of packages like this and I personally
always find them a pain in the rear, and mumble under my breath about
the folks who don't install the proper files so I don't need to do it
:).

  de> However, if the fvwm headers were installed as
  de> <prefix>/include/fvwm/config.h, etc.  the header name conflict for
  de> config.h wouldn't be an issue.  We would need to make a
  de> corresponding change inside of fvwm2, to match the new way of
  de> including headers, Ie. "#include <fvwm/config.h>".

I agree on the first point; that's a possibility.

Not on the second one, though: one of the problems anyone has when doing
this is making sure that the build of the _current_ version never uses
the headers and libraries globally installed for the _previous_ version.
You may recall that fvwm used to have this exact problem, itself, when
it installed libfvwm.a.

One trivial way to ensure this doesn't happen is by keeping the
directory structures different enough that the old stuff just isn't
seen.  For libraries we already win since the pathname to the lib dir
now has the version number in it.

---

From: [email-masked] (Paul D. Smith)
Date: 13 Jan 1999 09:38:08 -0500

sr> Mmm.  Even if 80% of libfvwm is only used by fvwm proper, I don't
  sr> think it is a problem.

  sr> There are two cases.  If the lib is static, then the linker will
  sr> only pull out what the module needs, so it makes no difference in
  sr> module size, etc.  If the lib is shared, it will be loaded into
  sr> mem by fvwm anyway, so again it doesn't impact on performance,
  sr> right?

Well, not really.  Recall that shared libraries incur a performance
penalty over static.  The numbers I've seen vary from 1% to 5% (for
ELF).  The thing is that shared libraries are position-independent (they
have to be, to be shared) so there's an extra bit to calculate offsets
when you reference functions and variables in the shared lib.

You might argue that (a) the amount of code that is used by fvwm2 but
not by any modules isn't much, and (b) the performance hit isn't that
big.  I'd agree with both of these, but I'd also point out that a window
manager is one of those apps where people really care about speed--I
wouldn't lose sleep over it, but all things being equal it'd be nice to
make all fvwm2-only functions statically linked.

  >> c) The header file(s) issue needs to be addressed.

  sr> I don't think that "config.h" is the problem, actually: that file
  sr> mostly contains system-compatibility stuff.  If I were building a
  sr> module outside of fvwm, I'd have it autoconf'd, and would have my
  sr> own config.h.

First, I don't want to make that requirement.  Sure, maybe we'd autoconf
it but not everyone will.  If it's just a little module with a .c and a
man page, why bother?

Second, autoconf'ing would require that the person doing it have some or
all of the configure.in stuff in fvwm2, since so many of the headers
_assume_ that various things will be included and set by the config.h
file.  I think that's a heavy burden for any given private module to
meet.

I'd much prefer to have fvwm install the header info it requires, then
everyone can use that.  I suppose there's a possible issue if the module
_does_ use autoconf, then there might be conflicts.  Well, we can think
about that.

  sr> The headers that need to be installed would be some or all of
  sr> libs/*.h and fvwm/*.h.  It would be best, of course, if the
  sr> installable ones were all in libs/ but for some reason "module.h"
  sr> is in fvwm/.

I would _hope_ that this project could collect the "important" header
info into one file, fvwmlib.h.  Or, maybe two: fvwmlib.h and config.h or
a renaming of that, for config info.

---

From: [email-masked] (Paul D. Smith)
Date: 13 Jan 1999 09:39:24 -0500

%% Chris Rankin <[email-masked]> writes:

  cr> Is there a way that "make install" could generate a new fvwmlib.h
  cr> header using the current config.h and the preprocessor or some
  cr> other tool? I've seen a lot of packages that seem to generate
  cr> header files out of fragments at configure time. Is this any
  cr> different?

Sure, that's not too hard.  Not sure if it's the best way, but
definitely an option to keep in mind.

---

From: Steve Robbins <[email-masked]>
Date: Thu, 14 Jan 1999 00:56:34 -0500 (EST)

On 13 Jan 1999, Paul D. Smith wrote:

> [ ... ] all things being equal it'd be nice to

I see.  I was arguing the shared case assuming that fvwm would use a
shared library.  

But these are details.  We can let the installer decide whether to link
statically or not.  And if the library is fvwm-heavy, then it can be
split. 

> it but not everyone will.  If it's just a little module with a .c and a

Uh, for portability reasons, perhaps?  

On the other hand, if it's small enough that portability is not a problem,
then config.h shouldn't be missed.

> file.

I think this can be changed.  Any installed headers should only provide
the definitions and prototypes for stuff in the library.  Nothing more.

> info into one file, fvwmlib.h.

Agreed.  I'm sure it can be collected, with system-dependent stuff
stripped out, into one or two files.

Here's the problem that I forsee with installing anything derived from
config.h.  That file describes the state of the system *at the time that
fvwm was configured*.  It may or may not describe the state of the system
when you want to build the module! 

For example, maybe you didn't have librplay when you built fvwm, but you
do now.  Should you have to edit some installed header to compile a new
module?

That may be trivial, but what if you've changed compilers in the meantime? 
Or upgraded libraries?  Do all the assumptions of linux's libc5 hold in
libc6?  (I don't know)  Maybe you didn't have memcpy(), but now you do. 
Maybe your new compiler has defines for pid_t, off_t, or size_t, where it
didn't before.  Or maybe the locking interface changed from lockf() to
flock() or to some wacky fcntl().  [Yes, I know that there is no locking
used in fvwm ... yet.  I just put this in because it is nearly a real-life
example; linux's kernel changed from having flock & fcntl locks
cooperating, to having them independent.  After such a change, you'd need
to make sure everything used the same locking style.]

You can probably dream up even more outrageous examples: fvwm compiled on
SunOS 4, but now running on solaris, using sunos compatibility libs.  The
config.h is very unlikely to apply to the new situation!  The change from
IRIX 4 to IRIX 5 was nearly as bad.

You might try arguing that these are pathological cases that never happen
in practice.  I dunno.  How do we know what will show up in config.h.in in
the future?  More to the point, why take the risk if we can easily avoid
the issue by not installing configure-derived information? 

This is not a locker room, and that's a surfboard, not a yacht.