Subject: -include

From: "Todd T. Fries" <[email-masked]>
Date: Sun, 15 Nov 1998 02:53:17 -0600

Could the 'powers that be' that control the configure sources consider
how to cause the following effect in some mannerism or another?

I know it's not optimal, some better way should be used to generate
dependencies, or perhaps having a single file like the Imakefiles used
to.

The reason I make this request is that for non gmake based systems,
the one line in almost every makefile that prevents another make
binary from working is the one I've commented out below.

I see it's not in Makefile.am so I can only conclude something in
gnu's automake script causes the '-include $(DEP_FILES)' line to
be put in there.

Thanks,
-- 
Todd Fries .. [email-masked]

$ diff -u Makefile.orig Makefile
--- Makefile.orig       Sun Nov 15 02:50:16 1998
+++ Makefile    Sun Nov 15 02:46:36 1998
@@ -221,7 +221,7 @@

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

--include $(DEP_FILES)
+#-include $(DEP_FILES)

 mostlyclean-depend:

--
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: Sun, 15 Nov 1998 10:36:01 -0500

> gnu's automake script causes the '-include $(DEP_FILES)' line to

Heres an opinion.

The  various UNIX  vendors   implementations of  "make"  are  horribly
incompatible.  If   you want to be portable,    vendor makes should be
avoided like the plague.  If you  need portability, and attempt to use
vendor makes, you  will be restricted to a  very small subset of  make
functionality.

"gnumake"  is the solution.  You may  not be able  to install it using
the executable name "make"  as it won't always  work as a  superset to
the vendors make, but its very worthwhile installing it and using it.

--
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: Maciej Stachowiak <[email-masked]>
Date: Sun, 15 Nov 1998 12:20:13 EST

> the vendors make, but its very worthwhile installing it and using it.

More appositely, I believe only developer Makefiles generated by
automake require GNU make, not the Makefiles generated by `make
dist'. Personally, I think it is eminently reasonable to require
developers to have gmake if the distribution itself works with
least-common-denominator vendor `make'.

 - Maciej Stachowiak

---

From: "Todd T. Fries" <[email-masked]>
Date: Sun, 15 Nov 1998 13:17:12 -0600

> the vendors make, but its very worthwhile installing it and using it.

The reason I requested the above is because earlier versions of fvwm
were incorporated into the tree in OpenBSD under the X11 subdir.  Now
what does this matter?  OpenBSD developers need to rely on their own
tools.  If I cannot build fvwm with gmake I will be faced with two
alternatives:

  1) write what we call 'Makefile.bsd-wrapper' which will be used
     instead of the regular makefile.  aka re-implement the makefile
     just so it doesn't require gmake
  2) convince someone that this one little fix is worth it.

