Clang approach of C/C++ module

[Lionel Auroux]

Deeply involve in the cnorm 4, I found this

http://clang.llvm.org/docs/Modules.html

I think it's could be a way to follow to handle the type problem in C chunk templates. I prefer to trash my unstrict mode

In rathaxes 2009, we precompiled C headers, store and use resulting trees. It's workable. The only fucking problem is the way to precompiled C headers... It was done not too stupidly but we need to write some specific codeworker scripts...

Now with python, we could use distutils to invoke the C compiler of the system to process the stuff.

--
Cordialement,
Lionel Auroux

[David Pineau]

The part where I'm particularly wary of this method is that it implies that we HAVE TO embark the pre-compiled include files for EACH system and EACH of its supported versions. It won't scale with a wide support, even only with linux. From my point of view, it does not differ much from the original issue noted with the first prototype.

I think we all agree that the unstrict method was the wrong way to go around the issues of types unknown in advance (it introduced far too much uncertainty and issues that were unresolvable automatically). The issue here is that we need a lightweight solution which does not burden our compiler nor our (future) community.

I feel like re-distributing the codes of the includes in order to check that the templates are valid is not the right way to go, since we want to be able to generate the C code on whatever platform/os/version for whatever other platform/os/version, without burdening the developer with having to download all the pre-compiled headers for every single system in the universe.

That is why we discussed about having a rathaxes-specific kind of forward declaration which, to me, seemed like the best compromise between the burden and the usability.

2013/8/30 Lionel Auroux <lionel...@gmail.com>

--
--
ML Rathaxes
www.rathaxes.org
 
---
You received this message because you are subscribed to the Google Groups "Rathaxes Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rathaxes-deve...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
David Pineau,
Developer R&D at Scality

[Lionel Auroux]

In rathaxes 2009 we design the BackEnd library as a package manager. When I speak to you about cache I have this in my mind. Providing a web-repository for populating the user cache or allow dev to submit a local evolution to the repository. If we could do it for chunks of code, we could do it for compiled version of headers.

In 2009, when the compiler see a header we load the associated tree file in compiler. It's not enough smart for our cache mechanism. But, when a developer write a BLT, and register it, he tests his code in his machine.

So his compiler is configured to process headers file correctly for his system (default value of CPP). So processing headers to get the related environment for his BLTs makes sense.

However, for macros we need special statement for declaring them in templates. So we could continue to go this way since we don't have a workable first version.

When I was writing this response, I checked some samples BLT to figure out how many declaration we should write for a complex template. It was surprisingly few. Indeed, the major part of the types are template placeholders.

sample syntax:

chunk LKM::code()

[
  type PDRIVER_OBJECT;

  macro_value IN;

]
{

    long DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath)
    {
        // ...
    }  

}

2013/8/30 David Pineau <dav.p...@gmail.com>

--
Cordialement,
Lionel Auroux

[Lionel Auroux]

message send too early...my bad :)

correct samples...
chunk LKM::code()
[
  type PDRIVER_OBJECT, PUNICODE_STRING;

  macro_qualifier IN;

]
{

    long DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath)
    {
        // ...
    }  

}

I propose a bracket syntax before block of C code. It's look like attributes (C#) on block.

- type allow to list type...
- macro_qualifier for macro value syntax in declaration_specifier rule.

- macro_decorator for macro used for C mangling (using ##) in declarator or abstract_declarator rules.

i.e :    int  Macro(thing)(int, double);

2013/8/31 Lionel Auroux <lionel...@gmail.com>

--
Cordialement,
Lionel Auroux

[David Pineau]

2013/8/31 Lionel Auroux <lionel...@gmail.com>

message send too early...my bad :)

correct samples...
chunk LKM::code()
[
  type PDRIVER_OBJECT, PUNICODE_STRING;

  macro_qualifier IN;

]
{

    long DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath)
    {
        // ...
    }  

}

I propose a bracket syntax before block of C code. It's look like attributes (C#) on block.

- type allow to list type...
- macro_qualifier for macro value syntax in declaration_specifier rule.

- macro_decorator for macro used for C mangling (using ##) in declarator or abstract_declarator rules.

i.e :    int  Macro(thing)(int, double);

I'm not a pro at judging a syntax, but it seems okay to me, and joins what we have discussed multiple times in terms of rathaxes-specific forward declarations.

To me it's a ok :)

 

2013/8/31 Lionel Auroux <lionel...@gmail.com>

In rathaxes 2009 we design the BackEnd library as a package manager. When I speak to you about cache I have this in my mind. Providing a web-repository for populating the user cache or allow dev to submit a local evolution to the repository. If we could do it for chunks of code, we could do it for compiled version of headers.

Well, not that I don't agree about managing "packages" of interfaces, templates and the likes...

But in the end, it is an enormous complexity for us. I mean, distributing the pre-compiled headers for each and every system ? really ? I can't fathom how much work it would lead to (and I honestly don't want to manage this)...

 

In 2009, when the compiler see a header we load the associated tree file in compiler. It's not enough smart for our cache mechanism. But, when a developer write a BLT, and register it, he tests his code in his machine.

So his compiler is configured to process headers file correctly for his system (default value of CPP). So processing headers to get the related environment for his BLTs makes sense.

Well, It makes sense in the way we want to do most of the checks before registering the template into a local library....
But then, if I understand you, the developer working on his target system only has to call upon a local tool to resolve this issue, which zould be ,ore than enough. Why distribute it ? (or did I miss something?)