Re: urgent help on Makefile

[Paul D. Smith]

%% Yin Lei <address@hidden> writes:

  yl> On Sun, 6 May 2001, Paul D. Smith wrote:

  >> This can't work, because you can't put make commands (like variable
  >> assignments) inside a command script.  The command script is passed to
  >> the shell and run there,

  yl> Thanks a lot, Paul. :)

  yl> Actually, in version 3.79 or above, It's so called "Target-specific
  yl> variable assignment" and it works.

Target-specific variable assignments were added in GNU make 3.77.

I know, I was the one who wrote the code :).

  yl> $(MODULE_LIST):%:
  yl>   override MOD_SUBDIRS    = $(sort $(filter-out /%,\
  yl>                           $(shell cat module/mods.$*)))
  yl>   override MOD_ARCH_FILES = $(foreach file,$(MODULE_SUBDIRS), \
  yl>                           src/$(file)/$(ARCH)/$(notdir $(file)))
  yl>   override MOD_ARCH_OBJS  = $(MOD_ARCH_FILES:%=%.o)

These are _NOT_ target-specific variable assignments.

These are a syntax errors, since those aren't valid shell commands
(unless you happen to have a UNIX command "override" on your PATH, I
suppose).

A target-specific variable assignment uses a syntax like:

  target: <variable assignment>

E.g., no newline/TAB between the target and the variable assignment:
they go on the same line as if the variable assignment was a
prerequisite.

Also, you can't use this with static pattern rule syntax.

  yl> $(MODULE_LIST):%:

This isn't really useful; it means just the same thing as writing:

  $(MODULE_LIST):

without using static pattern rules, so you might as well not bother.
Plus the non-static pattern rule version is somewhat more efficient to
parse for make.

  yl> if there is two module definitions:
  yl>   proj1:  sa, sb
  yl>   proj2:  sc, sd

You don't want commas.

  yl> In fact, this way is not good because there is no dependent rule
  yl> for making objective files, except write a seperate makefile for
  yl> each sub-directories. And in this makefile, if there is anything
  yl> wrong in sub-directory, the make will keep going. So it is hardly
  yl> for locating error.

You are all over the map here.  Originally you are talking about how to
have multiple lists of objects, now you're talking about other things.
Please try to constrain yourself to solving one problem at a time :).

I don't know what you mean by: "no dependent rule for making objective
files", so I can't say much about that.

As for the subdirectory thing, you should not build subdirectories in
loops like that, for exactly the reason you state.  Instead, use normal
target/prerequisite syntax like this:

  $(MODULE_LIST): $(MOD_SUBDIRS)

  .PHONY: $(MOD_SUBDIRS)
  $(MOD_SUBDIRS):
        $(MAKE) -C $@

There's some information in the GNU make manual for doing this kind of
thing.

  >> Even if it were, values set in a subprocess like a shell cannot
  >> affect the parent process.

  yl> Yes, exactly as what you said. :) sigh. This is the problem.

But, the real problem is that the commands you wrote won't even work in
the first place, as I said above.

  yl> The problem is: when you add a new project/executable file. you
  yl> have to re-write a makefile for this project and add project name
  yl> into module list of main Makefile. It's a tedious work, and is not
  yl> user friendly.

You will have to add the project name _somewhere_.  If you get it to the
point where all you have to do is add a new project (or directory or
whatever) to a single variable value, that's as good as you can get, and
better than most.

Don't be tempted to do things like use shell commands with "find ..." to
automatically locate all the things to be built!  This is Very Bad
Design (IMO).  You must require the user to actually explicitly list the
things he or she wants built, in some manner.

  yl> On the other hand, this way still has problem. If you include
  yl> "proj1.mk, proj2.mk, proj3.mk", the variable "SRC" will be
  yl> overrided. So I am afraid that it will not work.

Well, you never said you needed to preserve the value of SRC; what do
you need it for?

If you do need to preserve it you'll have to resort to dynamically
constructed variable names.

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