[v2] r1717 should be the final merge to the root

[Josh Petrie]

...don't develop in v2/SlimDX/... any longer unless you want to merge yourself. I'll delete the directory in a few days.

Unfortunately the project isn't buildable in this state because the generator isn't sufficiently configurable. Here's the plan:

Each of the product assemblies in v2 (currently, there's only one, SlimDX itself) should be buildable independently -- we also can't check in generated code. So, each product assembly needs a pre-build step to run the parser and generator for its relevant inputs.

However, the parser can't run from an arbitrary directory because it expects "win32_ext.h" to be either in the include path for the DX SDK or the working direc tory. This file, which appears to be a selection of bits from the Win32 headers, isn't even something we can legally distribute, so that needs to be addressed.

The generator can't seem to run from an arbitrary directory either -- for whatever reason (and I haven't look into this in depth yet), the text templating engines fails when run as pre-build step for SlimDX.csproj, but it runs fine when invoked from the build.proj MSBuild script in the root of the branch.

I've checked in the stub .csproj for the main assembly with nothing else, I'll open bugs for the above two issues in a moment.

-- jmp

[Alexandre Mutel]

>>>>>>...don't develop in v2/SlimDX/... any longer unless you want to merge yourself. I'll delete the directory in a few days.

 

Ok, I’m going to develop on root directory now.

 

>>>>>>Each of the product assemblies in v2 (currently, there's only one, SlimDX itself) should be buildable independently -- we also can't check in generated code. So, each product assembly needs a pre-build step to run the parser and generator for its relevant inputs.

 

The generator is not at all intended to be run on a per assembly basis... this is just not possible. The generator should be run, let say, before root assembly, SlimDX.dll, as a pre-build event, and It will generate all the code for all the assemblies.

 

>>>>>>However, the parser can't run from an arbitrary directory because it expects "win32_ext.h" to be either in the include path for the DX SDK or the working direc tory. This file, which appears to be a selection of bits from the Win32 headers, isn't even something we can legally distribute, so that needs to be addressed.

 

wow... all those legal issue are scaring me... seriously... I can move the struct declaration but I will  keep the defines (they are just defines, and In my life, I haven’t seen any legal issue with defines).... Structs declaration will be moved to their XML counterpart... that will be loaded by the generator (this plainly stupid, xml vs .h)

 

It’s not necessary to have win32_ext.h copied to the output directory. I can setup the include path to take it directly from the source Parser directory.

 

>>>>>>The generator can't seem to run from an arbitrary directory either -- for whatever reason (and I haven't look into this in depth yet), the text templating engines fails when run as pre-build step for SlimDX.csproj, but it runs fine when invoked from the build.proj MSBuild script in the root of the branch.

 

So, if I understand how you want to setup the project, you have in mind to have a single project with the tools (parser/generator) together with all the assemblies.

 

So the solution should look like this?

- XIDL

- Parser

- Generator   => run the generator after this step

- SlimDX    - root common assembly   => this project has a dependency on Generator

- SlimDX.Direct3D9   => this project has a dependency on SlimDX

- SlimDX.Direct3D10

- SlimDX.Direct3D11

- ...etc.

 

 

[@lx]

ok, r1723 is compiling fine. I did a primary checkin of SlimDX files.

The current compilation process has been simplified :

- The generator is using directly the parser
- Both the parser and the generatror have a special handling : when
they are successfully generated, they output a small tag file in the
build directory with the same timestamp than their respective
assembly. Next time, if the build process is re-run, the parser and
the generator will look at those files and compare their own
timestamp. This way, if you don't change the code of the parser or the
generator and last generated files were successfull, then, the
generator is not run in the building process.
- I have put in the Pre-Build of SlimDX assembly a call to the
generator. In order to make it working, I just put a simple .bat
inside the Generator source.

The building process in now working like this:
- XIDL
- Parser depends on XIDL
- Generator depends on Parser / XIDL

- SlimDX depends on Generator AND their is a pre-build event to run
the generator (and the generator will run, but won't generate anything
is everything is up-to-date)
- ...etc.

Currently, I need to check if the generator is not running
successfully if the build process is stopped, probably not, but this
should be fairly easy to integrate.

I'm going to checkin SlimDX.Direct3D10 / Direct3D11 / DXGI project and
extension files.

Also, concerning SlimDX2 directory, I have keep a copy of it, because
I did a couple of samples that are not available elsewhere...

[@lx]

Oh, btw, could you prefix your svn checkin for v2 with v2?

[Alexandre Mutel]

Ok, I have checked-in all the files and samples as well as updating the solution and project.

 

Things I have done:

 

- I have added the sample to the SlimDX.sln. I don’t know if It is done this way in SlimDX 1 but while developping, this is very important to be able to run the samples on the side of the project, in order to debug all interop/marshal layers correctly.

- All the projects are using the SharedAssemblyinfo

- All  the SlimDX, SlimDX.Direct3D9, SlimDX.Direct3D10 ...etc are referencing the SlimDX.Interop assembly. But this is important that this assembly is not copied as local (copy local : false). For future project, this is important, otherwise there will be some unpredictable behavior between x64 and x86.

- Samples are added for Direct3D9, Direct3D10, Direct3D11 and a running fine

- The generator is launched as a post-build event on SlimDX. It is run only when there is a change to the parser/generator assembly. Two small files .slimdx_parser_ok and .slimdx_generator_ok are generated in the Generator\Bin\Debug directory and are tagged with the same WriteLastTime then the Parser and Generator assemblies. This way, the building process is not running when nothing was changed from the previous build.

- I have also added the SlimDX.Error assembly. I have generated a part of this code with a small tools that was on the SlimDX2 subdirectory. We will have to find if It’s necessary to have a tool running for this... don’t know (all the errors were gotten from the DXGetErrorDescription / DXGetErrorString which are statically linked, so cannot be embedded in a C# assembly with an external dll)

 

The project should compile fine, generating the files and then compiling the remaining part of the project.

 

Mike, I would be glad to see if you are able to compile it like this.

 

 

 

 

[@lx]

> - The generator is launched as a post-build event on SlimDX.

An error here : the generator is launched as a PRE-build event on
SlimDX.

[@lx]

I have lastly added Direct2D1, DirectWrite, DirectSound, XAudio2 and
XAPO and according samples.

The reason is that I have put a lots of work in them already, in term
of mappings, extensions and samples (in order to test them), and
actually, I need them because I'm using them (for Direct2D as well as
a synthesizer that is using it).
It's also important to have them generated in order to check that any
significant changes in the generator is not to going to screw up
things.

Although I won't add XACT3, XInput, DirectInput as I didn't work on
them.

If this is really an issue, we could probably setup 2 working
SlimDX.sln solutions, one with the full model and one with the tiny
(Direct3D9, Direct3D10, Direct3D11, DXGI).

[Josh Petrie]

The generator is not at all intended to be run on a per assembly basis... this is just not possible. The generator should be run, let say, before root assembly, SlimDX.dll, as a pre-build event, and It will generate all the code for all the assemblies.

It should be possible, or we have a design problem we need to address. But I'm pretty sure this is already doable; if you simply comment out the mapping function calls for other APIs, leaving on the dependencies and the target API, it produces only the desired subset. We can do this with command line options that gate the appropriate mapping calls in the near term, and when we move to a model that reads the mapping information from input files, that will take care of it completely.

I have most of the code I believe is necessary for this change, I was just blocked by the text templating weirdness last night.

 

wow... all those legal issue are scaring me... seriously... I can move the struct declaration but I will  keep the defines (they are just defines, and In my life, I haven’t seen any legal issue with defines).... Structs declaration will be moved to their XML counterpart... that will be loaded by the generator (this plainly stupid, xml vs .h)

It doesn't matter if the declarations are in an XML file or not. It does not matter how much or how little of the Win32 header we copy. It's either illegal or of an unknown legal state for us to copy and paste code from the Win32 API and redistribute it. Until we have some kind of resolution of that, we cannot be redistributing that code (that includes checking it in to our public repository). It isn't a matter of the chance that Microsoft will notice and take action -- they almost certainly won't. It's a matter of principle and of risk tolerance. A legal dispute with Microsoft will put our project in their control and probably effectively shut it down. That's not an acceptable risk.

Besides, I don't believe that the dependency on the file is necessary from an engineering standpoint. I'm certain we can come up with a better solution.

 So, if I understand how you want to setup the project, you have in mind to have a single project with the tools (parser/generator) together with all the assemblies.

 

So the solution should look like this?

We should have a single solution file. Each of the product assemblies (SlimDX.dll itself, SlimDX.Direct3D10, et cetera) should be buildable on their own. Each product assembly should have a pre-build step that produces only the code for that project -- thus the necessity for the design changes to the generator. The samples *should* be in the solution as you've added them -- I just forgot about them. The only reason we had multiple solutions in v1 was to support Express users, who cannot load mixed-mode solutions. We intend to support people who don't have the version of VS we're supporting by enabling command-line builds from the start (unlike v1 where we unsuccessfully had to retrofit them).

Adding the other API product assemblies (DirectWrite, et cetera) is good, too -- we just shouldn't continue with forward development until we resolve the outstanding issues.

If a user with the appropriate DirectX SDK version cannot check out a fresh copy of v2 and build a complete release with a single command, our build process is wrong and must be corrected. That's the driving, high-level goal behind the project structure. The only exception to that is that only Promit, Mike and I have the private key to sign an official release.

Oh, btw, could you prefix your svn checkin for v2 with v2?

 

Why? It just adds noise. That information is already available in the body of the commit message if you're trying to set up a filter for it.

-- jmp

[@lx]

I have opened a list of issues... after seeing that they were
sometimes duplicate of previews issues I didn't see. Sorry!

I merged them, because they were no longer relevant, or partially
irrelevant.

Also I did remove one them : generating per-class-file. This is
definitely not something we should do for generating classes. I do
agree for hand written class but not for generated. See my complete
response in the defect : http://code.google.com/p/slimdx/issues/detail?id=731

[Alexandre Mutel]

>>>>>>> It should be possible, or we have a design problem we need to address. But I'm pretty sure this is already doable; if you simply comment out the mapping function calls for other APIs, leaving on the dependencies and the target API, it produces only the desired subset. We can do this with command line options that gate the appropriate mapping calls in the near term, and when we move to a model that reads the mapping information from input files, that will take care of it completely.

>>>>>>>

>>>>>>> I have most of the code I believe is necessary for this change, I was just blocked by the text templating weirdness last night.

 

Wow, It's going to be much harder than this. The Interop code is generated on a global project basis and not generated per assembly.

That would mean to generate an interop assembly specialized for each assembly. It's possible though (that's why I put LocalInterop for each project), but It's not straightforward

 

 

>>>>>>> It doesn't matter if the declarations are in an XML file or not. It does not matter how much or how little of the Win32 header we copy. It's either illegal or of an unknown legal state for us to copy and paste code from the Win32 API and redistribute it. Until we have some kind of resolution of that, we cannot be redistributing that code (that includes checking it in to our public repository). It isn't a matter of the chance that Microsoft will notice and take action -- they almost certainly won't. It's a matter of principle and of risk tolerance. A legal dispute with Microsoft will put our project in their control and probably effectively shut it down. That's not an acceptable risk.

 

No, I really don't agree.

win32_ext was written by hand, I didn't copy paste anything. Just the structure from MSDN...

Writing the declaration in XML or even, in C# doesn't have any legal issues with it. If yes, It would mean that ALL current interop codes available from the internet would be illegal...

 

meaning no p/invoke for anykind of project... come on, this is just impossible!

 

>>>>>>> We should have a single solution file. Each of the product assemblies (SlimDX.dll itself, SlimDX.Direct3D10, et cetera) should be buildable on their own. Each product assembly should have a pre-build step that produces only the code for that project -- thus the necessity for the design changes to the generator. The samples *should* be in the solution as you've added them -- I just forgot about them. The only reason we had multiple solutions in v1 was to support Express users, who cannot load mixed-mode solutions. We intend to support people who don't have the version of VS we're supporting by enabling command-line builds from the start (unlike v1 where we unsuccessfully had to retrofit them).

 

Ok, but the tricky side here is the interop assembly. It should be feasible to generate only a subset... BUT It will still need to parse and map all the files in the process.

 

This is mandatory to handle structure declaration correctly.

[@lx]

For example, this kind of thing has nothing to do with the initial
structure from a win32 header file, so there can't be any legal issue

<CppStruct>
<Name>RGNDATAHEADER</Name>
<Fields>
<CppField>
<Name>dwSize</Name>
<Type>int</Type>
<Specifier></Specifier>
<Const>false</Const>
<IsArray>false</IsArray>
<Offset>0</Offset>
<IsBitField>false</IsBitField>
<BitOffset>0</BitOffset>
</CppField>
<CppField>
<Name>iType</Name>
<Description i:nil="true" />
<Remarks i:nil="true" />
<Type>int</Type>
<Specifier></Specifier>
<Const>false</Const>
<IsArray>false</IsArray>
<ArrayDimension i:nil="true" />
<Offset>1</Offset>
<IsBitField>false</IsBitField>
<BitOffset>0</BitOffset>
</CppField>

[Josh Petrie]

No, I really don't agree.

Maybe there isn't a legal issue, maybe there is. I'm not lawyer, I can't really tell. But I'm unwilling to commit to a solution that I have my legal doubts about until I have those doubts resolved. I don't intend to pursue that, because from an engineering perspective I believe we can do better than depend on that file anyhow.

The types we need are in the Win32 SDK, why don't we simply parse those headers just like we parse the DX ones? We can expect a dependency on Win32 since we have a dependency on DX. We can implement whitelisting to prevent the XIDL from containing a truckload of types we don't actually need.

-- jmp

[Alexandre Mutel]

>>>>>>> Maybe there isn't a legal issue, maybe there is. I'm not lawyer, I can't really tell. But I'm unwilling to commit to a solution that I have my legal doubts about until I have those doubts resolved. I don't intend to pursue that, because from an engineering perspective I believe we can do better than depend on that file anyhow.

 

One reason is that the defines in win32_ext are not the same than in the windows SDK headers, some of them are used to catch things (like the GUID), someme of them are not defined like in win32 (like BOOL, because BOOL in win32 is mapped to unsigned int, and we NEED to have the information that it is a bool in C#), some of them are used to black list some part of DirectX SDK headers....etc.

 

Also, working with win32 sdk headers would lead to handle a lots of #include dependency, because the types are defined in several swapned includes, just a plain nightmare.

 

This is definitely not something I would do and agree with it, plus, I didn’t intend to work on a generic C++/C parser that would be able to parse any kind of C++ header file, I don’t have time, and NO interest in it.

 

Thing about it, If there was an issue with this kind of things, making your own WaveFormat class in C# would'nt even be possible.

 

[Josh Petrie]

One reason is that the defines in win32_ext are not the same than in the windows SDK headers, some of them are used to catch things (like the GUID), someme of them are not defined like in win32 (like BOOL, because BOOL in win32 is mapped to unsigned int, and we NEED to have the information that it is a bool in C#), some of them are used to black list some part of DirectX SDK headers....etc.

This sounds like something we could support in a remapping phase of some type.

Also, working with win32 sdk headers would lead to handle a lots of #include dependency, because the types are defined in several swapned includes, just a plain nightmare.

I agree, but just because it's hard does not mean we should ignore it, especially if the result is code that we believe does not not meet the quality bar we've set for ourselves. We have set a very high bar for ourselves, and we certainly don't always meet it, but we aren't going to stop trying.

This is definitely not something I would do and agree with it, plus, I didn’t intend to work on a generic C++/C parser that would be able to parse any kind of C++ header file, I don’t have time, and NO interest in it.

You don't have to do, it just has to be done, and you should be aware that it's going to be done because that should inform other decisions you may need to make regarding other, possibly related changes. That's part of working in team, especially in a team on an established project with established conventions and goals. Remember that ultimately, Promit, Mike and I are the principle developers for this project and responsible for its direction -- I'm not trying to hold a gun to your head and say that you, personally, must make all of the changes that I mentioned need to or should be made. I hope that's not the impression I've given you, because that's not what I intended.

I point these things out merely because they are issues that I want addressed, because I feel that they would improve the quality of the code in a project I am responsible for. That means that ultimately, the responsibility for enacting those changes falls to me. Part of that responsibility includes making other developers aware of my intent to enact those changes at some point, so that we're all on the same page. This is especially necessary since we're all mostly in different time zones and have very different schedules for working on this project.

-- jmp

--
You received this message because you are subscribed to the Google Groups "slimdx-devel" group.
To post to this group, send email to slimdx...@googlegroups.com.
To unsubscribe from this group, send email to slimdx-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/slimdx-devel?hl=en.

[@lx]

Ok. If you feel confident to handle those things and you have time for
them, why not.

I'm also expecting to use it quite soon, so I just don't want to have
an unsuable SlimDX v2 because the parser is a unstable and in long-
term development, just because for purity, you want to be able to
parse all win32 sdk headers.

At some point, If I feel really that the direction is going to
something that is completely wrong from my point of view, and we can't
find any solution or agree, I would spawn a separate project. So far,
I have been working full time on this since September, so I'm
expecting a lot from it.

But again, If you are confident to make all those things without
having a top-heavy, unwieldy, slow and impractical project, I'm fine.

The good thing is that your requirements are forcing me to make things
simpler (for example to build everything in a single project,
integrated in the whole process is nice), I just hope that because of
handling extra-things, this project will be not be delayed for years.

[Michael Popoloski]

Quick and dirty is fine as a development style when you're working on personal projects, or others that are small or one-off. In our case, we're looking at supporting a platform for many developers, both hobbyist and professional, for many years to come. The base for such a project needs to be absolutely rock solid and extremely easy to maintain in order for a small group of developers like ourselves to have any chance of holding it together in the long run. It's not a knock on your development process, it's simply a different target than you might be used to. We can't settle for small concessions now if they lead to larger problems in the future, which is what Josh is diligently working to prevent.

[Washu]

A couple of things:

1. We need a fully documented build setup for these projects. As it is
from a fresh check out I have no idea of
A. What dependencies I require other than the DXSDK (if any)
B. What to run/do in order to build the solution from scratch.
C. What is done where (who builds what, what is generated where,
etc).
All of that needs to be documented now, before the project gets
too far along that the amount of work required to get the
documentation going becomes a significant stopping point.

2. Refactoring. The generator especially needs this, and now. Before
we get too far along and it becomes too hard to change things without
massive breaking changes. This should be fixed up now. Almost
everything in the generator needs to be data driven. It also should:
A. Generate separate source files for each type (instead of one
giant one)
B. Be able to be run at a per-project level.

I think the first one is pretty self obvious as to why we would want
that, but the second one may need a bit of clarification: SlimDX is
changing over time, and because of that new things get added and old
things sometimes go away. We shouldn't constantly be having to add/
remove bits and pieces of source code to the generator just to
accommodate this. Since this should all be configuration driven, we
should be able to simply point it at the appropriate project, which
should contain the appropriate configuration files for the generator,
and have it produce the appropriate source files. This allows us to
not only apply the generator towards SlimDX projects, but potentially
towards other projects in general under the Slim* branding.

Finally, we should not be copying ANYTHING at all from the Windows or
DX SDK headers, or pretty much anything at all from anyone's headers
that aren't ours without a permissive license to do so. Any such
copying can constitute a derivative work and becomes a legal punching
bag. SlimDX has neither the legal precedence or financial backing to
fight any such copyright claims. That means we have to do it right the
first time, and ensure that anything we have to generate is generated
from the original source and not necessarily from convenience. Parsing
the win32 headers we need and simply white listing the types we
require should be sufficient, and furthermore is useful for other
potential applications of the generator.

On Nov 16, 1:50 pm, Michael Popoloski <mike.popolo...@gmail.com>
wrote:

> > slimdx-devel...@googlegroups.com<slimdx-devel%2Bunsubscribe@google groups.com>
> > .

[Alexandre Mutel]

>>>>>>> Quick and dirty is fine as a development style when you're working
>>>>>>> on personal projects, or others that are small or one-off. In our
>>>>>>> case, we're looking at supporting a platform for many developers,
>>>>>>> both hobbyist and professional, for many years to come. The base for
>>>>>>> such a project needs to be absolutely rock solid and extremely easy
>>>>>>> to maintain in order for a small group of developers like ourselves
>>>>>>> to have any chance of holding it together in the long run. It's not
>>>>>>> a knock on your development process, it's simply a different target
>>>>>>> than you might be used to. We can't settle for small concessions now
>>>>>>> if they lead to larger problems in the future, which is what Josh is
>>>>>>> diligently working to prevent.

There is a large palette between quick and dirty vs slow and heavy. On the
other hand, Keep It Simple and Smart, this is what I'm trying to follow on
every project I have been working so far (And I have been technical lead of
dozens of developers for several years, so I do know what is really dirty,
and what is leading to great things).
But ok, If Josh feels confortable to handle the task to handle correctly
this, I'm fine.
On this particular issue (defines and 4 structs defined in the code), I'm
just amazed by the solution you are validating to overcome the problem
(starting from the point that I still don't see the problem, anyway).

Also, so far, I have been the only contributor on the current v2 code, which
represents already a substantial amount of work (btw, I have been paying to
myself my salary for the 2.5 last months to work on this, just in case you
wouldn't understand how much I'm involved in this :D ), so I would be glad
to have some support!

Washu, concerning 1). I will write something soon. I have written a small
document on my blog If you haven't read it yet. There is a bit of
explanation here about the idea behind the process.
But the brandly new v2 has changed little bit things, so It might be a good
idea to write this down.

Concerning 2)
For A) As far as the process is transparent, I'm Ok. Josh proposed something
to update the vcproj directly, It would be great. But please, nothing like
"exit visual studio, restart".
For B) I agree on this, as It's going much easier to maintain, develop, and
would lead to other nice opportunities.

