RE: Tricky suffix rule problem for Corba

[Paul D. Smith]

%% "CARTER-HITCHIN, David, FM" <address@hidden> writes:

  >> Given the above makefile and requirements, the following will 
  >> do exactly
  >> what you want:
  >> 
  >> %.h %.cc : ../idl/%.idl
  >> $(MICOIDL) $(MICOIDL_OPTS) $<
  >> 
  >> (assuming that $(MICOIDL) will generate its output in the current
  >> directory, even if the IDL file is somewhere else).

  cdf> This doesn't work - the target is still considered as
  cdf> "../idl/a.h" so any re-make will consider that work needs to be
  cdf> done as it is looking in a place where the headers were not
  cdf> generated.

As I said, GIVEN THE ABOVE MAKEFILE.  If it's not working, then there's
more to your makefiles than you've shown.

If the target is ../idl/a.h, then you have somewhere in your makefile a
prerequisite statement that asks make to build ../idl/a.h.

Remember make starts the build "at the end": it starts at the target you
want ultimately to be created (in this case I suppose the library), and
looks for a rule that will build that target.  Once it finds one, it
tries to find out how to build _THAT_, and so on.

So, if you're seeing make try to build ../idl/a.h, then SOMETHING in
your makefile must list ../idl/a.h as a prerequisite.  After that, make
tries to find out how to build that target, and it sees that the rule
above matches, with a stem (%) of "../idl/", then it also notes that
this works for the prerequisite (because "../idl/../idl/a.idl" does
exist).


In other words, by the time make starts to match the pattern it's
already wrong.  You have to find out why it's trying to build ../idl/a.h
and change THAT so it wants to build just "a.h" instead.

  >> If that's not happening then somewhere in your make environment you
  >> must be explicitly defining some prerequisite relationships between
  >> the .o and .cc/.h files... maybe you have some kind of automated
  >> dependency generator or similar?

  cdf> I'll paste the whole of our rules file below, but there are no
  cdf> other rules which indicate any connection between .cc's and .h's
  cdf> - or at least any that I've spotted.

There are.  There have to be.

  cdf> Here are the rules we use.  If this doesn't show you what the
  cdf> problem is then I can do something else...  you're very kind for
  cdf> all your help, thank you.

As I said, we don't have time to debug your entire make environment.  If
you can't describe it completely you'll have to generate a small,
self-contained test case that shows the problem and we can look at that.
In my experience just going through that exercise will often show you
what the problem is.


I will give you some hints: first, almost certainly this is where your
problem is coming from:

  cdf> # include all the new dependancy files
  cdf> -include $(DFILES)

Look at the content of these dependency makefiles... very likely they
contain the problematic ../idl/a.h.  It may even be that these are just
left over from the build you did before you tried to update the
makefile, and if you just start over without any dependency files (and
the new pattern above) it will work.

You can also use "make -p" to view the entire make database; this will
give you some info on the prerequisites and even where they are
defined.


----- Apropos of not very much, this 23-line signature is incredibly
annoying... and legally completely useless.  The de facto standard
maximum length for a signature is 4 lines, FWIW :-).  At the very least
please reduce the line length to 79 chars or less per line, and please
use the universal signature introduction character sequence, which is
dash-dash-space ("-- ") on its own line just before the sig.

Cheers!

> ***********************************************************************************
> The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered 
> Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
> Authorized and regulated by the Financial Services Authority 

> This e-mail message is confidential and for use by the 
> addressee only. If the message is received by anyone other 
> than the addressee, please return the message to the sender 
> by replying to it and then delete the message from your 
> computer. Internet e-mails are not necessarily secure. The 
> Royal Bank of Scotland plc does not accept responsibility for 
> changes made to this message after it was sent. 

> Whilst all reasonable care has been taken to avoid the 
> transmission of viruses, it is the responsibility of the recipient to 
> ensure that the onward transmission, opening or use of this 
> message and any attachments will not adversely affect its 
> systems or data. No responsibility is accepted by The Royal 
> Bank of Scotland plc in this regard and the recipient should carry 
> out such virus and other checks as it considers appropriate. 
> Visit our websites at: 
> http://www.rbos.com
> http://www.rbsmarkets.com 
> ********************************************************************************

-- 
-------------------------------------------------------------------------------
 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