Re: stage litter reduction?

From: larry_brasfield (larrybrasfield_at_[hidden])
Date: 2004-12-29 05:01:29

> --- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> Hi Larry,
Hi, Vladimir, and thanks for your reply.

>> I'm using BBv2 with a spec like this in the topmost Jamfile:
>> stage dist : SineFit :
>> <traverse-dependencies>on
>> <include-type>EXE
>> <include-type>SHARED_LIB
>> <variant>publish:<location>$(deploy_dir)
>> <variant>debug:<location>debug
>> ;
>>
>> (deploy_dir is derived according to platform, environment,
>> invocation etc.)
>>
>> 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.

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

>> Am I misusing the 'stage' rule?
>
> 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."

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

Is the need for and appearance of .rsp files localized in
the toolset rules (except for incidental comments)? 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.

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.

If there will not exist a 'deploy' rule allowing placement
of just what is intended and nothing else, many such
will be written. For a minute, I wondered why my local
boost library installation directory was not full of .rsp
files. Then I realized, it was built with BBv1.

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

--Larry Brasfield