Concerning the doc, ok, this is clearly a disappointment. Now, I would like
to hear your solution(s).
Current statistics for v2 generated code are:
Number of interfaces : 251
Number of methods : 1714
Number of parameters : 5016
Number of enums : 285
Number of structs : 252
Number of fields : 1469
Number of enumitems : 2732
Number of functions : 297

Which is more than 10,000 documentation items to fill. What do you propose?
I cannot consider a "solid and rock" library without an API documentation.

There could be someone to write a tool to extract the current SlimDX
documentation and map it to v2 (although the current documentation is far
from being filled), could-it be a starting point?

[Washu]

Ok, a few things...

Nothing in here is a personal attack on you. That being said: Pulling
the experience card means nothing. Please don't do that, because then
we have to respond by pulling out our experience cards. Frankly, I'm
not nearly gay enough to be comparing my e-peen to your e-peen and
Josh's and Mike's and Promit's... Some impromptu cuddling at night is
about as far as I'll go.

The generator is a good idea, and so far we like what it's producing.
The problem is with the generator source code its self. It is very
inflexible, requiring modification at the source level in order to add
new imports, also a lot of it needs refactoring to clean it up and
make it more readable and maintainable. As the generator is going to
be a core component to SlimDX.2 it has to be very high quality code,
as we're going to have to live with it for a few years at the least.

Common examples of problems includes the lack of configuration data/
files for indicating parse points. As an example, all of the
"Program*.cs" files should be configuration XML files, not hard coded.

Other issues are things like OnIncludeLoad in CppHeaderParser.cs,
which assumes an incorrect accessibility level to the header files
(fixed in recent commit), and also silently fails if it can't load the
header (prints out the exception and then returns blank).

On the issue of documentation:
SlimDX has never tried to reproduce the DirectX documentation, what we
have tried to do was provide a general pointer to what each function/
class does. The goal being for the person then to look up the relevant
material in the DirectX documentation. Now, the good news is, you do
not have to embed the documentation in the CS files, but can instead
embed them in XML files using xpath links in the source files to point
to the appropriate entries in the XML files. This is done using the
<include> tag:
///<include file='filename' path='tagpath[@name="id"]' />

