Re: export not working...

[Paul D. Smith]

%% Christopher J Bottaro <address@hidden> writes:

  cjb> ok, now i'm confused.  i'm looking at some pretty popular linux
  cjb> projects (KDE) and in their makefiles (generated by
  cjb> automake/autoconf)

That's your answer right there.

Automake generates makefiles that work with the least common denominator
version of make, so they can't take advantage of any of the modern
features of GNU make (or any other make).  If you want your makefiles to
work with every version of make and every version of sh out there, no
matter how ancient and crusty, then you'll have to do things similar to
what you see in an automake generated makefile.

Since these makefiles are generated automatically, it doesn't really
matter how long and complicated they are: someone only has to write it
once anyway.

If you're writing your makefile by hand and don't mind requiring
relatively modern tools, like GNU make and a POSIX-compliant shell, you
can avoid most of the hacky stuff in autoconf/automake.

In short, you shouldn't use those files as examples of "best practices"
for writing makefiles.  If anything at all, they're examples of "best
practices" for creating maximally portable makefiles and scripts.  But
as you've seen, maximally portable is in no way equivalent to maximally
maintainable.  That is, after all, why autoconf and automake were
created in the first place.

  cjb> the command lines of the rules are pretty big shell scripts
  cjb> (complete with for loops to do recursive makes).  this seems to
  cjb> be pretty much the standard way to do things it seems.

Depends on what kind of "standard" you want to adhere to.

If you want makefiles that are massively portable then why write them
yourself?  Just use automake in the first place and save yourself a lot
of aggravation.

  cjb> i did a search for "recursive make" and found web articles giving
  cjb> examples of using the shell for loop as the "correct" way of
  cjb> doing it.

It's not the best way.  At least, not for GNU make.

  cjb> why is what seems to be the "accepted standard" the wrong way to
  cjb> do it?

Because I said so, and I know better :).  Seriously, those methods are
OK.  They will work to some extent, but they all have problems.  They
don't obey flags like -k.  They don't work well with parallel makes.
Etc.

If you don't care about those things, then doing it with a shell loop is
fine.  It will work.  Just not as well.

Also, doing it the better ways often requires you to make assumptions
about your version of make, because many of those things can't be done
in "standard" make syntax.

  cjb> $(RECURSIVE_TARGETS):
  cjb>  sh recursive_targets_makefile.sh

First, you're forgetting that the original shell script contained many
make variables.  In the original script, those variables are expanded
into values _BEFORE_ the script is sent to the shell.  Once you're in
the shell script there's no way to get ahold of the values of those
variables (unless you're going to export them--and exporting make
variables is not supported by may versions of make).

So you would have to pass those values on the command line of the
"recursive_targets_makefile.sh" script, which already makes it less
simple.

Second, projects don't really want automake to go around creating lots
of little helper scripts to litter their project directories.

And finally, it works embedded in the makefile so why bother with an
extra file?

  cjb> that way that huge, ugly, multiline command can be tucked away in
  cjb> a shell script...where you don't have to use so many ";"s and
  cjb> "\"s.

Who cares how many ";"'s and "\"'s there are, when the whole thing is
autogenerated?  That's exactly why automake was created, so no one would
have to care how gross these scripts are.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist