On 2011-10-22 15:41, Andrej Mitrovic wrote:
> I have a question about licensing. If you translate a C LGPL'ed header
> file to D, and you keep the same license, are you still allowed to use
> whichever license in your user code that uses the new D files? Because
> I don't know whether using LGPL'ed .d files falls under "using the
> library" or "extending the library".
>
> For example, CairoD has translated Cairo LGPL/MPL'ed header files in
> equivalent Boost-licensed .d files. I know I'm asking for free lawyer
> advice here, but do you think this is going to be a problem?

You still need to link to the C library.

-- 
/Jacob Carlborg

On 10/22/11, Jacob Carlborg <doob@me.com> wrote:
> On 2011-10-22 15:41, Andrej Mitrovic wrote:
>> I have a question about licensing. If you translate a C LGPL'ed header file to D, and you keep the same license, are you still allowed to use whichever license in your user code that uses the new D files? Because I don't know whether using LGPL'ed .d files falls under "using the library" or "extending the library".
>>
>> For example, CairoD has translated Cairo LGPL/MPL'ed header files in equivalent Boost-licensed .d files. I know I'm asking for free lawyer advice here, but do you think this is going to be a problem?
>
> You still need to link to the C library.
>
> --
> /Jacob Carlborg
>

Yes, but *linking* isn't extending the library. Importing D files that are LGPL licensed could be different.

On Saturday, October 22, 2011 15:41:13 Andrej Mitrovic wrote:
> I have a question about licensing. If you translate a C LGPL'ed header file to D, and you keep the same license, are you still allowed to use whichever license in your user code that uses the new D files? Because I don't know whether using LGPL'ed .d files falls under "using the library" or "extending the library".
> 
> For example, CairoD has translated Cairo LGPL/MPL'ed header files in equivalent Boost-licensed .d files. I know I'm asking for free lawyer advice here, but do you think this is going to be a problem?

I would _think_ that it would be okay as long as it's a direct translation, since all you're doing is making it so that you can link to the libraries as you would in C, not extending their functionality in any way. But I'm not a lawyer, and I'm far from an expert on software licensing.

- Jonathan M Davis

On Oct 22, 2011, at 4:03 AM, Timon Gehr wrote:

> On 10/22/2011 04:33 AM, Walter Bright wrote:
>> On 10/21/2011 4:32 PM, Fawzi Mohamed wrote:
>>> 
>>> On Oct 21, 2011, at 4:20 PM, Fawzi Mohamed wrote:
>>> 
>>>> The main problem with this approach is how to support different
>>>> versions of
>>>> a library, or of OS. It quickly becomes difficult to support anything
>>>> but
>>>> the latest, or a fixed version. It works beautifully for mature libs.
>> 
>> Since github has excellent support for branches, I don't see why this is a major problem.

do you have a repo per library? if yes then indeed it is feasible. I didn't think about that.

>>>> I still cannot avoid thinking that a C frontend automatically
>>>> generating D
>>>> modules with the help of recipes would be a better way. It will need
>>>> some
>>>> manual intervention for "difficult" cases, mainly giving manual
>>>> translation
>>>> of some macros, but it should be small.
>>> 
>>> … and it seems that in the time I was offline others came up with the
>>> same
>>> idea...
>> 
>> It's an old idea. The trouble is, as always, the C preprocessor. I'm currently converting the openssl .h files, and they are a zoo of metaprogramming using C preprocessor macros.
>> 
>> People are going to demand perfect translation if it is automatic.

that was the reason I talked about recipes that can add manual fixes where needed (for selected macros).

>> 
>> The only way to do it is to work with the preprocessed output of the .h file, and just forget about the preprocessor.
> 
> Another way is to replace the preprocessor with CTFE and string mixins. I think that could be automated quite easily. (modulo the possibility of some extremely heavy abuse on the C side that could make the other parts of the translation a lot harder of course)

I think string mixings are an extremely ugly solution to this problem, and I would try to avoid that, especially if they are used to represent a function that should be inlined, and might be replaced by a normal function in a later version.

On 10/22/2011 6:12 PM, Fawzi Mohamed wrote:
>> Another way is to replace the preprocessor with CTFE and string mixins. I
>> think that could be automated quite easily. (modulo the possibility of some
>> extremely heavy abuse on the C side that could make the other parts of the
>> translation a lot harder of course)
>
> I think string mixings are an extremely ugly solution to this problem, and I
> would try to avoid that, especially if they are used to represent a function
> that should be inlined, and might be replaced by a normal function in a later
> version.

