In article <dle3ro$c8h$1@digitaldaemon.com>, pragma says...
>
>I'll try to answer the bits that haven't been covered yet. :)
>
>In article <dld5lt$2l18$1@digitaldaemon.com>, Dave says...
>>
>>2) Is there anything started for emitting 'header' source code for static libs?
>
>Nope. But I think it's been brought up before.
>
>One problem with this concept is that D symbol information contains more than enough information to reproduce a D-header quite easily.  Everything else (C/C++ mostly) defies reproduction when working with an intermediate file.  Now if that doesn't seem like a problem then it should be quite easy to cobble together such a utility: the current codebase in SVN already has the parts to do most of this.
>

The reason I ask is because I'm thinking it would be cool if the 'consumer' of a library could use DDL to either dynamically load the library or create 'header' files with which to statically link; their choice. And, if the header generator was built into or called by the compiler, without the hassle of more than one set of files to maintain.. The compiler generates the 'headers' when it needs them and then disposes of them.

>>3) I'm not familiar with the .ddl format or what it is capable of -
>
>The .ddl format allows for a clean, portable way to refer to intermediate (object) files without having to manage a constellation of file-types and extensions.  The format is really just a wrapper, which stores some information about the enclosed binary file in the header.
>
>The .ddl header information contains, but is not limited to:
>- the name of the (original) enclosed binary
>- the binary's type (independent of its file extension) like OMF or COFF
>- arbitrary metadata (planned)
>
>> is it (capable of) extracting function body code as well?
>
>Not in a way that would reproduce the original source code.  All the binary file support in DDL is only as capable as what we have for .dll files right now, with the addtion of resolving external dependencies and fixups.
>

Not reproducing the original source code sounds great from a 'code security' perspective for those concerned about it -- how about in a way that would emit legal D source code (even if it's in asm{} blocks) to allow functions to be inlined at compile time?

What I have in mind is basically a 'header file' generated as above where functions are not only declared but defined in such a way so that a compiler could examine them, and inline or otherwise optimize based on this information.

Alot to ask for or even mention, no? <g>

Don't get me wrong - DDL is nice as-is and would be huge for D. Just thinking out loud..

>- EricAnderton at yahoo

In article <dlec9i$3vm$1@digitaldaemon.com>, Dave says...
>
>Not reproducing the original source code sounds great from a 'code security' perspective for those concerned about it -- how about in a way that would emit legal D source code (even if it's in asm{} blocks) to allow functions to be inlined at compile time?
>
>What I have in mind is basically a 'header file' generated as above where functions are not only declared but defined in such a way so that a compiler could examine them, and inline or otherwise optimize based on this information.

This is certainly possible.  What you're suggesting is a hybrid between what OBJ2ASM and a D header generator; you get a .d file instead of an .asm file is all.  Its quite the concept, especially since it invites the compiler to do what it does best.  However, I'm skeptical as to how DMD treats "naked asm{}" functions with respect to inlining.

To accomplish this, the various DDL binary types would have to expose a little more metadata than usual (returning exports as raw byte[] for starters), and the demangler would be put to use in creating the needed D stub code.  Fixups would have to be translated into D symbols suitable for recompilation, ModuleInfo parts get thrown out and re-done imports and "static this()"... it can be done, but its not trivial.

I'll see what I can do for chalking the door open for this.  Its a neat idea, and would open DDL up to supporting object-format translators as well.

>
>Alot to ask for or even mention, no? <g>

Not really.  Its just a new direction... something I didn't give much thought to before.

>
>Don't get me wrong - DDL is nice as-is and would be huge for D. Just thinking out loud..

The envelope is made to be pushed around.  I don't think we've tapped D's potential yet, so please don't quit "thinking out loud".

- EricAnderton at yahoo

In article <dleg0q$6l6$1@digitaldaemon.com>, pragma says...
>
>In article <dlec9i$3vm$1@digitaldaemon.com>, Dave says...
>>
>>Not reproducing the original source code sounds great from a 'code security' perspective for those concerned about it -- how about in a way that would emit legal D source code (even if it's in asm{} blocks) to allow functions to be inlined at compile time?
>>
>>What I have in mind is basically a 'header file' generated as above where functions are not only declared but defined in such a way so that a compiler could examine them, and inline or otherwise optimize based on this information.
>
>This is certainly possible.  What you're suggesting is a hybrid between what OBJ2ASM and a D header generator; you get a .d file instead of an .asm file is all.  Its quite the concept, especially since it invites the compiler to do what it does best.  However, I'm skeptical as to how DMD treats "naked asm{}" functions with respect to inlining.
>

I've been playing with that stuff a little so I know that a function with an asm{} statement is basically flagged as not inlinable right now, so some work would have to be done here definitely.

Maybe the possibility of getting rid of needing to distribute anything but library binaries would be enough to change that.

>To accomplish this, the various DDL binary types would have to expose a little more metadata than usual (returning exports as raw byte[] for starters), and the demangler would be put to use in creating the needed D stub code.  Fixups would have to be translated into D symbols suitable for recompilation, ModuleInfo parts get thrown out and re-done imports and "static this()"... it can be done, but its not trivial.
>
>I'll see what I can do for chalking the door open for this.  Its a neat idea, and would open DDL up to supporting object-format translators as well.
>
>>
>>Alot to ask for or even mention, no? <g>
>
>Not really.  Its just a new direction... something I didn't give much thought to before.
>
>>
>>Don't get me wrong - DDL is nice as-is and would be huge for D. Just thinking out loud..
>
>The envelope is made to be pushed around.  I don't think we've tapped D's potential yet, so please don't quit "thinking out loud".
>

In my mind, the ultimate goal would be to have the ability to distribute 3 or 4 files for a standardized base compiler distribution:

- The compiler executable.
- The DDL executable to create either the .ddl file or 'header' input for the
compiler to use 'on the fly'.
- The standard runtime lib.
- Linker

If we could then get the compiler to optimize using the 'header' input for static builds, we would not have to sacrifice anything.

Maybe even bigger would be that 3rd party lib. developers could distribute one file, and bigger yet would be that the end-user wouldn't have to worry about keeping 'headers' and binaries in sync. This would actually make distributing and using libraries /easier/ than Java or .NET all while keeping the same performance potential.

>- EricAnderton at yahoo

Dave wrote:
> Just curious, how important would COFF be unless MS decided to support D in a
> big way (fat chance <g>)?

Very important, for me at least. The inability of DMD to directly link to COFF libraries is a show-stopper for several of my projects, and is the only reason why they must remain in C++. The commercial libraries which I use* are in COFF format, and it is illegal to redistribute them in a different format. In this case, because of the requirement to purchase COFF2OMF, D does not operate as free software. I appreciate the necessity for revenue protection of DMC -- it's just a shame we don't have a COFF2OMF that is free for D but which wouldn't work for DMC. Sounds like DDL could solve that problem.

* eg libraries for interfacing to A/D cards. Supplied by the vendor of the A/D boards.