Subject: fvwm lib dependances

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 2 Jan 2000 05:30:23 +0200

On 01 Jan 2000, Andrey on other mailing list wrote:

> BTW there are problems with the latest makefile from fvwm2.. cvsup-ing the
> latest dir and trying to compile it on FreeBSD returns an error from the
> makefile.

I had similar problems. Try to `touch fvwm/fvwm.h` in your case.
This should force the problematic files to recompile.

The problem is that the sources in fvwm/ have no direct dependances of
libs/ files. Paul, can you please look for the right solution here?

Regards,
Mikhael.
--
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: Andrey <[email-masked]>
Date: Sun, 2 Jan 2000 01:02:44 -0600 (CST)

> libs/ files. Paul, can you please look for the right solution here?

I hate to disappoint you, but I think this does not fix the problem.. in
my case at least :(

I followed your instructions on a brand new installation of FBSD and
received exactly the same error (the cvs tree was just up-ed, hence it is
the latest code available on the server. No former fvwm files or
dependencies ecisted. 

automake --add-missing only complained of lacking config.h.in file and
aureconf had the same warning.

make itself returned the following:

----paste----
[f2f@hairy fvwm]$ make
make  all-recursive
Making all in libs
"Makefile", line 233: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop.
*** Error code 1

Stop.
-----end-----

/please bear with my bash prompt, included it only to show the complete
command/

Line 233 of the same Makefile sais:

231:    test -z "$(ETAGS_ARGS)config.h.in$$unique$(LISP)$$tags" \
232:       || (cd $(srcdir) && etags $(ETAGS_ARGS) $$tags config.h.in
$$unique
$(LISP) -o $$here/TAGS)

233: mostlyclean-tags:

235: clean-tags:

237: distclean-tags:
238:     -rm -f TAGS ID

I think the problem lies again with the missing config.h.in (line 231) but
i am not ackuainted with the tree and simply lack the knowledge/time to
check the tree against any of the snapshots (latest being 28.12.99) that
compile without any problems :)

Hope that helps at least a bit...

Unfortunately I am not subscribed to this list and cannot fillow the
discussion. Please e-mail any requests for further actions you may wish me
to perform in order to fix this (ie additional debugging ;)

Regards: Andrey

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 2 Jan 2000 15:02:10 +0200

> aureconf had the same warning.

This is a warning, it should be ignored if ./configure is created.

> 232:       || (cd $(srcdir) && etags $(ETAGS_ARGS) $$tags config.h.in $$unique $(LISP) -o $$here/TAGS)

I believe, the problem here is in libs/Makefile, not Makefile.

232: DEPS_MAGIC := $(shell mkdir .deps > /dev/null 2>&1 || :)
233: 
234: -include $(DEP_FILES)

Just to be sure, do you use GNU make on your FreeBSD? Which version?
I am asking because I can't reproduce this error on my GNU system.

Regards,
Mikhael.

---

From: Andrey <[email-masked]>
Date: Sun, 2 Jan 2000 14:46:25 -0600 (CST)

[snip]
> I am asking because I can't reproduce this error on my GNU system.

I was using the standard make that came up with FreeBSD (sorry, can't find
how to display version information :)...

Adding gmake from the ports and compiling with it (without any other
modifications) seemed to do the job for me. 

Still don't know why it wouldnt compiile with the (non-GNU I presume) make
though.

Thanx for helping :)

Keep up the good work guys :)

Regards: Andrey

---

From: "Paul D. Smith" <[email-masked]>
Date: 03 Jan 2000 13:14:04 -0500

%% Andrey <[email-masked]> writes:

  >> I am asking because I can't reproduce this error on my GNU system.

  a> I was using the standard make that came up with FreeBSD (sorry,
  a> can't find how to display version information :)...

  a> Still don't know why it wouldnt compiile with the (non-GNU I
  a> presume) make though.

If you compile from CVS you _must_ use the proper autoconf/automake
toolset.  This means you need GNU make, GCC, GNU m4, etc.

If you build a snapshot or a distribution tarball, you don't need any
particular make: any make should work.

-- 
-------------------------------------------------------------------------------
 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.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: "Paul D. Smith" <[email-masked]>
Date: 05 Jan 2000 10:56:28 -0500

%% Mikhael Goikhman <[email-masked]> writes:

  mg> The problem is that the sources in fvwm/ have no direct
  mg> dependances of libs/ files. Paul, can you please look for the
  mg> right solution here?

The original problem was due to using the wrong make, but can you give
me more info on your issue, Mikhael?

I don't think there should be any need for direct dependencies on libs
files (if I understand what you mean here) and indeed, things work
correctly for me (if I change a header in libs and build from the top,
all the proper files in other directories like fvwm do rebuild).

Thx.

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 5 Jan 2000 23:35:14 +0200

> all the proper files in other directories like fvwm do rebuild).

I have fixed compilation of the CVS from 30 Dec by doing something
equivalent to `touch fvwm/fvwm.h`. Thus my guess was that there are
situations, when indirect dependances (.deps) are not enough.
The problem itself was related to new constants in libs/defaults.h.

Regards,
Mikhael.

---

From: "Paul D. Smith" <[email-masked]>
Date: 14 Jan 2000 15:57:36 -0500

>> all the proper files in other directories like fvwm do rebuild).

  mg> I have fixed compilation of the CVS from 30 Dec by doing something
  mg> equivalent to `touch fvwm/fvwm.h`. Thus my guess was that there are
  mg> situations, when indirect dependances (.deps) are not enough.
  mg> The problem itself was related to new constants in libs/defaults.h.

I don't know how that can be.

GCC will report a dependency on a header for every file that includes
it, directly or indirectly.  Make will rebuild any target which depends
on a file that's newer than the target.

The next time you see something like this, please check the .dep/xxx.P
file for the file that didn't get recompiled and see if the reference to
the header in question is there.

Also, are you working on a local filesystem or an NFS-mounted
filesystem?  If the latter, check the system times between your local
system and the server and make sure they're the same (down to the
second... or better!)