digitalmars.D - import and commercial software
- "Ted Williams" <ted.wil.no.spam verizon.net> Jun 04 2004
- "Walter" <newshound digitalmars.com> Jun 04 2004
- Stephan Wienczny <wienczny web.de> Jun 04 2004
- "Ted Williams" <ted.wil.no.spam verizon.net> Jun 06 2004
- "Walter" <newshound digitalmars.com> Jun 06 2004
- "Ted Williams" <ted.wil.no.spam verizon.net> Jun 06 2004
- Arcane Jill <Arcane_member pathlink.com> Jun 06 2004
- "Ted Williams" <ted.wil.no.spam verizon.net> Jun 06 2004
- Stephan Wienczny <wienczny web.de> Jun 06 2004
- "Martin M. Pedersen" <martin moeller-pedersen.dk> Jun 06 2004
- Ilya Minkov <minkov cs.tum.edu> Jun 07 2004
- J C Calvarese <jcc7 cox.net> Jun 07 2004
- "Walter" <newshound digitalmars.com> Jun 09 2004
- "Walter" <newshound digitalmars.com> Jun 09 2004
- Marco A <Marco_member pathlink.com> Jun 09 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
Jun 04 2004
"Walter" <newshound digitalmars.com> "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
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
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
"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
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
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
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
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
"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
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
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
"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
"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
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