Jump to page: 1 2
Thread overview
import and commercial software
Jun 04, 2004
Ted Williams
Jun 04, 2004
Walter
Jun 04, 2004
Stephan Wienczny
Jun 06, 2004
Ted Williams
Jun 06, 2004
Walter
Jun 06, 2004
Ted Williams
Jun 06, 2004
Arcane Jill
Jun 06, 2004
Ted Williams
Jun 06, 2004
Stephan Wienczny
Jun 06, 2004
Martin M. Pedersen
Jun 07, 2004
Ilya Minkov
Jun 07, 2004
J C Calvarese
Jun 09, 2004
Walter
Jun 09, 2004
Walter
Jun 10, 2004
Marco A
June 04, 2004
It would seem based on the descriptions of import I have seen that in order to link to a library written in D You need to have access to the source of the library at the time you are compiling the client.  How does this work for commercial software where it is undesirable for the user to have access to the full source of the library?

Thanks,
Ted


June 04, 2004
"Ted Williams" <ted.wil.no.spam@verizon.net> wrote in message news:c9qim8$1hq2$1@digitaldaemon.com...
> It would seem based on the descriptions of import I have seen that in
order
> to link to a library written in D You need to have access to the source of the library at the time you are compiling the client.  How does this work for commercial software where it is undesirable for the user to have
access
> to the full source of the library?

Take a look at std.gc and internal/gc/gc.d for a demonstration.


June 04, 2004
You simply strip of everything...
Imports don't have to contain the full source code. All you have to provide are the declarations.

module A;

void _func();

module B;
import A;

int main(char[][] argv)
{
	_func();
	return 0;
}

Now you will have to link against the object file that contains A.

Ted Williams wrote:
> It would seem based on the descriptions of import I have seen that in order
> to link to a library written in D You need to have access to the source of
> the library at the time you are compiling the client.  How does this work
> for commercial software where it is undesirable for the user to have access
> to the full source of the library?
> 
> Thanks,
> Ted
> 
> 
June 06, 2004
So what you are saying is that I will have to maintain two of everything? One version with the full source to compile the library and one "stripped" version with just declarations?

"Stephan Wienczny" <wienczny@web.de> wrote in message news:c9qjkc$1j42$1@digitaldaemon.com...
> You simply strip of everything...
> Imports don't have to contain the full source code. All you have to
> provide are the declarations.
>
> module A;
>
> void _func();
>
> module B;
> import A;
>
> int main(char[][] argv)
> {
> _func();
> return 0;
> }
>
> Now you will have to link against the object file that contains A.
>
> Ted Williams wrote:
> > It would seem based on the descriptions of import I have seen that in
order
> > to link to a library written in D You need to have access to the source
of
> > the library at the time you are compiling the client.  How does this
work
> > for commercial software where it is undesirable for the user to have
access
> > to the full source of the library?
> >
> > Thanks,
> > Ted
> >
> >


June 06, 2004
"Ted Williams" <ted.wil.no.spam@verizon.net> wrote in message news:c9uopb$1hkl$1@digitaldaemon.com...
> So what you are saying is that I will have to maintain two of everything? One version with the full source to compile the library and one "stripped" version with just declarations?

Yes, just like in C++. However, it would be fairly easy to write a D tool to take the source and 'strip' it.


June 06, 2004
This sounds an aweful lot like header files, which I thought import was supposed to eliminiate the need for.  I have a solution in mind if you'd like to hear it.

"Walter" <newshound@digitalmars.com> wrote in message news:c9vn3c$2qod$1@digitaldaemon.com...
>
> "Ted Williams" <ted.wil.no.spam@verizon.net> wrote in message news:c9uopb$1hkl$1@digitaldaemon.com...
> > So what you are saying is that I will have to maintain two of
everything?
> > One version with the full source to compile the library and one
"stripped"
> > version with just declarations?
>
> Yes, just like in C++. However, it would be fairly easy to write a D tool
to
> take the source and 'strip' it.
>
>


June 06, 2004
In article <c9vv4i$4ao$1@digitaldaemon.com>, Ted Williams says...
>
>This sounds an aweful lot like header files, which I thought import was supposed to eliminiate the need for.

It's the price you pay for not being open-source.


>I have a solution in mind if you'd
>like to hear it.

Well /I'm/ intrigued. Let rip...




June 06, 2004
OK...what if the compiler, based on a switch, would generate a pre-compiled "module" file from the source file it is compiling.  Whenever a module is referenced via import, first this pre-comled file would be searched for and used if found, otherwise the corresponding source file would be imported as is now.

So, to compile a library module I might have:

    dmd -c -genimport myModule.d        Generates object and import file
myModule.imp for myModule.d

Then, when the libary is shipped, only the .imp files are sent with it.

Probably there is a better solution, but this is my stab at it.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca00rh$6tk$1@digitaldaemon.com...
> In article <c9vv4i$4ao$1@digitaldaemon.com>, Ted Williams says...
> >
> >This sounds an aweful lot like header files, which I thought import was supposed to eliminiate the need for.
>
> It's the price you pay for not being open-source.
>
>
> >I have a solution in mind if you'd
> >like to hear it.
>
> Well /I'm/ intrigued. Let rip...
>
>
>
>


June 06, 2004
I think it would be easier to do it the way Walter suggested.
You could have a small tool that removes every implementation from the sources and copys it into a new import tree.
You would like to have precompiled files. Could you please explain how the one you are selling your lib should know whats in you lib? If you have a plain source file you can look there...

Stephan

Ted Williams wrote:
> OK...what if the compiler, based on a switch, would generate a pre-compiled
> "module" file from the source file it is compiling.  Whenever a module is
> referenced via import, first this pre-comled file would be searched for and
> used if found, otherwise the corresponding source file would be imported as
> is now.
> 
> So, to compile a library module I might have:
> 
>     dmd -c -genimport myModule.d        Generates object and import file
> myModule.imp for myModule.d
> 
> Then, when the libary is shipped, only the .imp files are sent with it.
> 
> Probably there is a better solution, but this is my stab at it.
> 
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message
> news:ca00rh$6tk$1@digitaldaemon.com...
> 
>>In article <c9vv4i$4ao$1@digitaldaemon.com>, Ted Williams says...
>>
>>>This sounds an aweful lot like header files, which I thought import was
>>>supposed to eliminiate the need for.
>>
>>It's the price you pay for not being open-source.
>>
>>
>>
>>>I have a solution in mind if you'd
>>>like to hear it.
>>
>>Well /I'm/ intrigued. Let rip...
>>
>>
>>
>>
> 
> 
> 
June 06, 2004
"Ted Williams" <ted.wil.no.spam@verizon.net> wrote in message news:ca01jj$7vg$1@digitaldaemon.com...
> OK...what if the compiler, based on a switch, would generate a
pre-compiled
> "module" file from the source file it is compiling.

I don't know if it is feasable, but it would be simpler if a compiled object file could be imported directly. My idea is to store the needed information in the object file along with the code, but in such a way that the linker will ignore it. It could be stored in some binary pre-compiled format, or simply as stripped-down source text that the parser can use.


« First   ‹ Prev
1 2