Re: [Boost-build] [PING] State of PCH/msvc

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-04-27 03:56:41

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 -> [ASM|OBJ] 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/onm00200471ave/direct/01/