[Alexandre Mutel]

>>>>>>> Nothing in here is a personal attack on you. That being said:
>>>>>>> Pulling
>>>>>>> the experience card means nothing. Please don't do that

I'm sorry for this. I just had the bad feeling that you (not you directly)
telling me "Boy, you have a short seeing view on things, you don't know what
kind of direction to go for, you are developing quick and dirty. On our
side, we are thinking long term and develop things for the next century".

>>>>>>> The generator is a good idea, and so far we like what it's
>>>>>>> producing.
>>>>>>> The problem is with the generator source code its self. It is very
>>>>>>> inflexible, requiring modification at the source level in order to
>>>>>>> add
>>>>>>> new imports, also a lot of it needs refactoring to clean it up and
>>>>>>> make it more readable and maintainable. As the generator is going to
>>>>>>> be a core component to SlimDX.2 it has to be very high quality code,
>>>>>>> as we're going to have to live with it for a few years at the least.
>>>>>>>
>>>>>>> Common examples of problems includes the lack of configuration data/
>>>>>>> files for indicating parse points. As an example, all of the
>>>>>>> "Program*.cs" files should be configuration XML files, not hard
>>>>>>> coded.

I agree, and It didn't say that current code should stay as it is. This code
is a large prototype/proof of concept, and I did it because I was
frigthtened by the direction SlimDX 2 was taking (or not taking).
I mean, If all of this, starting from the whole generator, was so obvious,
It would have been already done... and I doubt that If I came to SlimDX team
with only the idea of it, you would have say "yeah, cool, we go for it"...
but most probably, I would have heard "We tried already but It's not
praticable, sorry". Then, that's why I was little touchy on comments,
because It's like you were finally talking about my work in terms of "oh, of
course, but it's so badly implemented, we have greater plans". Voila, this
whole debate is probably because we don't know yet enough each other, as
well as you need to make enough space for me to get in the SlimDX team as
much as I need to leave and let large part of the work I did in other good
hands. :)

That's said, I fully agree with all of you in improving the whole code, and
happy that you are taking it seriously and going to improve it, and more
happy because I do know that SlimDX team members are clever to push things
in right direction (Ok, I had to learn some general behavior about the legal
issues, which frustrated me at the beginning, but that's fine now... It's
probably a cultural thing, as probably in France, we are mush less sensitive
to this subject!)

For the XML based configuration, I agree, and previous work on the code has
been largely done in this direction, although I was still keeping C# code in
order to refine the code usage, ease the debugging for a particular mapping,
clearly identify mapping functions and to prepare things to make them
simpler (older version were far less flexible than that). The tagging system
for example was not done at the beginning, but then, I found that It was the
most practical way to associate things easily in order to manipulate the C++
object model.

>>>>>>> Other issues are things like OnIncludeLoad in CppHeaderParser.cs,
>>>>>>> which assumes an incorrect accessibility level to the header files
>>>>>>> (fixed in recent commit), and also silently fails if it can't load
>>>>>>> the
>>>>>>> header (prints out the exception and then returns blank).

This behavior was largely due to Boost.Wave. Boost::wave for example is
testing the files in the include path you provide, before calling
OnIncludeLoad, which is pretty stupid, because you cannot implement loading
include files from anything else than the disk. Also, all the OnXXX are
called from boost::wave which is native code, meaning that you cannot
forward exceptions to the upper managed level. Like for the generator, the
parser is far from being failsafe proof in all C++ cases, again, It's a
prototype and I do agree that It needs to be improved. Though, it's working
on DirectX SDK headers now.

The way the code running right now is like this :

- .NET/CppParserHeader.Run() => .NET/Boost.Wave.Net.Preprocessor.Run() =>
... => (C++)boost::wave => BoostWave.NET => OnXXX => handle includes,
tokens and Parse

In fact, It would probably safer to only handle includes and tokens in the
OnXXX and then after Boost.Wave.Net.Preprocessor.Run() returns, handling the
whole parsing for all the tokens. I will look at it at some point.