Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-22 05:56:04


David Abrahams wrote:

> OK. Not sure what the problem was, then. I still have the
>
> mv yyacc yyacc.x
>
> in my command history which caused the build to succeed.

It would be very desirable to diagnose it...

> >> 2. generators.try-one-generator is accessing a variable from an
> >> enclosing scope called $(results). I'm fairly certain this is a
> >> bug.

> Sorry, I meant "generators.select-dependency-graph".

Yes, IIRC the 'select-dependency-graph' was extracted from
construct-without-caching and one of the references to results was not fixed.
It should refer 'options', as you've surely guessed.

> > Then you'll have library called "e" created and linked in exe called "e",
> > which is bogus behaviour. In fact, you can remove "d" target altogether,
> > and still get this behaviour.
>
> Yes, good point.
>
> > Hmm.... RSP can be created from STATIC_LIB and from OBJ, so the
> > generators code manage to convert e.cpp both to STATIC_LIB and OBJ,
> > and happily use them.
> >
> > Without your patch applied, everything works okay, becase to create
> > STATIC_LIB you need to run response-file generator for a second
> > time, which is not allowed.
>
> Right. Lucky.
>
> > I've two interpretations of this.
> > 1. There's a bug in generators -- we should use only "OBJ".
> > 2. There's a bug in generators -- we should not produce STATIC_LIB.
>
> I think both of these are true, by different criteria. The first
> one, because the paths are shorter and the same sources are consumed.

We agree, then.

> > In fact,
> > it's the *second* invocation of *composing* generators:
> > builtin.response-file is the first one, and msvc.archive is the second
> > one. If you recall, we used to have "allow-composing" parameter which
> > controlled that. I still think that composing generator in the middle of
> > the search can only be used in special situations.
>
> I think as I mentioned in my previous post that composing generators
> are fine as long as they appear only once on any path from source to
> target. I still believe that. Some systems require you to
> post-process a DLL in order to get an IMPLIB... why should that be a
> problem?

"Previous post"? You previous message was ending abruptly at the example, so I
though it's not finished... oh, now I see that something has decided to put
attachment in the middle, and the rest of your message as another
attachement. I'll reply that soon.

> > And the funny thing is that I believe we have both of those bugs. If
> > would not be hard to produce an example where RSP takes OBJ and
> > FOOBAR, and FOOBAR can be produces from CPP by a sequence of two
> > transformations. In which case, CPP in sources will be converted
> > both to FOOBAR and OBJ. So the first bug exists -- we should error
> > in this case, most probably.
>
> No, I think we should be smarter about which generators are chosen.

What will the user prefer? Smart, but not surely right behaviour, or error,
which must be explicitly disambiguated. The rule that shortest transformation
is choosen is obvious, but it's it reasonable to users?

- Volodya

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk