Subject: build problems

From: Dominik Vogt <[email-masked]>
Date: Thu, 14 Jan 1999 02:06:50 +0100

I'm wondering why several people are having problems to build
2.1.7 properly. What would happen if they untar the package into
the directory that already holds some previous source and then
don't run 'make clean' before they rebuild or even just 'make'
without running 'configure'?

[after trying just that myself with 2.1.7/2.1.4]

As I suspected the build fails miserably (linkage error). If
this is done between 2.1.5 linking might still work. The code
won't do anything useful though. The sources will not be
rebuilt properly if the object files are still newer than
timestamps of the .c files in the tarball.

Is there anything we can do to detect this condition in the
Makefile? Or in configure? Configure *did* run and generate
new Makefiles. Shouldn't this entail a 'make clean' with
the changed Makefiles?

This is giving us pain enough to warrant some thoughts on
how to avoid that. Perhaps like this:

 - Generate a file 'check_build.c' each time a tarball is
   created. The file contains a single automatically
   generated line:

     char *last_built_package = "last built package: 2.x.y";

 - Give it a timestamp in the computer stoneage:

     touch check_build.c 010101011975

 - When make is called check the check_build.o file for the
   last built version:

     strings check_build.o

   will return the contents of the string

 - If this is not the same version as the current source
   force a 'make clean'. Issuing a warning might not help
   here because we are already building so this will
   most likely be overlooked.

Is this doable with configure and is it worth the effort?
If not, what shall we do then?

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [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: 14 Jan 1999 00:11:13 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> I'm wondering why several people are having problems to build
  dv> 2.1.7 properly. What would happen if they untar the package into
  dv> the directory that already holds some previous source and then
  dv> don't run 'make clean' before they rebuild or even just 'make'
  dv> without running 'configure'?

  dv> This is giving us pain enough to warrant some thoughts on
  dv> how to avoid that. Perhaps like this:

I disagree.  Distributions created the proper way with "make distcheck"
will untar into directories named with version, like fvwm-2.1.7, etc.

Thus distfiles will never untar into a directory that existed previously
and contained existing source code.

The only potential problems are by people getting CVS versions (which
should handle the timestamps correctly) or non-distributed tar files,
who should know better.

-- 
-------------------------------------------------------------------------------
 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: Dominik Vogt <[email-masked]>
Date: Thu, 14 Jan 1999 23:47:53 +0100

> and contained existing source code.

OK, you're right. I was assuming that because it happens on my
system it might affect anybody else (not that I have a problem with it).
 
> should handle the timestamps correctly) or non-distributed tar files,

But I think it's a good idea to create some script that gathers
information about the fvwm2 installation as some other free
software projects do. This way we could tell people to run
this script prior to reporting a bug and include the output
in the report. Part of this might be some tests to verify
the installation went OK.

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 14 Jan 1999 22:52:37 -0500

dv> But I think it's a good idea to create some script that gathers
  dv> information about the fvwm2 installation as some other free
  dv> software projects do. This way we could tell people to run
  dv> this script prior to reporting a bug and include the output
  dv> in the report. Part of this might be some tests to verify
  dv> the installation went OK.

"fvwmbug"?  Sounds good to me.