Subject: autoconf gnumake version problem?

From: Dan Espen <[email-masked]>
Date: Mon, 02 Nov 1998 11:33:59 -0500

My build of 2.1.0 went OK at home on a Sparc  1+, Solaris 2.5.1, using
gcc.  I didn't check why yet, but I have  a working g++, but configure
said it didn't work, so I just compiled with --without-cxx.
(I will find out why.)

I built from a parallel directory, not within  the source tree.  Sun's
make didn't cut it, but gnumake 3.75 did fine.

I'm now  trying the same  thing at work, Ultra  5,  Solaris 2.6, Sun's
compiler.  Same attempt  to build outside the  source tree.  This time
configure says both   C and C++  work.   Sun's make isn't   happy, and
gnumake won't work either.  At work I seem  to be on an older gnumake,
(3.63).

The error I get is:

fork> gnumake   
gnumake  all-recursive
gnumake[1]: Entering directory `/u/tools/dane/fvwm/build_version-2_1_0'
Making all in libs
gnumake[2]: Entering directory `/u/tools/dane/fvwm/build_version-2_1_0/libs'
Makefile:219: *** missing separator.  Stop.
gnumake[2]: Leaving directory `/u/tools/dane/fvwm/build_version-2_1_0/libs'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory `/u/tools/dane/fvwm/build_version-2_1_0'
gnumake: *** [all-recursive-am] Error 1

Here is the stuff around line 219 in the libs directory:

DEPS_MAGIC := $(shell mkdir .deps > /dev/null 2>&1 || :)

-include $(DEP_FILES)

mostlyclean-depend:

Line 219 is the -include.

I have a copy of 3.75 here, so I'll try that.

--
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: 02 Nov 1998 13:21:29 -0500

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

  de> Sun's make isn't happy, and gnumake won't work either.  At work I
  de> seem to be on an older gnumake, (3.63).

  de> -include $(DEP_FILES)

  de> Line 219 is the -include.

GNU make 3.63 is too old; that version didn't support -include.

-- 
-------------------------------------------------------------------------------
 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: Dan Espen <[email-masked]>
Date: Tue, 03 Nov 1998 10:26:57 -0500

> GNU make 3.63 is too old; that version didn't support -include.

OK, a new version of gnumake restarted my adventure.

I found that  for what I am  trying to do,  (build outside the  source
tree), Sun's compiler is definitly out.  At least SunPro3.0:

/opt/SUNWspro3.0/bin/cc -DHAVE_CONFIG_H -I. -I../../version-2_1_0/libs\
  -I.. -I../../version-2_1_0  -I/opt/public/include \
  -g -c ../../version-2_1_0/libs/GetFont.c
command line: fatal: invalid arg for option M  D: No such file or directory
cc: acomp failed for ../../version-2_1_0/libs/GetFont.c

I think  this might have  something to do  with the compiler trying to
come up with dependency information.

I finally got a working version with gcc/g++.

I would have liked to get the modules  and fvwm2 in the same directory
but  I couldn't figure out the  right options for config to accomplish
it.     The are  both    platform/release  specific binaries,  I'm not
understanding why they can't installed in the same place.

I used:

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

The other   problem  I had  is  with   "-R".   Like lots  of   Solaris
installations, we don't have XPM installed in the Solaris directories,
so I    used "--with-xpm-library"  and  "--with-xpm-includes".   I was
hoping that config would take the xpm library and apply the "-R" to it
automatically, but as I found out,  it didn't.  I probably didn't need
to  include /usr/openwin/lib  in  "--x-libraries", but  I wanted to be
sure fvwm2 would look in /usr/openwin/lib first.

I can live with these 2 issues, just thought I'd mention them.

All and all, I'd say the "autoconf" change is a definite improvement.

> -- 
>  Paul D. Smith <[email-masked]>

---

From: [email-masked] (Paul D. Smith)
Date: 03 Nov 1998 12:21:44 -0500

de> I found that  for what I am  trying to do,  (build outside the  source
  de> tree), Sun's compiler is definitly out.

Hm.  Yes, if you want to build from CVS source you likely need GCC (and
GNU make).  If you examine the makefile you'll see that the actual rule
run is different than the one printed: it adds GCC specific options that
allow for dependency tracking (as you surmised).

The Automake manual sez:

  Automatic dependency tracking
   ...
     Currently this support requires the use of GNU `make' and `gcc'.

