parabolis wrote:

> h3r3tic wrote:
> 
>> Though about it for a longer moment and the best option now really seems to have a good tool that would generate the headers. That tool should, being open-source and crossplatform would be used in every IDE so that one would only click on an icon 'generate headers' or sth like that and immediately have them with no pain at all. I think this wouldnt hurt anybody
> 
> 
> It would be more universal (and ergo more helpful) if it were actually a compiler option...

the front-end source is available, no?

Perhaps you could code it up and submit a patch to Walter.  Then it would be a compiler option

Scott

Martin M. Pedersen wrote:

> Because the binary code that the D compiler emits now, does not include all
> that information, it does not mean that it could not be made to do it. I
> cannot imagine that there is not a way to put that information into object
> files and/or libraries. It could be as simple a producing the stripped down
> version of the input source file and put it into the object files as some
> predefined symbol or stuff it into a comment field. No new file formats
> needs to be invented - only a built-in "stripper" in the compiler and the
> ability to parse a source embedded in an object file.

This is actually an intriguing idea. (Besides the fact that humans would not be able to read the stripped down files.) The OMF format (which is what dm uses) does have a comment field that might be repurposed to do just that. (COMMENT type 0xDA should work)

stonecobra wrote:
> parabolis wrote:
> 
>> h3r3tic wrote:
>>
>>> Though about it for a longer moment and the best option now really seems to have a good tool that would generate the headers. That tool should, being open-source and crossplatform would be used in every IDE so that one would only click on an icon 'generate headers' or sth like that and immediately have them with no pain at all. I think this wouldnt hurt anybody
>>
>>
>>
>> It would be more universal (and ergo more helpful) if it were actually a compiler option...
> 
> 
> the front-end source is available, no?
> 
> Perhaps you could code it up and submit a patch to Walter.  Then it would be a compiler option

That is a good point... Although I was just thinking over Martin M. Pedersen's post in which he suggested shoving it all into an .obj file which would happen in the optlink...

Charlie wrote:
> Ive gotten the DMD front-end to compile ( super cool design i might add!) , and

Great!

> am working out the details of the symbol table ( i dont have any experience with
> this sort of thing ) , but it actually shouldnt be too hard to write a stripper
> tool given the front end.  In fact its doable right now, I plan to work on this

For what it's worth, dig's strip.d isn't particularly long, but it's filled with "pointer magic" that hurts my brain to look at it. It's probably easy to understand for someone experienced in C++, but it doesn't seem like a very D way of doing it.

> when I get back from vacation ( pop quiz, what state is the self proclaimed
> Sportsmans Paradise  :) ).

Have fun!

