What is the best way to provide a D library with a D header (well, I've read
"there's no need of headers in D"... but there is so it seems).
Do we still have to keep the D source, and a separate (manualy extracted) D
declaration with a lib?

ElfQT

ElfQT wrote:
> What is the best way to provide a D library with a D header (well, I've read "there's no need of headers in D"... but there is so it seems).
> Do we still have to keep the D source, and a separate (manualy extracted) D declaration with a lib?
> 
> ElfQT 
> 
> 

It is technically possible to add support for headerlessness (that's a mouthful!) in D.  But such a feature has not yet been implemented yet. Until such a time, nobody should be bragging about D having such capabilities. :-)

-JJR

I suspected that.
OK, what can I do with the next:

I have a library. That's a D lib. With .d "headers".
Then I have some samples. These should share some common files. (This all
caomes from c++, yeah). The original layout would be:
MyLibProjFolder
MyLibProjFolder\Main                        -- this is the lib with all the
D files and lib output
MyLibProjFolder\Samples                   -- containing the following:
MyLibProjFolder\Samples\Common    -- comon files, mostly declarations, used
by all sample (as source, not lib or anything)
MyLibProjFolder\Sample1                   -- D files compiling into exe
MyLibProjFolder\SampleN                  -- detto

The problem is with imports.
MyLibProjFolder\Samples\Common\all.d or similar should contain all the
imports needed for the samples using the Main lib.
I don't know how to import any Common module or even Main lib module into
Sample1.
I get errors like
"ExampleApplication.d(21): module all cannot read file 'all.d'"

How to properly do the layout? What am I missing from the great importing schema?

ElfQT


"John Reimer" <brk_6502@yahoo.com> wrote in message news:dfku2c$1lat$1@digitaldaemon.com...
> ElfQT wrote:
>> What is the best way to provide a D library with a D header (well, I've
>> read "there's no need of headers in D"... but there is so it seems).
>> Do we still have to keep the D source, and a separate (manualy extracted)
>> D declaration with a lib?
>>
>> ElfQT
>
> It is technically possible to add support for headerlessness (that's a mouthful!) in D.  But such a feature has not yet been implemented yet. Until such a time, nobody should be bragging about D having such capabilities. :-)
>
> -JJR

ElfQT wrote:
> I suspected that.
> OK, what can I do with the next:
> 
> I have a library. That's a D lib. With .d "headers".
> Then I have some samples. These should share some common files. (This all caomes from c++, yeah). The original layout would be:
> MyLibProjFolder
> MyLibProjFolder\Main                        -- this is the lib with all the D files and lib output
> MyLibProjFolder\Samples                   -- containing the following:
> MyLibProjFolder\Samples\Common    -- comon files, mostly declarations, used by all sample (as source, not lib or anything)
> MyLibProjFolder\Sample1                   -- D files compiling into exe
> MyLibProjFolder\SampleN                  -- detto
> 
> The problem is with imports.
> MyLibProjFolder\Samples\Common\all.d or similar should contain all the imports needed for the samples using the Main lib.
> I don't know how to import any Common module or even Main lib module into Sample1.
> I get errors like
> "ExampleApplication.d(21): module all cannot read file 'all.d'"
> 
> How to properly do the layout? What am I missing from the great importing schema?

Given ...

samples\common\all.d
samples\sample.d


-- all.d --
module common.all;
--


-- sample.d --
import common.all;
--



> 
> ElfQT
> 
> 
> "John Reimer" <brk_6502@yahoo.com> wrote in message news:dfku2c$1lat$1@digitaldaemon.com...
> 
>>ElfQT wrote:
>>
>>>What is the best way to provide a D library with a D header (well, I've read "there's no need of headers in D"... but there is so it seems).
>>>Do we still have to keep the D source, and a separate (manualy extracted) D declaration with a lib?
>>>
>>>ElfQT
>>
>>It is technically possible to add support for headerlessness (that's a mouthful!) in D.  But such a feature has not yet been implemented yet. Until such a time, nobody should be bragging about D having such capabilities. :-)
>>
>>-JJR 
> 
> 
> 

(I've just noticed I've mistyped the subject, sorry (library header), that
must be the painkiller I took. (Not because of the confusing import stuff ;)
don't worry.))
So, the starting point of dmd.exe (or working directory or whatever) _has_
to be a common root?
All imports will be looked in the folder (directory) with corresponding
name?

So it is impossible (or real hard for a mortal like me) to compile from a
child folder? Well, I don't need that anyway.
But what about another sample exe somewhere else on the harddisk, which
would like to use the original sample\common (and the Main lib)?

Sorry for being confused :p, if you can point me to a more described place than the dm original doc, that would be welcome. (... err, well and if there is no any then maybe there should be... something like "module organization, referencing modules and libraries")

Thanks,
 ElfQT

ElfQT escribió:
> (I've just noticed I've mistyped the subject, sorry (library header), that must be the painkiller I took. (Not because of the confusing import stuff ;) don't worry.))
> So, the starting point of dmd.exe (or working directory or whatever) _has_ to be a common root?
> All imports will be looked in the folder (directory) with corresponding name?
> 
> So it is impossible (or real hard for a mortal like me) to compile from a child folder? Well, I don't need that anyway.
> But what about another sample exe somewhere else on the harddisk, which would like to use the original sample\common (and the Main lib)?
> 
> Sorry for being confused :p, if you can point me to a more described place than the dm original doc, that would be welcome. (... err, well and if there is no any then maybe there should be... something like "module organization, referencing modules and libraries")
> 
> Thanks,
>  ElfQT 
> 
> 

dmd (arguments) -Ipath_to_files -Ianother_path

-- 
Carlos Santander Bernal

On Wed, 7 Sep 2005 00:53:59 +0200, ElfQT <dethjunk@yahoo.com> wrote:
> (I've just noticed I've mistyped the subject, sorry (library header), that
> must be the painkiller I took. (Not because of the confusing import stuff ;)
> don't worry.))
> So, the starting point of dmd.exe (or working directory or whatever) _has_
> to be a common root?
> All imports will be looked in the folder (directory) with corresponding
> name?

Have a look in sc.ini in the dmd\bin directory.
It has a line which reads:

DFLAGS="-I%@P%\..\src\phobos"

the -I tells the D compiler where to look for imports. The %@p% refers to the dmd\bin directory. I have added the following ";%@P%\..\..\src" giving:

DFLAGS="-I%@P%\..\src\phobos;%@P%\..\..\src"

which tells the compiler to look in 2 directories for imports.

> So it is impossible (or real hard for a mortal like me) to compile from a
> child folder?

You can compile from anywhere (assuming you put dmd\bin in the PATH enviroment variable). It will only look for imports where you tell it to. If you want it to look for imports from the current directory you should be able to add -I. or -I.\ or -I./ to the command line you type (I haven't tried this, you could probably put it in sc.ini and have it always do it if you wanted)

Regan

In article <opswpfgoya23k2f5@nrage.netwin.co.nz>, Regan Heath says...

>you could probably put it in sc.ini and have it always do it if you wanted)

While this is true in theory, each new download of DMD replaces any changes you have made to sc.ini with the defaults again. This is why the Build utility uses an additional optional configuration file which supplements sc.ini.

It would be useful if DMD could use sc.ini and also use sc_user.ini if it exists...or something like that. We could then maintain our sc_user.ini without new releases messing things up.

-- 
Derek
Melbourne, Australia

On Wed, 7 Sep 2005 05:57:38 +0000 (UTC), Derek Parnell <Derek_member@pathlink.com> wrote:
> In article <opswpfgoya23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>> you could probably put it in sc.ini and have it always do it
>> if you wanted)
>
> While this is true in theory, each new download of DMD replaces any changes you
> have made to sc.ini with the defaults again. This is why the Build utility uses
> an additional optional configuration file which supplements sc.ini.
>
> It would be useful if DMD could use sc.ini and also use sc_user.ini if it
> exists...or something like that. We could then maintain our sc_user.ini without
> new releases messing things up.

This is true. I have a backup copy which is copied by my script for downloading and extracting the latest dmd.zip and dmc.zip. Having a 'user' config file would be nice. So might a per-project/per-library config file. ;)

Regan

Thanks Regan, and Carlos,
somehow I overlooked these settings.
ElfQT