Re: [Boost-build] assembler output

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-08-29 13:16:27

Volodya wrote:

> On Tuesday 29 August 2006 14:52, Reece Dunn wrote:
> > Artem Alimarine wrote:
> > > Vladimir Prus wrote:
> > > >>It would be nice to have a portable flag <asm-output>on or a special
> > > >>target type
> > > >>	asm foo.asm : foo.cpp ;
> > > >
> > > > This is probably beyond the portable nature of Boost.Build, if you need
> > > > assembler output you are likely to know the right switches already ;-)
> > >
> > > I relealize that what I asked is not on the top10 of the new requested
> > > features ;-)
> >
> > I would like to implement support for intemediate files. The other one that
> > comes to mind is pre-processed output. My aim is to make it possible to
> > use Boost.Wave as your designated preprocessor and feed that to an
> > msvc, Borland or other C++ compiler backend.
> >
> > At the moment, BBv2 assumes:
> >
> >     CPP --> OBJ
> >
> > where it needs to be:
> >
> >     CPP --> PP --> ASM --> OBJ
> >
> > such that by default the preprocessor (PP) and assembly (ASM) outputs
> > are collapsed.
> 
> I hope we both agree that the transformation sequence you list above should be 
> used only if explicitly requested, as passing files around will be slower.

That's what I meant by "collapsed": if no explicit preprocessor or preprocessed
output is required, the PP stage is skipped (collapsed).

> If so, I don't see any problems, just add necessary generators to, say, 
> msvc.jam, and modify CPP -> OBJ generator to produce nothing if 
> <assembly>generate is specified.

So, something like:

   pp bar1 : bar.cpp : <preprocessor>default ;
   pp bar2 : bar.cpp : <preprocessor>wave ;
   exe foo : bar ;

? Sounds reasonable to me.

> It might be still better to pass special options to the compiler, as it will 
> be faster.

Not sure I follow. Surely you would need to pass the special options to the
compiler to get it to generate preprocessor and/or assembly output. There
are compilers that will only generate output for that phase (e.g. preprocessor)
and not continue, so in these instances, they would need to be invoked
multiple times.

> > At this stage, this is one of the high-level aims that I am thinking about
> > when we decide where to go with BBv3/BBpy. I have created a wiki page
> > that outlines these (the "evolution" page).
> 
> I'm not sure this is so big change.

Adding the preprocessor/assembler support for each toolset should be a matter
of adding the appropirate generators. That is not a problem.

The thing I am not sure about is replacing the default (compiler) preprocessor
and/or assembler with an external tool. For example, how would I replace the
msvc preprocessor (cl -E ...) with Boost.Wave?

There would also be a lot of shared machinery involved (default vs custom
tool for the specified step). NOTE: the big picture I am thinking of is being
able to have a single BB file that contains Fortran code, C/C++ code,
.NET/mono code (including C# code that links in with C++ code into a
single executable) and installer code.

That is where I would like BB to get to in the long term.

- Reece
_________________________________________________________________
Be one of the first to try Windows Live Mail.
http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d