> 
> Charlie
> 
> In article <cebo1r$1p37$1@digitaldaemon.com>, Niko Korhonen says...
> 
>>Thanks for the responses everyone! I already suspected that I had to provide some sort of stripped-down (let's not call them headers) versions of the source code.
>>
>>Ok, this works well enough. Technically I'm against having /two/ sets of source files since they are bound to drift apart as time goes by.
>>
>>How nightmarish C/C++ headers may be, they still work well enough since the compiler processes them too, hopefully emitting a warning if the interface and implementation differ too much. But if I'm keeping two sets of D source, I develop actively the other set and pretty much ignore the "header" (Ok, now I called it a header) set. Since the compiler doesn't check these "headers" while compiling the library, there's probably going to be some nasty surprises sooner or later.
>>
>>The Java/.NET way of using only one set of source files is IMO definitely the way to go. But I guess what is done with Java/.NET (distribute only .jar or .dll files, no headers or source code) is impossible in D, since Bytecode/MSIL contains all the information the source code does. The binary code that C/C++/D compiler emits doesn't.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Niko Korhonen wrote:
> Thanks for the responses everyone! I already suspected that I had to provide some sort of stripped-down (let's not call them headers) versions of the source code.
> 
> Ok, this works well enough. Technically I'm against having /two/ sets of source files since they are bound to drift apart as time goes by.
> 
> How nightmarish C/C++ headers may be, they still work well enough since the compiler processes them too, hopefully emitting a warning if the interface and implementation differ too much. But if I'm keeping two sets of D source, I develop actively the other set and pretty much ignore the "header" (Ok, now I called it a header) set. Since the compiler doesn't check these "headers" while compiling the library, there's probably going to be some nasty surprises sooner or later.
> 
> The Java/.NET way of using only one set of source files is IMO definitely the way to go. But I guess what is done with Java/.NET (distribute only .jar or .dll files, no headers or source code) is impossible in D, since Bytecode/MSIL contains all the information the source code does. The binary code that C/C++/D compiler emits doesn't.

If this is really important to you, I don't know why we (and by we and mean Walter) couldn't implement a .dar file format. It could be .zip-format file containing stripped headers and a corresponding .lib. This is definitely post-1.0 talk, but I don't think it'd have to be too hard. We'd want to get the compiler to write .dar files (as well as read them).

I suppose if someone was really industrious that could create a tool to do all of this now as a build system that calls dmd.exe and lib.exe. (And, no, I'm not that person. I'm busy doing other stuff...)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

In article <ceccnk$21uc$1@digitaldaemon.com>, parabolis says...

>It would be more universal (and ergo more helpful) if it were actually a compiler option...

<rant>
It would be "helpful" only for those people wishing to hide their source code
from the rest of us.

Make the closed source brigade do their own dirty work, I say. If they're going
to be charging us money for their closed source software they can damn well pay
for their own stripping tool.
</rant>

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cectuh$2aa6$1@digitaldaemon.com...
> In article <ceccnk$21uc$1@digitaldaemon.com>, parabolis says...
>
> >It would be more universal (and ergo more helpful) if it were
> >actually a compiler option...
>
> <rant>
> It would be "helpful" only for those people wishing to hide their source code
> from the rest of us.
>
> Make the closed source brigade do their own dirty work, I say. If they're going
> to be charging us money for their closed source software they can damn well pay
> for their own stripping tool.
> </rant>

I trust that was wind-up?

It most certainly should be an option in the compiler. Absence of such is not going to persuade people to release their IP, it will merely dissuade them from using D.

Arcane Jill wrote:
> It would be "helpful" only for those people wishing to hide their source code
> from the rest of us.

I'm not asking "how can I close my sources" just out of spite. In fact, I /am/ a fan of open source, and all of my personal projects are BSD-licensed anyway.

But the fact is that not all software development is done by open source -oriented individuals. Only a small minority of it is. It's a common business practice not to divulge your intellectual property. I asked the question strictly with business considerations of the D language in mind.

J C Calvarese wrote:
> If this is really important to you, I don't know why we (and by we and mean Walter) couldn't implement a .dar file format. It could be .zip-format file containing stripped headers and a corresponding .lib. 

While I can't say that doesn't sound tempting, I'll say no. It's not really /that/ important. It doesn't apply to me or my personal developing methodologies very much, what I asked was more of a theoretical question for (future) business aspects of D.

I asked whether distributing closed-source libraries for D is possible, and I got my answer. I'm satisfied. It's currently about as easy as in C, I just have to write additional "header" files. If I'm targeting a widely-usable C library, I going to have to use extern(C) and write the C headers anyway.

What you suggested or what Martin M. Pedersen said about putting the necessary information into .obj/.lib files /would/ be a relief though, and it would push D a notch into the Java/.NET realm. Whether this is desirable or not is probably a subject of debate.

But no, as of yet this isn't necessary. If a required number of people start asking about this, *then* you could possibly take it into consideration :)

"Niko Korhonen" <niktheblak@hotmail.com> wrote in message news:cedfu1$2ifg$1@digitaldaemon.com...
> Arcane Jill wrote:
> > It would be "helpful" only for those people wishing to hide their source code from the rest of us.
>
> I'm not asking "how can I close my sources" just out of spite. In fact, I /am/ a fan of open source, and all of my personal projects are BSD-licensed anyway.
>
> But the fact is that not all software development is done by open source -oriented individuals. Only a small minority of it is. It's a common business practice not to divulge your intellectual property. I asked the question strictly with business considerations of the D language in mind.

Quite right. The idea that all software must be open-source is indicative of a peurile notion amongst many NG-hangers, i.e. that everything in the IT world should be free. I've never had a paying client for whom an open-source model could ever conceivably be appropriate. To not recognise this, or to not care, is simply stupid, and demonstrates an attitude that is not commensurate with the long term aims of D (and of Walter).

I completely agree that the DMD distribution should include tools to assist with closed-source development, and urge Walter (or anyone with a bit of spare time) to consider how we can get this with 1.0.