Re: [jamboost] Re: stage litter reduction?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-29 08:35:49

Hi Larry,

> >> When I run this build for the 'publish' variant, this
> >> warning appears
> >> warning: using independent target <pc:\bin>sinefit.rsp
> >
> > Which V2 version?
>
> (Woops,) I should have mentioned:
> [C:\tmp]
>
> > bjam --version
>
> Boost.Build V2 (Milestone 10)
> Boost.Jam 03.01.10
>
> > Warning is not supposed to be there in m10 or later.
>
> Part of the reason I posted was that I saw a comment to
> the same effect. 
> Also, in stage.jam regarding RSP targets: 
> # By default, we don't install such targets.
> # If specific list of installable types is given, we don't
> # care if target is intermediate or not.

I think the comment is a bit out of date.

> >> and an extraneous .rsp file ends up where only useful output
> >> was intended:
> >> msvc.link c:\bin\sinefit.exe c:\bin\sinefit.rsp
> >>
> >> Is there a way to suppress the warning and eliminate the extra
> >> and unneeded .rsp file?
> >
> > I'm afraid no.
>
> The warning is the most troublesome since it is harder
> to work around. (The work-around is to not use stage.)

Could you provide me with the minimal testcase which reproduces the problem? I 
can't reproduce it on small test.

> > No, it's just a way 'stage' works. The problem is that windows
> > has severe command line length limitations so all compile and
> > link actions use response files.
>
> So, the curse of command.com and cmd.exe continues.
> The command line limitation on NT boxes, as imposed
> by the OS, is more like 32K. It is only the cursed default
> CLI shell that has the severe limit. It would be nice if one
> could say "Look, we use bash, so please do not burden
> this build with legacy from folks who disdain their shell."

This would be good, but then current code expects that respose file is
always created.

> > The response files are consisred regular targets by V2. Finally,
> > the 'stage' rule always relinks the executables to the destination
> > dir, and so it creates respose file in the destination dir, too.
>
> The .rsp files are logically just temporaries. They could
> be considered part of the invocation sequence, having
> no more persistance than a command line usually has.
>
> From the outside looking in, (and into a grand design I
> do not well comprehend, yet), I would think the .rsp
> files would be in a temp directory and exist only due to
> the rule associated with the tool invocation that happens
> to need that kludge. They could be deleted immediately
> after use (except during debugging, maybe) and nobody
> would be the wiser. They especially should not appear
> in dependency logic.

This option is reasonable. The current scheme (where RSP targets are 
explicitly represented) appeared because it was simpler to do without bjam 
changes (which we tried to avoid earlier), and also RSP targets are retained
after building, so that you can look at them.

> Is the need for and appearance of .rsp files localized in
> the toolset rules (except for incidental comments)? 

Yes.

> If so, 
> I am tempted to resolve this by writing a modified set for
> some less limited combination, say bash_msvc. (It bugs
> me to see vcvars32.bat being run during the build.)
>
> > How pressing is this issue?
>
> I cannot claim "pressing". I can, of course, stage to a
> location within the build directory structure and copy
> the useful results where they become (more) useful.

Ok.

> That said, I think a 'deploy' rule would be nice.
>
> > I'll be working on stage for m11, and thinking
> > about making it simply copy executables on windows. This,
> > accidentally, will fix your problem.
>
> I would urge minimal differences between platforms,
> at least at the more abstract levels.

The difference will be that on Linux, executable is relinked when staging, and 
on Windows it's not. This is due the fact that on Linux executables must be 
staged (to change dynamic library paths), and on Windows, no such need 
exists.

> By the way, I must say that I am struck with admiration
> for the specification, design and implementation of BBv2.

Thanks.

- Volodya