Sure, but I've seen some pretty ugly use of preprocessor macros to paste together statements that need to be inserted. String mixins are the only hope.

On 2011-10-22 21:12, Andrej Mitrovic wrote:
> On 10/22/11, Jacob Carlborg<doob@me.com>  wrote:
>> On 2011-10-22 15:41, Andrej Mitrovic wrote:
>>> I have a question about licensing. If you translate a C LGPL'ed header
>>> file to D, and you keep the same license, are you still allowed to use
>>> whichever license in your user code that uses the new D files? Because
>>> I don't know whether using LGPL'ed .d files falls under "using the
>>> library" or "extending the library".
>>>
>>> For example, CairoD has translated Cairo LGPL/MPL'ed header files in
>>> equivalent Boost-licensed .d files. I know I'm asking for free lawyer
>>> advice here, but do you think this is going to be a problem?
>>
>> You still need to link to the C library.
>>
>> --
>> /Jacob Carlborg
>>
>
> Yes, but *linking* isn't extending the library. Importing D files that
> are LGPL licensed could be different.

According to GPL it is and according to LGPL it is for static linking, IIRC.

-- 
/Jacob Carlborg

On 21.10.2011 13:42, Gor Gyolchanyan wrote:
> This will defeat the philosophy of D, which stands for core
> correctness, simplicity, maintainability and flexibility.
> A much better solution would be to implement the AST macros, which
> were discussed in a video-talk a long time ago by Walter and Andrei,
> for which the macro keyword was reserved.
> After that, all C macros will be translatable.

Unfortunately, the AST macros described in the conference video don't work (they are *far* too weak). Nobody has ever come up with a replacement proposal.

On Sat, 22 Oct 2011 04:34:59 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> On 10/21/2011 12:41 AM, so wrote:
>> You are right, i forgot about macros, Is it only this or is there anything else?
>
> The only other thing is what does one do about 'char' - make it a byte, ubyte, or char D type?

One should not loose the implicit conversion of string literals to
const char pointers. So the answer might be to use char where something
is used in a string context and (u)byte where it's not. In most cases this is
a no-brainer.

martin

Am 22.10.2011, 04:33 Uhr, schrieb Walter Bright <newshound2@digitalmars.com>:

> On 10/21/2011 4:32 PM, Fawzi Mohamed wrote:
>>
>> On Oct 21, 2011, at 4:20 PM, Fawzi Mohamed wrote:
>>
>>> The main problem with this approach is how to support different versions of
>>> a library, or of OS. It quickly becomes difficult to support anything but
>>> the latest, or a fixed version. It works beautifully for mature libs.
>
> Since github has excellent support for branches, I don't see why this is a major problem.
>
>
>>> I still cannot avoid thinking that a C frontend automatically generating D
>>> modules with the help of recipes would be a better way. It will need some
>>> manual intervention for "difficult" cases, mainly giving manual translation
>>> of some macros, but it should be small.
>>
>> … and it seems that in the time I was offline others came up with the same
>> idea...
>
> It's an old idea. The trouble is, as always, the C preprocessor. I'm currently converting the openssl .h files, and they are a zoo of metaprogramming using C preprocessor macros.
>
> People are going to demand perfect translation if it is automatic.
>
> The only way to do it is to work with the preprocessed output of the .h file, and just forget about the preprocessor.

Doesn't that mean no #ifdef WINDOWS ?

Am 21.10.2011, 10:32 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>:

> That's ALL you can do in C. fill structs and call functions
> (fundamental type manipulation doesn't count).
> My personal research shows the following use cases of C macros (sorted
> by popularity in descending order):
> 1. enum
> 2. alias (most notably, conditionally compiled ones)
> 3. CTFE function
> 4. mixin template
> 5. syntactic alias
> 6. syntactic mixin template
>
> only the last 2 out of 6 cannot be translated to D.
> An example of a syntactic alias is this very common piece of C code:
> #ifdef __VERY_VERY_OLD_C_COMPILER__
>     #define CONST
> #else
>     #define CONST const
> #endif

Maybe these cases can often be solved when, as you say, they are for compatibility with other compilers. The header converter would simply assume to be the latest and greatest of the known compilers and evaluate the code like this:
- there is an #ifdef
- if it a define from the list of "known C compilers with quirks"
  - jump right to the else block
The #define obviously can become more than one thing in the .d file. But that is determined by the instantiation site. The above CONST would probably be ignored when it is used in a const parameter declaration, because of D's transitivity and become 'immutable __gshared' when used on a global variable. Do you get the idea?