www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - import and commercial software

reply "Ted Williams" <ted.wil.no.spam verizon.net> writes:
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
Jun 04 2004
next sibling parent "Walter" <newshound digitalmars.com> writes:
"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

 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

 to the full source of the library?

Take a look at std.gc and internal/gc/gc.d for a demonstration.
Jun 04 2004
prev sibling parent reply Stephan Wienczny <wienczny web.de> writes:
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
 
 

Jun 04 2004
parent reply "Ted Williams" <ted.wil.no.spam verizon.net> writes:
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


 to link to a library written in D You need to have access to the source


 the library at the time you are compiling the client.  How does this


 for commercial software where it is undesirable for the user to have


 to the full source of the library?

 Thanks,
 Ted


Jun 06 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 06 2004
next sibling parent reply "Ted Williams" <ted.wil.no.spam verizon.net> writes:
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


 One version with the full source to compile the library and one


 version with just declarations?

Yes, just like in C++. However, it would be fairly easy to write a D tool

 take the source and 'strip' it.

Jun 06 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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...
Jun 06 2004
parent reply "Ted Williams" <ted.wil.no.spam verizon.net> writes:
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...

Jun 06 2004
next sibling parent Stephan Wienczny <wienczny web.de> writes:
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...


Jun 06 2004
prev sibling next sibling parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"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

 "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.
Jun 06 2004
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ted Williams schrieb:

 OK...what if the compiler, based on a switch, would generate a pre-comp=

 "module" file from the source file it is compiling.  Whenever a module =

 referenced via import, first this pre-comled file would be searched for=

 used if found, otherwise the corresponding source file would be importe=

 is now.

If i recall correctly, Walter's original plan involved caching an=20 intermediate representation for modules in a binary format, which would=20 as a side effect allow to do the same you propose. However, the parser=20 has turned out so fast, that this feature lost most of its technical=20 motivation and has been put off. Maybe Walter would implement something=20 like that in the first commercial D compiler. Naturally, if you liked you could take the source and implement the=20 feature. However, this doesn't mean that the implementation would be=20 accepted by the distributions, and there's another aspect: the=20 implementation would be public, so as soon as D gains more users, tools=20 will start to appear which would regain major parts of the source code=20 from th=EDs representation. From some point of popularity, roughly the=20 same would happen even with format being closed. Besides, when you do a=20 binary-only distribution, you can make it for a limited number of=20 compilers and operating systems, thus some people won't be able to use=20 it. So i see some people sell their libraries with source. digc compiler driver (a neat tool by itself: see undig at dsource) can=20 do stripped versions ("headers") of libraries. -eye
Jun 07 2004
parent J C Calvarese <jcc7 cox.net> writes:
Ilya Minkov wrote:
 Ted Williams schrieb:
 
 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.

If i recall correctly, Walter's original plan involved caching an intermediate representation for modules in a binary format, which would as a side effect allow to do the same you propose. However, the parser has turned out so fast, that this feature lost most of its technical motivation and has been put off. Maybe Walter would implement something like that in the first commercial D compiler. Naturally, if you liked you could take the source and implement the feature. However, this doesn't mean that the implementation would be accepted by the distributions, and there's another aspect: the implementation would be public, so as soon as D gains more users, tools will start to appear which would regain major parts of the source code from thÝs representation. From some point of popularity, roughly the same would happen even with format being closed. Besides, when you do a binary-only distribution, you can make it for a limited number of compilers and operating systems, thus some people won't be able to use it. So i see some people sell their libraries with source. digc compiler driver (a neat tool by itself: see undig at dsource) can do stripped versions ("headers") of libraries. -eye

Some of dig has accumulated some dust since Burton Radons stopped working on it. The strip.d module is one of those parts. I've just made some improvements to it, but I'm sure it'll still malfunction on some bits of valid D code. See also: http://www.dsource.org/forums/viewtopic.php?t=196 -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jun 07 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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

 "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

 used if found, otherwise the corresponding source file would be imported

 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.

That's really no different from a 'strip' utility.
Jun 09 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
news:c9vv4i$4ao$1 digitaldaemon.com...
 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.

Import does eliminate the need for it, unless you want to hide the source.
Jun 09 2004
prev sibling parent Marco A <Marco_member pathlink.com> writes:
In article <c9vn3c$2qod$1 digitaldaemon.com>, Walter says...
"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.

Putting both the interface and the implementation in a single file doesn't mean those separate concepts go away
Jun 09 2004