I don't think it has anything to do with building in or out of the
source tree, per se.  Definitely if you want to build out of the source
tree you need GNU make, both for the CVS source and the distribution
tarball.

You can, though, turn dependency tracking off.  One problem is you won't
get dependency tracking, and the other problem is you have to modify the
Makefile.am file to do it :(.  The manual sez:

     Automatic dependency tracking can be suppressed by putting
  `no-dependencies' in the variable `AUTOMAKE_OPTIONS'.

That sucks because you might forget to change Makefile.am back before
committing your changes :-/.

  de> I would have liked to get the modules and fvwm2 in the same
  de> directory but I couldn't figure out the right options for config
  de> to accomplish it.  The are both platform/release specific
  de> binaries, I'm not understanding why they can't installed in the
  de> same place.

The idea is that fvwm2 goes into a bin directory everyone has on their
PATH (like /usr/local/bin), and the modules don't go there because
they're not directly executable but instead invoked as subprocesses.
These kinds of "helper programs" go in libexec so they're out of the
way.  Anyway, that's the GNU guidelines; they do it this way rather than
the "package" method Sun, etc. use where each package goes into its own
subdirectory under /opt (or whatever).

With Emacs, for example, the "emacs" executable goes in /usr/local/bin
but all the helper apps like movemail, etc. go in libexec/emacs.

  de> The other problem I had is with "-R".  Like lots of Solaris
  de> installations, we don't have XPM installed in the Solaris
  de> directories, so I used "--with-xpm-library" and
  de> "--with-xpm-includes".  I was hoping that config would take the
  de> xpm library and apply the "-R" to it automatically, but as I found
  de> out, it didn't.

I'd say this is a bug; any -L paths specified to configure should be
turned into -R options on those systems which require that.  One day
maybe we'll have readline shared libs, etc., too.

---

From: Steve Robbins <[email-masked]>
Date: Tue, 3 Nov 1998 12:45:01 -0500 (EST)

> come up with dependency information.

Yes, very likely the problem is with the dependency-tracking, NOT with
building in a separate dir.  

I guess it bears repeating:

	*** If you pull sources from CVS, you will need GNU gcc ***
 
The ability to build outside the source tree is a completely separate
issue, and has to do with how your make handles VPATH, I think.  Gnu make,
of course, works, and I think some vendor makes also work.  I know that
IRIX make loses, but I thought sunos' make worked. 

> I finally got a working version with gcc/g++.

So now you can do "make distcheck" with gcc.  All the dependency-tracking
stuff is gone from the tarball's Makefile.in's, so you can use it to check
if your vendor compiler & make will build it.

>   --libexec=/opt/public/src/fvwm.version-2_1_0 \

Here's one way to get them both in the same place:

    configure --bindir=/opt/public/src/fvwm/2.1.0 \
	      --libexecdir=/opt/public/src

Note that the option is 'libexecdir', not 'libexec', and that at present
"fvwm/${VERSION}" is added to it to form the module directory.

[The other way is to specify FVWM_MODULEDIR=/bla during the "make" and
"make install" commands.]

Would people prefer a "--moduledir" option for configure that defaults to 
the current ${libexecdir}/fvwm/${VERSION} ?

How about a "--configdir" option for the default location of
"system.fvwm2rc"?

--
Steve Robbins                              <[email-masked]>

Don't play cards with the Devil.  He'll deal you an awful hand.

---

From: Steve Robbins <[email-masked]>
Date: Tue, 3 Nov 1998 14:40:12 -0500 (EST)

> maybe we'll have readline shared libs, etc., too.

Does anyone know the portable autoconf-way to do this?  Would libtool
solve this problem? 

Standing on the beach with a gun in my hand
staring at the sea, staring at the sand ...

---

From: Dan Espen <[email-masked]>
Date: Tue, 03 Nov 1998 15:41:03 -0500

> 	      --libexecdir=/opt/public/src

Works to my satisfaction, thanks.

> "make install" commands.]

Doesn't  seem ideal  but  thanks for reminding  me, whatever configure
sets up, make is going to let me have my way with.

> the current ${libexecdir}/fvwm/${VERSION} ?

Yes, please.  That seems much more straight forward.

> How about a "--configdir" option for the default location of

Yep.

I currently do icons by hand.  My fvwm2 shell exports FVWMICONS and my
users .fvwm2rc's have  "PixmapPath $FVWMICONS".  The point  being, the
icons need installation too.