This is an easy question (as I saw some people around here creating library files but never saw how using them).

Suppose I have two files:
apple.d  and  banana.d
I compile apple.d and insert the apple.obj into a library (called apple.lib
here)
Now I want to ship my "apple" code (but don't want to ship the source).
If anyone wants to use my apple.lib now how should he access the functions
in apple.lib? (syntax?)
I tried by just using the functions from the library and linking the library
in but that didn't seem to do the deal.

How do I have to declare the functions/classes in apple.d so they can be accessible in apple.lib later on(public?)?

Thanks,

Yannick Welsch

Yannick Welsch wrote:
> This is an easy question (as I saw some people around here creating library
> files but never saw how using them).
> 
> Suppose I have two files:
> apple.d  and  banana.d
> I compile apple.d and insert the apple.obj into a library (called apple.lib
> here)
> Now I want to ship my "apple" code (but don't want to ship the source).
> If anyone wants to use my apple.lib now how should he access the functions
> in apple.lib? (syntax?)
> I tried by just using the functions from the library and linking the library
> in but that didn't seem to do the deal.
> 
> How do I have to declare the functions/classes in apple.d so they can be
> accessible in apple.lib later on(public?)?
> 
> Thanks,
> 
> Yannick Welsch
> 
> 

Remember that the original module name must be referenced to access those funtions in order for the compiler to know how to lookup the names.

So typically you must first declare an "interface" module with the /same/ name as the module that is in the library:

// File: a.d

module a;

int functionA();
int funcitonB();

class A {
int methodA();
int methodB();
}

Import that name in, but don't compile that file.  Link with your original lib instead.  You should now be able to make calls to all a's methods and functions.

What you are probably trying to do is declare the external functions/classes inside your program module.  It won't work because it lacks a fully qualified name that directs the compiler to the right spot.

I hope that helps.

- John

John Reimer wrote:

>> Now I want to ship my "apple" code (but don't want to ship the source).
>> If anyone wants to use my apple.lib now how should he access the functions
>> in apple.lib? (syntax?)
>>
>> How do I have to declare the functions/classes in apple.d so they can be
>> accessible in apple.lib later on(public?)?
>
> Remember that the original module name must be referenced to access those funtions in order for the compiler to know how to lookup the names.
> 
> So typically you must first declare an "interface" module with the /same/ name as the module that is in the library:

That sounds a whole lot like a header file to me ?
So, one must maintain a "stripped" file for each ?
And then keep those in sync, when it is updated...

The libraries in D that I have seen so far has been
a) open source b) without "make install", so I was
also wondering how to accomplish the same thing...

Was comparing to C (easy, ship the header file and lib)
and with Java (easy, dynamic linkage and "javap" tool)
D seems to be somewhere inbetween them, just as usual ?

I guess the moral is that we should all do Open Source :-)

--anders

Exactly the answer I needed ;)
> So typically you must first declare an "interface" module with the /same/ name as the module that is in the library:
Can't this be done automatically?
In Java there is no need to define such an "interface" module.
It would be nice if the compiler could give out such an "interface" module
in addition to the object file (As it has the capability to).

Many thanks,

Yannick Welsch


"John Reimer" <brk_6502@yahoo.com> wrote in message news:cp6u9v$1ski$1@digitaldaemon.com...
> Yannick Welsch wrote:
> > This is an easy question (as I saw some people around here creating
library
> > files but never saw how using them).
> >
> > Suppose I have two files:
> > apple.d  and  banana.d
> > I compile apple.d and insert the apple.obj into a library (called
apple.lib
> > here)
> > Now I want to ship my "apple" code (but don't want to ship the source).
> > If anyone wants to use my apple.lib now how should he access the
functions
> > in apple.lib? (syntax?)
> > I tried by just using the functions from the library and linking the
library
> > in but that didn't seem to do the deal.
> >
> > How do I have to declare the functions/classes in apple.d so they can be accessible in apple.lib later on(public?)?
> >
> > Thanks,
> >
> > Yannick Welsch
> >
> >
>
> Remember that the original module name must be referenced to access those funtions in order for the compiler to know how to lookup the names.
>
> So typically you must first declare an "interface" module with the /same/ name as the module that is in the library:
>
> // File: a.d
>
> module a;
>
> int functionA();
> int funcitonB();
>
> class A {
> int methodA();
> int methodB();
> }
>
> Import that name in, but don't compile that file.  Link with your original lib instead.  You should now be able to make calls to all a's methods and functions.
>
> What you are probably trying to do is declare the external functions/classes inside your program module.  It won't work because it lacks a fully qualified name that directs the compiler to the right spot.
>
> I hope that helps.
>
> - John
>
>
>

Yannick Welsch wrote:
> Exactly the answer I needed ;)
> 
>>So typically you must first declare an "interface" module with the
>>/same/ name as the module that is in the library:
> 
> Can't this be done automatically?
> In Java there is no need to define such an "interface" module.
> It would be nice if the compiler could give out such an "interface" module
> in addition to the object file (As it has the capability to).
> 
> Many thanks,
> 
> Yannick Welsch
> 
> 