X makefiles WERE compatible with everyone's make programs.  I don't
see why we have to loose bigtime just because configure is used.
-- 
Todd Fries .. [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: "Todd T. Fries" <[email-masked]>
Date: Sun, 15 Nov 1998 13:30:07 -0600

> least-common-denominator vendor `make'.

I am confused.  I, as a developer, on my OpenBSD machine, must use
gmake, but then when someone else wants to use it, magically, my 'native'
make program will work?

I thought development involved testing and verification that the entire
build process worked, including the makefiles.

How can we build development versions with one set of makefiles and
then distribute yet another?

I'm utterly confused.  Please elaborate.

---

From: Steve Robbins <[email-masked]>
Date: Sun, 15 Nov 1998 15:06:03 -0500 (EST)

> gmake, but then when someone else wants to use it, magically, my 'native'

Yes.  That's the magic of automake.
 
Both "developer" and "installer" makefiles are built from the same
Makefile.am input files.  The major difference is that the latter include
dependency information *in the makefile*, while the former *generate* said
dependency info.  Hence, the distributed makefiles don't need any of the
"include" lines. 

> build process worked, including the makefiles.

Sure.  Automake very helpfully includes a "make distcheck" rule for this
very purpose!
 
> I'm utterly confused.  Please elaborate.

<li>Auto* tools
  <ul> 
  <li><a href="http://www.amath.washington.edu/~lf/tutorials/autoconf/">
  Tutorial</a> on autoconf and automake</li>
  <li><a href="http://www.cyclic.com/cyclic-pages/autoconf.html">Autoconf,
  Automake, and libtool information</a></li>
  <li><a href="ftp://ftp.cygnus.com/pub/tromey/">Automake</a>
  distribution site</li>
  <li>Automake <a href="http://www.cygnus.com/ml/automake/">mailing
  list</a> archives</li>
  </ul>
</li>

--
Steve Robbins                              <[email-masked]>

Speeding motorcycle ... won't you take me ...

---

From: "Todd T. Fries" <[email-masked]>
Date: Sun, 15 Nov 1998 14:09:25 -0600

> Sure.  Automake very helpfully includes a "make distcheck" rule for this

Hmm, I am now clear on how things work.  But this is called asking to shoot
ones self in foot.  How many people know about the obscure 'make distcheck'
and how many are going to try it just for kicks and grins?

I bet we have someone who tests something as a developer makefile, then
it breaks in the final makefile.  I don't understand the philosophy of
building/developming with one set of makefiles and having others 'the people
who need to be given a good impression' with untested Makefiles.  Sounds
like an accident waiting to happen.  But I guess it is something that
is supported.  Oh well.  Just seemed strange to me.

So now I have to:
cd fvwm
cvs update -PAd
gmake dist
cd ..
tar xvzf fvwm/fvwm-2.1.x.tar.gz
cd fvwm-2.1.x
./configure .........
make

Every single time I want to build the latest version with my own make
program?  Whee.

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 15 Nov 1998 15:25:24 EST

> Yes.  That's the magic of automake.

[ snip excellent explanation ]

I was going to reply, but Steve explained it better than I could have.

 - Maciej
 
PS how did Todd's post get to the list? The only copies I got were
addressed to me personally and had no cc's...

 - Maciej

---

From: "Todd T. Fries" <[email-masked]>
Date: Sun, 15 Nov 1998 14:16:55 -0600

> dependency info.  Hence, the distributed makefiles don't need any of the

The magic didn't work.

I did the 'gmake dist' which created fvwm-2.1.2.tar.gz.
I extracted fvwm-2.1.2.tar.gz and cd'ed into fvwm-2.1.2
I ran './configure --prefix=/sw/pkgs/fvwm' and then I typed 'make' and
I got this:

todd@LightHouse:~/src/fvwm/f/fvwm-2.1.2(45)$ make
make  all-recursive
Making all in libs
"Makefile", line 224: Need an operator
Fatal errors encountered -- cannot continue
*** Error code 1

Stop.
*** Error code 1

Stop.
todd@LightHouse:~/src/fvwm/f/fvwm-2.1.2(46)$

Same error I got before.  Am I missing something or does it not work still?

---

From: [email-masked] (Paul D. Smith)
Date: 15 Nov 1998 16:22:21 -0500

%% "Todd T. Fries" <[email-masked]> writes:

  ttf> Hmm, I am now clear on how things work.  But this is called
  ttf> asking to shoot ones self in foot.  How many people know about
  ttf> the obscure 'make distcheck' and how many are going to try it
  ttf> just for kicks and grins?

How many people will build an official FVWM release dist?  Only one (per
release).  So this isn't a serious problem.

  ttf> I bet we have someone who tests something as a developer
  ttf> makefile, then it breaks in the final makefile.

This is _extremely_ unlikely, since developers don't write makefiles,
they write (or more likely, add to existing) Makefile.am's, which are
fairly trivial.

Yes, it can break, but that's why the developer's tree is not gauranteed
to work.  Before it goes out someone with the appropriate knowledge will
test it and find the problem.  At least, that's just as likely as if
someone were writing makefiles from scratch.

  ttf> I don't understand the philosophy of building/developming with
  ttf> one set of makefiles and having others 'the people who need to be
  ttf> given a good impression' with untested Makefiles.  Sounds like an
  ttf> accident waiting to happen.  But I guess it is something that is
  ttf> supported.  Oh well.  Just seemed strange to me.

The makefiles are _almost_ exactly the same; the differences are
essentially (a) the include line is replaced with the contents of the .d
files, and (b) the compilation lines don't have the special commands to
build the .d files.  Certainly there are no differences in the parts of
the makefiles that developers write.

Anyway, remember that all these makefiles are auto-generated from
Makefile.am so typically there's very little "user-error" that can
occur.

  ttf> So now I have to:
  ttf> cd fvwm
  ttf> cvs update -PAd
  ttf> gmake dist
  ttf> cd ..
  ttf> tar xvzf fvwm/fvwm-2.1.x.tar.gz
  ttf> cd fvwm-2.1.x
  ttf> ./configure .........
  ttf> make

  ttf> Every single time I want to build the latest version with my own make
  ttf> program?  Whee.

You misunderstand the environment.

The CVS tree and the build it uses is meant for _developers_ who are
_developing_ fvwm.  If you decide you would like to be a developer and
keep up with all the latest changes as they're checked in, then yes,
it's a requirement that you have available all the required tools (those
being at least GNU make, and maybe GCC too).  In this case, you would
typically never (or hardly ever) build a dist yourself; you just compile
the source tree as-is because you have the tools.

If you don't want to do that, you can get the packaged tar files as
they're made available, both the release and beta versions.  These
require no special tools to build; any make and compiler will do.

These are the choices, and you need to decide what category you're in.
The idea is that if you're willing to go to all the hassle of keeping
up-to-date with the latest sources, etc. then using GNU make is the
least of your hassles :)

Essentially, no one should be handing out random selections of source as
a "distribution" using make dist.  There's nothing illegal about it, of
course, but it seems quite dangerous and I'm not sure we should spend a
lot of effort making it easy :)

-- 
-------------------------------------------------------------------------------
 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] (Paul D. Smith)
Date: 15 Nov 1998 17:49:06 -0500

ttf> The magic didn't work.

  ttf> I did the 'gmake dist' which created fvwm-2.1.2.tar.gz.
  ttf> I extracted fvwm-2.1.2.tar.gz and cd'ed into fvwm-2.1.2
  ttf> I ran './configure --prefix=/sw/pkgs/fvwm' and then I typed 'make' and
  ttf> I got this:

  ttf> todd@LightHouse:~/src/fvwm/f/fvwm-2.1.2(45)$ make
  ttf> make  all-recursive
  ttf> Making all in libs
  ttf> "Makefile", line 224: Need an operator
  ttf> Fatal errors encountered -- cannot continue
  ttf> *** Error code 1

  ttf> Same error I got before.  Am I missing something or does it not
  ttf> work still?

I just tried the same thing, using Sun make, and it worked fine for me.
Line 224 in libs/Makefile containts some dependency lines.  There is no
"include xxx" or "-include xxx" in the makefile anywhere.

If this did not work for you, we'll need to debug it.  I've never had
this not work for me.

What version of automake do you have installed?

Hm.  One possible problem is that you _don't_ have automake installed.
The developer's tree doesn't require automake but it _is_ required in
order to build a distribution.  If you don't have automake, a special
script called "missing" is run instead; this allows things to work (it
will touch the files automake would have update, so the make succeeds)
but it obviously doesn't do all the things automake would do... such as
create new makefiles which don't use the "include" feature.