<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>+1<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As have we. We have CMake wrappers and variable injection to
make it work with our internal build system.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I also agree with the point that others have made – why reinvent
the wheel? You already have use of a dedicated build system tool – Cmake – that
is fit for purpose and while it may not generate *<b>quite</b>* as good a set
of Makefiles as a hand-crafted solution would, is this really important? Is
that 3 seconds of build time improvement really important?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Why not use a well known and respected build system tool like
CMake that all sysadmins know, can hack, and removes the development burden
from LLVM?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Cheers,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>James<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> llvmdev-bounces@cs.uiuc.edu
[mailto:llvmdev-bounces@cs.uiuc.edu] <b>On Behalf Of </b>Rotem, Nadav<br>
<b>Sent:</b> 28 October 2011 15:09<br>
<b>To:</b> Chandler Carruth; Daniel Dunbar<br>
<b>Cc:</b> cfe-dev; LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] [cfe-dev] RFC: Upcoming Build System Changes<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>+1 <o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We build our OpenCL SDK (for windows and Linux) using CMake.
We’ve integrated LLVM’s Cmake hierarchy into our own (customizing
LLVM external parameters like build and install directories, added passes, etc)<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Migrating LLVM’s build system from CMake to something else would
require us to change the way we currently do things. <o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> llvmdev-bounces@cs.uiuc.edu
[mailto:llvmdev-bounces@cs.uiuc.edu] <b>On Behalf Of </b>Chandler Carruth<br>
<b>Sent:</b> Friday, October 28, 2011 03:35<br>
<b>To:</b> Daniel Dunbar<br>
<b>Cc:</b> cfe-dev; LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] [cfe-dev] RFC: Upcoming Build System Changes<o:p></o:p></span></p>
</div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US>I have a very high level comment, and you
may be able to directly shed light on it before I dig into a lot more detail.<o:p></o:p></span></p>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>Why not simply standardize on CMake? It's
not my favorite tool, but it seems to work well, we have established usage of
it, and several people involved in the project who understand how it works. It
doesn't seem like a significantly more burdensome dependency than Python when
developing, and it remains possible to build installable packages for the
casual hacker.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>I can see some objections to CMake, but
it's not clear to me that they should carry the day. I'm also probably missing
some.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>The one I see most clearly is that the
CMake build, as it stands, involves Too Much Magic. I don't at all disagree.
That said, I strongly believe this could be completely addressed.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>- If we moved to CMake as the standard
build system, numerous kludgy aspects of the current build would go away. They
are often in existence purely to support interoperation with the old system.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>- It would be very straight forward to
centralize all of the library dependencies and descriptions in the single
top-level CMakeLists.txt file, making it easily consumable by your average
developer. It would have a format no harder to edit or understand than the one
you propose, and they would both (at worst) be unfamiliar to existing
developers.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>- It would likely improve the quality of
our CMake builds by ensuring it was well tested and always in a consistent
state.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>- It already has a relatively optimized
makefile-generation system, so we wouldn't need to re-invent this wheel again.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>The biggest downside to making CMake the
standard build system is the dependence on CMake to my eyes. However, among the
cross-platform users of LLVM, I think CMake is often the preferred build
system. I know of folks using it under xcode, visual studio, mingw, cygwin, and
all flavors of Linux.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>Anyways, I'm sure there are more
considerations than just these, I just think it would be beneficial to
seriously consider using an existing meta-build system rather than rolling our
own.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>-Chandler<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
<div>
<p class=MsoNormal><span lang=EN-US>On Thu, Oct 27, 2011 at 6:11 PM, Daniel
Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US>Hi all,<br>
<br>
As you might have inferred, I'm in the process of working on some changes to
the<br>
way LLVM builds. I have outlined a rough proposal below, unless there are any<br>
major objections I will probably start committing stuff next week.<br>
<br>
This message may be verbose, if you want the executive summary, skip<br>
to 'What This<br>
Means For Jane "LLVM Developer" Doe' at the bottom.<br>
<br>
Motivation<br>
----------<br>
<br>
We currently maintain two build systems (make, CMake). This has a couple of<br>
problems:<br>
<br>
* Duplication: the two build systems duplicate a significant amount of
implicit<br>
logic (higher level dependencies), some config files, and other
miscellaneous<br>
features.<br>
<br>
* Maintenance: Some parts of the build systems requires regular
maintenance<br>
(the CMake file lists, CMake dependency lists, module structure). Having
one<br>
more thing to maintain is annoying.<br>
<br>
* Inconsistency: The two build systems behave inconsistently in some
ways. If<br>
we want both to officially supported systems, it would be nice for them
to<br>
behave as identically as possible.<br>
<br>
For example, CMake now uses explicit dependencies which are hard coded
into<br>
the CMake files, but the Makefiles work completely differently.<br>
<br>
There are also other general issues with the way LLVM is built now:<br>
<br>
* LLVM has a higher level structure for its organization, but this is not<br>
explicit. LLVM is roughly organized into components (libraries, tools,
etc.)<br>
by directory. It would be nice to have this be more explicit.<br>
<br>
* Much of the project build structure is implicit in the Makefiles or<br>
CMakeFiles. It is not particularly explicit anywhere that, say, parts of<br>
VMCore depend on building the Intrinsics, which depend on building
tblgen.<br>
<br>
* The Make system is not very efficient. We use recursive Makefiles which
make<br>
the current system (relatively) simple in some ways, but mean the Make
build<br>
is not nearly as scalable as it could be. In particular, the current<br>
organization means the built is often serialized on something that is
not a<br>
strict dependency. It also makes it much more likely to do things like a<br>
stampeding link of all the tools, even though many tools could have been<br>
built earlier.<br>
<br>
<br>
Specific Goals<br>
--------------<br>
<br>
* Move both build systems to use explicit library dependencies, in a
clean<br>
fashion. The CMake files do this now, but I don't think it has been made<br>
clear to developers when they are supposed to edit these files, or how
(other<br>
than when something breaks, I guess).<br>
<br>
* Explicitly describe as much of the project structure as necessary to
support<br>
builds. This means explicitly specifying how the project is organized,
and<br>
the dependencies among the components required to build (e.g.,
Intrinsics<br>
before VMCore).<br>
<br>
I believe a number of other projects/users (FreeBSD, fbuild) have<br>
built there own<br>
build system for LLVM. Encoding the project structure clearly should make
it<br>
easier for such projects, or for other future users that want to do the
same.<br>
<br>
This should make it easier to experiment with the build system, for
example<br>
we could just directly generate good Makefiles for our project, or could<br>
experiment with systems like Ninja which expect to be targetted by a<br>
generator of some kind.<br>
<br>
<br>
Proposal<br>
--------<br>
<br>
My initial proposal is focused at moving us to use explicit library<br>
dependencies, but paves the way for centralizing more "build systemy"
stuff in<br>
the future.<br>
<br>
* Every LLVM "component" (roughly corresponds to each place we
have a Makefile<br>
or CMakeLists.txt currently) will get a 'LLVMBuild.txt' file.<br>
<br>
This file will be an LLVM specific description of that component.
Initially,<br>
it will look something like this::<br>
<br>
[component]<br>
# The kind of component this is (currently library, tool, build
tool). More<br>
# types will be defined over time.<br>
type = Library<br>
<br>
# The name of the component.<br>
name = VMCore<br>
<br>
# The name of the component to logically group this in. This is
just for<br>
# organization purposes.<br>
parent = Libraries<br>
<br>
# The names of the library components that are also required when
linking<br>
# with this library. More on this later.<br>
required_libraries = Support<br>
<br>
The exact structure of the format is TBD (and easy to change), currently
the<br>
format is INI style but I may decide to change to JSON once all the
pieces<br>
are in place.<br>
<br>
The LLVM web pages will have clear documentation on what these files
should<br>
look like, what is required, what is supported, and so on.<br>
<br>
<br>
* I will add a new tool in utils/llvm-build which is designed to load and
work<br>
with these files. This tool will be written in Python, and the
expectation is<br>
that it can be run at configure time.<br>
<br>
TO BE CLEAR: I intend to introduce a hard dependency on requiring Python
in<br>
order to build LLVM.<br>
<br>
For the Makefiles, this is no worse than requiring Perl, so I don't
think<br>
there is much to argue with.<br>
<br>
For CMake, this is a new dependency. However, I feel this is
unavoidable:<br>
<br>
* I see no way to support multiple build systems including CMake
without<br>
either introducing a dependency on some extra tool (which
can be shared),<br>
or duplicating a significant amount of logic in CMake.<br>
<br>
I believe that duplicating logic is worse than adding the
Python<br>
dependency, and I think we already have more CMake code (a
relatively<br>
horrible language) than can be expected for most LLVM
developers to deal<br>
with.<br>
<br>
Additionally, we already require Python for running our tests, so anyone<br>
doing serious LLVM development should have it.<br>
<br>
The one use case I believe this particularly hurts is users who just
want to<br>
download and play with LLVM, but I believe the Right Answer (tm) for
that<br>
case would be for us to provide nice installer packages anyway.<br>
<br>
<br>
* utils/llvm-build will be run during configure time (both for Make and
CMake),<br>
and will:<br>
<br>
* Generate the library dependency information required to link tools, in<br>
whatever format makes the most system for the build system in
use.<br>
<br>
* Generate a C++ .inc file containing the dependency table for use by<br>
llvm-config (which I am going to rewrite in C++).<br>
<br>
* Add dependencies on the LLVMBuild.txt files to the build system, so
that<br>
the build will reconfigure appropriately when the library<br>
requirements change.<br>
<br>
<br>
* Remove GenLibDeps.pl, <a href="http://find-cycles.pl" target="_blank">find-cycles.pl</a>,
etc.<br>
<br>
We will no longer be using these after llvm-config has moved over.<br>
<br>
<br>
* Add explicit source file lists to the LLVMBuild.txt files.
Unfortunately,<br>
this is inevitable if we want to support CMake users projects
automatically<br>
reconfiguring themselves when new files get added. I can make it easier
to<br>
manage (for example, provide build targets that will automatically add
any<br>
new files).<br>
<br>
<br>
* Move both Make and CMake over to using the explicit file lists in the<br>
LLVMBuild files. This ensures that both systems get the same behavior<br>
(instead of Make users being able to add files and forget to update<br>
CMakeLists.txt).<br>
<br>
<br>
* Add new 'lit' tests to check that the library dependency<br>
information is correct.<br>
<br>
This seems a nicer place to do the checking which is currently partially<br>
handled by find-cycles, and we should also be able to do a better job of
the<br>
checking (for example, verifying that the dependency list is
"exact" -- only<br>
specifies the minimum set of libraries required, and isn't allowed to
specify<br>
libraries which are only indirectly required).<br>
<br>
It would be particularly cool if we could just write these tests using
our<br>
Object libraries.<br>
<br>
This is one piece I haven't prototyped yet. I can obviously do something
as<br>
good as the current <a href="http://find-cycles.pl" target="_blank">find-cycles.pl</a>,
but I hope to do better (eventually).<br>
<br>
<br>
* These are just the first steps, after this I will continue to
incrementally<br>
try and move as much common information out of the Make and CMake
systems so<br>
there is "one source of truth" with regard to the project
definition.<br>
<br>
<br>
* I assume it is obvious, but when I say "LLVM" here I am
referring to both<br>
LLVM and Clang. I have not looked at lldb yet, but if it uses the LLVM
build<br>
system (and llvm-config) functionality I will try to make sure it<br>
continues to work.<br>
<br>
<br>
What This Means For Jane "LLVM Developer" Doe<br>
---------------------------------------------<br>
<br>
In practice, this means:<br>
<br>
* LLVM requires Python to build.<br>
<br>
* When you add a file to LLVM, you will need to edit LLVMBuild.txt
instead of<br>
CMakeLists.txt, which will be in a slightly different, but otherwise
totally<br>
obvious format.<br>
<br>
If you forget to do this, your file will not be built (which will most
likely<br>
cause a link error eventually). This is better than it being built by
Make,<br>
but causing CMake build failures when you check in.<br>
<br>
* When you add a new library requirement to an existing component, you
will be<br>
required to edit LLVMBuild.txt instead of CMakeLists.txt, which will be
in a<br>
slightly different, but otherwise totally obvious (hopefully) format.<br>
<br>
If you forget to do this, you will either get a link error or a test<br>
failure. This is better than library you need transparently getting
linked in<br>
(with make) because it forces you to think about whether you actually
should<br>
be adding that dependency.<br>
<br>
The goal is that this also ensures that if LLVM links and passes tests
on<br>
your system, then it should for everyone else as well.<br>
<br>
* Developers not actively touching the build system should never need to
touch<br>
a Makefile or a CMake file.<br>
<br>
Overall, I believe this should be a quality of life improvement for the<br>
developer community. The only downside is having to deal with a new
non-standard<br>
LLVM specific format, but I plan to solve this through documentation.<br>
<br>
Comments?<br>
<br>
- Daniel<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><o:p></o:p></span></p>
</div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<p class=MsoNormal><span lang=EN-US style='font-family:"Courier New"'>---------------------------------------------------------------------<br>
Intel Israel (74) Limited<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</span><span
lang=EN-US><o:p></o:p></span></p>
</div>
</body>
</html>