This has been brought up before.  Automation of the task is as simple as creating a tool that does the stripping for you.  In fact I believe the library creation tool "digc" by Burton Radons has been able to do this for couple of years.  While it may be nice to have such a feature as part of the compiler, it's been argued that such a task is not strictly within the problem domain of the compiler.

I agree in one respect: such a tool should at least be made part of the compiler package.

Later,

John

Anders F Björklund wrote:

> 
> That sounds a whole lot like a header file to me ?
> So, one must maintain a "stripped" file for each ?
> And then keep those in sync, when it is updated...

Yeah, I guess it does.  A header file is pretty much what it is, although I find d import modules much easier on the eyes than C headers.  And yes, I guess you would have to keep the file in sync if you added functions or methods that you wanted to be public to the package.  With the proper build tool, though, keeping things in sync would not be much of an issue.  It would just be a matter of the make process updating the stripped file after every make.

> The libraries in D that I have seen so far has been
> a) open source b) without "make install", so I was
> also wondering how to accomplish the same thing...
>

Yep, the open source way has been the most popular method of distribution up til this point.  The "interface" method is much less talked about for some reason, although the steps have been in place almost since the compilers inception (phobos uses this method in one or two places).  A tutorial really needs to be made to advertise the possibility of an "interface" module for those that find open-sourcing their code undesirable.  We also need a standard build tool that works these wonders automatically, especially since gdc is here and crossplatform coding is now a real possibility.

> Was comparing to C (easy, ship the header file and lib)
> and with Java (easy, dynamic linkage and "javap" tool)
> D seems to be somewhere inbetween them, just as usual ?

It's only in between because no ones agressively promoted or developed tools that do the same thing for D (which isn't that hard to do).  Once again, I believe the we're nearing the time when such tools need to surface to make D development go more smoothly and be more attractive to people.  We also need a well-designed GUI and an IDE, too.  :-)  It seems work is already in progress in these areas, though.

> I guess the moral is that we should all do Open Source :-)
> 
> --anders

Opensource is what started the ball rolling.  :-)

Later,

John

John Reimer wrote:

> This has been brought up before.  Automation of the task is as simple as creating a tool that does the stripping for you.  In fact I believe the library creation tool "digc" by Burton Radons has been able to do this for couple of years.  While it may be nice to have such a feature as part of the compiler, it's been argued that such a task is not strictly within the problem domain of the compiler.

A demangler would be nice too, i.e. something that could convert
"_D5hello5helloFAaZv" into "module hello; void hello(char[] _a);"

Wonder if something like that has already been done for debugging ?

--anders

John Reimer wrote:

>> Was comparing to C (easy, ship the header file and lib)
>> and with Java (easy, dynamic linkage and "javap" tool)
>> D seems to be somewhere inbetween them, just as usual ?
> 
> It's only in between because no ones agressively promoted or developed tools that do the same thing for D (which isn't that hard to do).

Not only that, but D is also designed to be in-between... ?

So it's not really all that surprising, just that it has
the same issue as C++ does with striking a balance between
the two "extremes", also when it comes to compiling/linking.
(and I find it to be a very nice complement to the other two)

--anders

Anders F Björklund wrote:
> John Reimer wrote:
> 
>>> Was comparing to C (easy, ship the header file and lib)
>>> and with Java (easy, dynamic linkage and "javap" tool)
>>> D seems to be somewhere inbetween them, just as usual ?
>>
>>
>> It's only in between because no ones agressively promoted or developed tools that do the same thing for D (which isn't that hard to do).
> 
> 
> Not only that, but D is also designed to be in-between... ?
> 
> So it's not really all that surprising, just that it has
> the same issue as C++ does with striking a balance between
> the two "extremes", also when it comes to compiling/linking.
> (and I find it to be a very nice complement to the other two)
> 
> --anders


Ah, yes, I see.  Good point.

John Reimer wrote:

> I believe the we're nearing the time when such tools need to surface to make D development go more smoothly and be more attractive to people.  We also need a well-designed GUI and an IDE, too.  :-)  It seems work is already in progress in these areas, though.

Another thing that is needed is a documentation generator,
but Doxygen kinda works and Ant is working on a new D tool.
Otherwise one ends up with out-of-date documentation like
http://www.digitalmars.com/d/phobos.html (sorry, Walter)

Javadoc sets an example for such API documentation, IMHO.
http://java.sun.com/j2se/javadoc/ (but Doxygen is not bad)

>> I guess the moral is that we should all do Open Source :-)
> 
> Opensource is what started the ball rolling.  :-)

At least for me, since none of the Digital Mars compilers
works on the platforms that I am using (Mac OS X, Linux PPC)

--anders