State of PCH/msvc

NOTE: All of this is me rambling and brainstorming for the
future direction
of BB for the Python port and beyond, so if I start talking
nonsense, I
apologise.

Volodya wrote:
> On Wednesday 26 April 2006 20:44, Reece Dunn wrote:
> 
> What kind of "core" support for PCH files
do you think is necessary?

When we added the PCH support, the PCH_FILE and related
variables
needed some core adjustments to prevent them from being
propagated
by BB. These would make sense as non-propagated properties.

It has also been reported that in the presence of PCHs,
properties need
to be propagated *up* the build graph as well as down. At
the moment,
the way properties are propagated is fixed (downstream).

Having a more flexible properties mechanism would then allow
for more
powerful constructs - I have an example use case but can't
remember it
at the moment.

> > There are also several things that I would like to
see BBv2 or BBv3
> > support. With compilers, you can get them to
generate preprocessed
> > output and generate the assembly instead of object
code. This is not
> > currently supported in BBv2. The chain would look
something like:
> >
> >    CPP -> PreProcessed-CPP -> ASM -> OBJ
> 
> I think that supporting this would be a matter of
adding new features and 
> adjusting CPP->OBJ generator for compilers that
support this model.

Yes, that is entirely possible. I just wanted to raise that
for the future direction
of BB so that if there is a more generic mechanism to add
custom chains and
multi-pass builds (needed for the CPP -> pre-processed
-> [ASMBJ]
transforms).
Also, some compilers like Borland have an external toolset
for preprocessing.

> > Also, it is not possible to support different
build models (e.g. Java/C#
> > compile everything in one pass) 
> 
> Yes, we basically did not have anobydy work on Java/C#
so even requirements 
> are not written down.

Exactly. So I am reraising it here so that this model is
thought about.

> > or support orthogonal toolsets. What 
> > I mean by orthogonal toolsets is performing a
build that uses msvc for
> > C++ compilation and WiX for MSI/Installer
generation.

Expanding on the preprocessor side, WAVE behaves like a C++
toolset, so you could
have:

   using wave : $(BOOST_ROOT)/bin/wave ;
   using msvc : 7.1 ;

   $ bjam msvc+wave

So that wave is used for the preprocessor. I have no idea
how this will look, I am
just trying to examine various use cases and scenareos.

> And what is wrong with that? 

I would like to just run bjam *once* to perform the entire
build.

As another example, whast if I have a C++ component for
Python and some
Python sources I want to compile to executable form. As a
user, I would want
to build both in one pass.

C++/CLI and .NET allow you to mix C#, VB.NET, J#.NET and
C++/CLI source
code and link them *into the same executable*. The
non-C++/CLI languages
could share the same toolset model, but then it would be
difficult to get C#
and J#.NET sources building to the same executable.

My thinking is to keep the toolset model where toolsets are
mutually exclusive,
but make the exclusivity to a specific *language*. That
would allow you to
build C# code and Python code in the same pass, as well as
allowing C++
code and installer code to be built in the same pass.

Therefore, the preprocessor could be a separate language
(you would need to
be able to specify multiple languages at once in the
property -> compiler
options mappings for this to work and have some sort of
priority when using
gcc for preprocess and compile or wave+borland for
preprocess+compile).
There are other issues with this, but I'm rambling .

> > My current thinking is to work out what is needed
by all of these and
> > how to make them fit into the BBv2 view of the
world, but rework
> > BB (for bbpy?) to add direct support *from the
ground up* rather
> > than providing a hack that uses several kludges to
get these working
> > (like is currently done with PCH). 
> 
> It's perfectly reasonable to adjust architecture to
better support things like 
> PCH. But without specific suggestions there's not much
we can discuss 

See my ramblings here .

> > This will be easier to do in Python 
> > where we are not restricted by the action/rule
model from Jam 
> 
> I think that the action/rule model from Jam is the
least problematic part. Can 
> you say that exactly is wrong with that?

The thing I was thinking about was having:

msvc.link.dll DEF_FILE ( ... )
msvc.link PCH_FILE ( ... )

that repeat code. Also, what about the various permutations
for each. Adding
another thing like this would be complex. And, because the
actions don't get
run via Jam, it is complex to do things genericly like
capturing output from the
test framework.

I have a version of command.run that uses Python 2.4
subprocess and will
capture stdout, stderr and run the process without going via
the shell. This
would be implementable if the rule/action was one unit (e.g.
run) that was
executed in Pythonland. For example:

   def run( testfile, args=[], input=[] ):
      cmd = [ testfile ]
      cmd.extend( args )
      capture, exitCode = command.run( cmd, input )
      if exitCode:
         open( '%s.log' % testfile, 'w' ).write(
'\n'.join( capture ))
      return exitCode

How difficult is this to do currently in BBv2? (That is
rhetorical )

> > and 
> > have a richer *native* set of types.
> 
> That's one reason of the Python port, anyway.

Exactly.

- Reece
____________________________________________________________
_____
Express yourself instantly with MSN Messenger! Download
today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471
ave/direct/01/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build