• Matthew Wilson (7/7) Mar 17 2003 Is it the case that for compilation, the source of the dependent librari...
• J C Calvarese (17/27) Mar 17 2003 I think you'll have to reveal constants and types, but you can hide the
• Burton Radons (24/29) Mar 18 2003 Yeah. digc (a compilation utility packaged with dig

"Matthew Wilson" <dmd synesis.com.au> writes:

Is it the case that for compilation, the source of the dependent libraries
must be visible?

If so, are there any IP protection measures available?
If not, how do I bundle a library and allow dependent code to be compilable?
Also, is it possible to bundle such in a DLL, or must it be static lib?

Thanks

Matthew

J C Calvarese <jcc-47 excite.com> writes:

I think you'll have to reveal constants and types, but you can hide the 
body of your functions.

For example, if this was a function in your module:

int squareit(int i)
{
	return i * i;
}


Then you could give something like a prototype to your customer:

int squareit(int i);

They wouldn't see what your function actually does, or be able to 
re-compile the module, but they would be able to import your module.  I 
think this is what you want.

I don't know much about DLL's, but D can create them. Burton explained 
how to make a DLL (http://www.digitalmars.com/drn-bin/wwwnews?D/11884). 
  His example seems pretty helpful to me.  It gave me a functioning dll.

Justin


Matthew Wilson wrote:
 Is it the case that for compilation, the source of the dependent libraries
 must be visible?
 
 If so, are there any IP protection measures available?
 If not, how do I bundle a library and allow dependent code to be compilable?
 Also, is it possible to bundle such in a DLL, or must it be static lib?
 
 Thanks
 
 Matthew

Burton Radons <loth users.sourceforge.net> writes:

Matthew Wilson wrote:
 Is it the case that for compilation, the source of the dependent libraries
 must be visible?

Yeah.  digc (a compilation utility packaged with dig 
(http://www.opend.org/dig/arc/dig-0.0.11.zip)) will put stripped headers 
at the end of libraries it creates using the -lib= option.  It will then 
recreate these headers during compilation of users.  It also 
automatically links in necessary libraries based on import statements.

 If so, are there any IP protection measures available?

The stripped headers don't have any function bodies, unless if it's for 
a template.  Since these are libraries and the interface should be 
documented, it shouldn't be a loss.

 If not, how do I bundle a library and allow dependent code to be compilable?
 Also, is it possible to bundle such in a DLL, or must it be static lib?

Just add a "-shared" option to the digc command-line.

I'll try to organise the features into a set of bullet points.

- Compile libraries using the "-lib=name" option.  Don't provide an 
extension.  Do compile using the exact names you want to import - for 
example, if you want users to import a module using "foo.bar", you must 
compile it as "foo/bar.d".

- Use "-install" to put the created files in appropriate directories.

- Use "-shared" to create a DLL as well as the import library.  All 
public symbols are exported, so that it's closer to Linux shared 
libraries than Windows' goony nonsense.  If you use -install it will be 
put in Windows' system directory.

- Code is searched for import statements.  If a library matches an 
import the library and its dependencies are linked in, and the headers 
are recreated.  A full binary for a library, then, is the .lib file and 
the .dll if it has one.