This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Another paralell make patch for libf2c


In the name of simplifying this discussion, let's assume I'm to blame
for all that's wrong with lib2fc's Makefiles and configure stuff for,
oh, the last year.  That optimizes away the "who's to blame" part of
this episode.  I'll even take the blame for killing the Kennedys, the
Vietnam war, and the Celeron processor.

Now, let's get back to a technical solution for a technical problem.


Craig Burley wrote:

> In short, in an earlier snapshot of egcs, the `all' rule did not
> depend on $(LIBG2C), and, AFAIK, it shouldn't.  But, I recognize that
> I don't have the full picture, not really understanding the new
> multi-lib stuff.  (I should probably have questioned an earlier patch

If you think it shouldn't, we'll pull it.  Basically, when I was working
on the recently reported 'make builds the .o's but not the .a when I
specifiy --disable-multilib' case, I was just trying to synchronize it
against other multlibbed Makefile.in's such as libchill.

This certainly doesn't mean it's right.  Perhaps I tried too hard to
bolt that solution on.  The libf2c Makefile situation is certainly
different becuase of the way it stamps things and builds the toplevel .a
from the child .o's.

> I thought the idea of the pre-multilib libf2c Makefile rules was to
> distinguish its `all' rule from its `$(LIBG2C)' rule -- the former
> being to build .o's, the latter being to build the .a, with the

If that is the desired behavior, I can submit patches to emulate that.

Is the default target desired to be 'all' or '$(LIBG2C)?

If I understand what I think you want, $(LIBG2C) dependens on 'all'.
'all' depends all the child .o's and the four s-blah files.  Three of
the s-blah files are created by descending into the child directories
and doing the make.  It's that fourth case (s-libe77) that tempted me
into the current approach.  I experimented with a number of solutions to
try to make libe77 work like the rest.  This was the closest I got.

If the rule then does the "obvious" thing:

all: i77 f77 u77 s-libe77
        $(MULTIDO) $(FLAGS_TO_PASS) multi-do DO="$(LIBG2C)"

libg2c.a doesn't get built in the main directory, though it does get
built in the multilib dirs.  This means if you have configured while
disabling multilibs, you get no libf2c.a at all.  If you add the
dependency for $(LIBG2C) in there, it works.


This discussion has made it clear that I've plastered over one problem
and created another.   Let's find the original one...


> 	* Makefile.in (all): Correct dependencies do --disable-multilibs
> Also, `do' should be `so'.  My bad for not looking at this more

Yes, it should.   Shall I submit a patch? :-)

RJL


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]