From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-08-29 09:52:52
On Tuesday 29 August 2006 14:52, Reece Dunn wrote:
> Artem Alimarine wrote:
> > Vladimir Prus wrote:
> > > You can run "bjam -n" and then copy-paste the command line and add the
> > > needed option.
> > This indeed sound like a good alternative for a quick experiment with
> > the switches.
> > However, I'll need to do that from time to time, so I wanted to make a
> > target in the jamfile for it.
> It is not really a feasible solution if you need to do it every time you
> build the project, or if you have an automated build.
Don't know, I never had the need to get assembly sources on each build.
> > >>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. In your situation, you would pass something like:
> and you will get an assembly file (.S for gcc; .asm for Windows tools) as
> part of your output.
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.
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.
It might be still better to pass special options to the compiler, as it will
> > However, I do not agree that having a support for assembeler output
> > contradicts with the portability of Boost.Build. Yes, assembler output
> > is platform-specific, but so is object file or executable. All compilers
> > I know can produce assembler. Actually, the difference in the formats
> > and toolsets is one of the things that makes Boost.Build a very good
> > tool, because it helps to abstract from the differences. In the light
> > of this an assembler file is just another target that the user might
> > want to build.
> I agree and as I have said above, I want to generalize this. Note that
> I don't yet know exactly how this would work, or even that I am close
> to a solution, because I am not.
> 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.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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