Hi All,

I'm a hobby programmer and have been playing around with D for a few weeks. I usually make little games and have recently started a gui project using DWT. Not much gets finished but I have fun solving the problems and making stuff happen.

In the past I've used a bunch of different scripting languages, quite a bit of Basic and Pascal and a bit of C#. Most of these have been presented in a neat package where I can simply hit the build button and get an exe.

D is a little different in that you have to know a little more about what is going on when you try and build something. Well, perhaps you don't need to know it, but because it's exposed I find myself asking questions.

Anyhow, I guess thats my question. Is there somewhere I can go and read about the fundamentals of the build process?

Examples: What do each of the exe's in bm/bin do? In what order are they run? Why have a dm and a dmd folder. When I import a module, how does the build process find my source files. What the hell does pragma import do, I've read the docs but don't understand how this is different to linking to libs . etc...

If you guys don't know of anywhere this is already documented, do you think this list a good place to ask?  Perhaps I could add some of the answers I get to the wiki.

Any help much appreciated.

Jay Kyburz

Jay Kyburz wrote:
> Hi All,
> 
> I'm a hobby programmer and have been playing around with D for a few weeks. I usually make little games and have recently started a gui project using DWT. Not much gets finished but I have fun solving the problems and making stuff happen. 
> 
> In the past I've used a bunch of different scripting languages, quite a bit of Basic and Pascal and a bit of C#. Most of these have been presented in a neat package where I can simply hit the build button and get an exe. 
> 
> D is a little different in that you have to know a little more about what is going on when you try and build something. Well, perhaps you don't need to know it, but because it's exposed I find myself asking questions. 
> 
> Anyhow, I guess thats my question. Is there somewhere I can go and read about the fundamentals of the build process?

It may help to know that D is pretty much the same as C in that source files are compiled to an intermediate language (ie. object files) and then linked to produce an executable application.

> Examples: What do each of the exe's in bm/bin do? In what order are they run? Why have a dm and a dmd folder.

The dm folder contains the Digital Mars C compiler and linker, which is used both for linking and also possibly for code generation.  I've got a bunch of stuff in dm/bin so I can't come up with a list of default EXEs offhand, but 'lib' generates static libraries, 'make' is a make tool, 'link' is a linker, and I think 'sc' is an alias for 'dmc' which is the C compiler.

> When I import a module, how does the build
> process find my source files.

It looks in your include path, which is in dmd/bin/sc.ini as the -I portion of the DFLAGS variable.

> What the hell does pragma import do, I've read the docs but don't understand how this is different to linking to libs .  etc... 

You shouldn't need to use any pragmas for typical D applications, so don't worry about them.  But they are documented here: http://www.digitalmars.com/d/pragma.html

> If you guys don't know of anywhere this is already documented, do you think this list a good place to ask?  Perhaps I could add some of the answers I get to the wiki.

This is the best place to ask questions not answered by the wiki.


Sean

>> When I import a module, how does the build
>> process find my source files.
> 
> It looks in your include path, which is in dmd/bin/sc.ini as the -I portion of the DFLAGS variable.
> 
I always use the 'build' tool from http://www.dsource.org/projects/build to compile and link an executable in one step. It searches for all files and calls dmd with the right parameters.

> I always use the 'build' tool from http://www.dsource.org/projects/build to compile and link an executable in one step. It searches for all files and calls dmd with the right parameters.

Thanks for those notes Sean and Frank, and yeah, I've been using build.exe too, and with no problems. Everything is working fine and happily coding away on my little project.

I guessed a few things that I would like to know for sure though.

Heres another question. I have lots.

I have each of my classes in separate source files. the files are named the
same as the class.  Is it true that each source files is compiled to a
separate module?
That a module needs to import any other module to access its classes?
These modules are the obj files right?

Where is it getting the name of the modules from? My source files are
capitalized but from the looks of things module names need to be lowercase.
Or at least the first letter needs to be. eg. TaskArea class is save in
TaskArea.d but I need to import taskArea to access the class.  By disabling
clean I see that this is the name of the generated obj file. How come it
changes case on me? Should I stick with this naming convention for my
sources?


Also, how does the dot syntax work?

I've downloaded and using TinyXML. I've dropped the sources in a folder called TinyXML. To access this i need to import tinyxml.tinyxml not TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And it also requires lowercase?

But then what is with std.stdio? I don't see an std folder? Is this a special case?

When i import dwt.all for GUI, it seems to be compiling all of it it every time I build. Do I really need to recompile all of dwt every time i build?


I'd better stop there. I starting to sound like I don't know anything.

If you guys are kind enough to answer these questions I'll post some more about linking to libs. :)

I'll also google around and see if i can't find some good info about c's build process.

Thanks guys!

> I have each of my classes in separate source files. the files are named the same as the class.  Is it true that each source files is compiled to a separate module?

Every source file is a module. Each module (=src file) is compile to a
object file.

> That a module needs to import any other module to access its classes?

Yes.

> These modules are the obj files right?
No, its the source files.

> Where is it getting the name of the modules from?

The path the source file is located in, has to match the module-statement in the source file.

e.g.

module mypackage.mymod;
map to the file
mypackage/mymod.d

> My source files are
> capitalized but from the looks of things module names need to be lowercase.


The case is important, but you can name the modules/files like you want.

> Or at least the first letter needs to be. eg. TaskArea class is save in TaskArea.d but I need to import taskArea to access the class.  By disabling clean I see that this is the name of the generated obj file. How come it changes case on me? Should I stick with this naming convention for my sources?

You really do not need the mapping 1 module == 1 class.
You can put 3 classes into one module if you want. The module name and
the class name are independent. They can be equal, but doesn't have to.
They have different scopes.

> Also, how does the dot syntax work?

If you mymodule contains the class 'MyClass' then:
mypackage		=> qualifies the package
mypackage.mymodule	=> qualifies the module, needed to import
mypackage.mymodule.MyClass => is the full qualified name of the class
MyClass.

The dot syntax is only unique if a file mymodule.d is found in a mypackage directory. If not it could also mean a module 'MyClass' in the directory mypackage/mymodule or it can mean a inner class MyClass in the class 'mymodule' in the module 'mypackage' :)

> I've downloaded and using TinyXML. I've dropped the sources in a folder called TinyXML. To access this i need to import tinyxml.tinyxml not TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And it also requires lowercase?

If you work on windows, its possible the case sensitivity is affected
from the file system. I don't know. I work on linux.
You have to make sure, the module statements of the tinyxml modules
match the directory structure, and the root of this structure is one of
the compiler include paths (option -I). I don't know the TinyXML so I
cannot help further.

> But then what is with std.stdio? I don't see an std folder? Is this a special case?

look into the dmd/source/phobos folder. This directory is also listed in sc.ini, that is the cause, the compiler looks there.

> 
> When i import dwt.all for GUI, it seems to be compiling all of it it every time I build. Do I really need to recompile all of dwt every time i build?

compiling is made in several steps. If you import a module, it is parsed to extract all definitions. Only if you compile the whole semantic parsing is done. Well, I think that is the way it works :)

On Tue, 15 Aug 2006 21:10:47 +1000, Jay Kyburz wrote:

>> I always use the 'build' tool from http://www.dsource.org/projects/build to compile and link an executable in one step. It searches for all files and calls dmd with the right parameters.
> 
> Thanks for those notes Sean and Frank, and yeah, I've been using build.exe too, and with no problems. Everything is working fine and happily coding away on my little project.

Glad its been useful for you.

> I guessed a few things that I would like to know for sure though.
> 
> Heres another question. I have lots.
> 
> I have each of my classes in separate source files. the files are named the same as the class.  Is it true that each source files is compiled to a separate module?

Yes. A source file *is* a module. The resulting .obj file is the module in 'object' form and can be linked in with other modules to form the executable.

> That a module needs to import any other module to access its classes?

Yes.

> These modules are the obj files right?

See above.

> Where is it getting the name of the modules from?

If your source file does *not* have a module statement in it, then the module name is the same as the source file minus the '.d' suffix. Otherwise the module name is what you've declared in the module statement.

In nearly every case, the best practice is to have a module statement that is exactly the same as your source file name. It saves headaches later on.

> My source files are capitalized but from the looks of things module names need to be lowercase.

They don't absolutely need to be lowercase, but the recommended standard is to make module names (and thus file names) all lowercase.

> Or at least the first letter needs to be. eg. TaskArea class is save in TaskArea.d but I need to import taskArea to access the class.  By disabling clean I see that this is the name of the generated obj file. How come it changes case on me? Should I stick with this naming convention for my sources?

No, I suggest you use a different naming convention. I would have your class name start with a Capital letter and have your source file name all lowercase. And if you stick to one class per file, have your filename different to the class by adding a suffix or prefix. For example,

  module foo_m;
  class Foo
  {
   ...
  }

You can have multiple classes in a single file. One would typically do that if those classes needed direct access to each other's internals without having to go through member functions. Everything in a module has access to everything else in the same module (if in scope of course).

> 
> Also, how does the dot syntax work?

If the module name is "foo.bar", it implies that the source file is to be found in "foo\bar.d". Note that module names are *not* relative to the current folder or the folder of the file importing the module. They are relative to an entry in the 'Import List' of folder names. This list is defined in dmd\bin\sc.ini and can be added to by the -I switch (dmd only).

My Build utility analyzes the source files to discover what the right Import List should be and automatically adds them to the list before it compiles the souirces.

> I've downloaded and using TinyXML. I've dropped the sources in a folder called TinyXML. To access this i need to import tinyxml.tinyxml not TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And it also requires lowercase?

This is why one should stick to lowercase file names as they are portable across systems.

> But then what is with std.stdio? I don't see an std folder? Is this a special case?

No it is not special. "std.stdio" is a module found in "std\stdio.d". This is relative to an entry in the Import List. The default Import List is usually "c:\dmd\src\phobos" and can be found in sc.ini as

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


> When i import dwt.all for GUI, it seems to be compiling all of it it every time I build. Do I really need to recompile all of dwt every time i build?

Probably not, but its so fast it doesn't hurt.  Also, there are some remaining limitations with templates and -release mode that is often fixed by doing a full compile.


-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Jay Kyburz wrote:
> 
> I have each of my classes in separate source files. the files are named the same as the class.  Is it true that each source files is compiled to a separate module? 

Source files and modules are effectively the same thing.  I think you could technically have two separate files with the same module name to split up large modules, but I consider that more of a hacker trick than anything.

> That a module needs to import any other module to access its classes?

Yes.

> These modules are the obj files right? 

Yup.

> Where is it getting the name of the modules from?

If no module name is supplied then it is assumed to be the same as the file name.  And in general, it is a bad idea to use a different file name from what you want the module name to be, because import statements reference the file name, not the module name (confusing, huh?).  If you want your module to be semantically grouped with other modules, you can specify a package name as a part of the module name. ie.

    // filename should be 'mymodule.d'
    module mymodule;

    // file should be 'mypackage\subgroup\mymodule.d'
    module mypackage.subgroup.mymodule;

In the latter case, you'd add the directory the 'mypackage' directory lives in into your include path.  Importing it would be:

    import mypackage.subgroup.mymodule;

> My source files are
> capitalized but from the looks of things module names need to be lowercase. Or at least the first letter needs to be. eg. TaskArea class is save in TaskArea.d but I need to import taskArea to access the class.  By disabling clean I see that this is the name of the generated obj file. How come it changes case on me? Should I stick with this naming convention for my sources?

That's a matter of opinion.  According to the D style guide, module names should be lowercase.  But this is just a convention, and not everyone uses it.  Mango, for example, uses CamelCase module names similar to Java.  Whatever you choose, however, the capitalization of the module name, file name, and import statement should all be the same.

> Also, how does the dot syntax work?

See above.  Each dotted segment refers to a subdirectory name, with the last bit referring to a file name.  This directory chain is expected to hang off of one of the directories in your include path (whych can be set at compile time by adding a '-Ipathname' in addition to modifying sc.ini).

> I've downloaded and using TinyXML. I've dropped the sources in a folder called TinyXML. To access this i need to import tinyxml.tinyxml not TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And it also requires lowercase?

Case shouldn't matter on Windows, but as above, the capitalization used in your import statement should match the capitalization of the path name.  I'm not sure why the capitalized form isn't working, though I've never tried to capitalized the path portion of the name.

> But then what is with std.stdio? I don't see an std folder? Is this a special case?

The std folder is in dmd\src\phobos, which should be the first directory in your include path listed in dmd\bin\sc.ini.

> When i import dwt.all for GUI, it seems to be compiling all of it it every time I build. Do I really need to recompile all of dwt every time i build?

Assuming you're using Build, it should build an object file for each .d file needed for the application if the object file doesn't already exist and put that file in the same directory as the .d file it corresponds to.  You can tell Build to get rid of the object files when it's done with them (thus forcing them to be re-built each time) by adding a '-clean' switch at the command-line, but it isn't required.


Sean

Derek Parnell wrote:

> No, I suggest you use a different naming convention. I would have your
> class name start with a Capital letter and have your source file name all
> lowercase. And if you stick to one class per file, have your filename
> different to the class by adding a suffix or prefix. For example,
> 
>   module foo_m;
>   class Foo
>   {
>    ...
>   }

Can I ask you, what is your reason for naming a source file differently than the class? Does it have something to do with importing magic?

Lutger wrote:
> Derek Parnell wrote:
> 
>> No, I suggest you use a different naming convention. I would have your
>> class name start with a Capital letter and have your source file name all
>> lowercase. And if you stick to one class per file, have your filename
>> different to the class by adding a suffix or prefix. For example,
>>
>>   module foo_m;
>>   class Foo
>>   {
>>    ...
>>   }
> 
> 
> Can I ask you, what is your reason for naming a source file differently than the class? Does it have something to do with importing magic?

The name of the source file and the name of the class are completely orthogonal. They have nothing to do with each other. They may be the same or different as you wish. This is not Java: A source file can contain zero classes or as many classes as you like.

That said, it is convention to name source files and modules completely lower-case, and to start class names with a capital. However, the language does not actually enforce either of these. If nothing else, it is a /very bad/ idea to ever name the source file and the module different things, even if they just differ in capitalization.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

On Wed, 16 Aug 2006 01:39:18 +1000, Sean Kelly wrote
(in article <ebsprc$2cmn$1@digitaldaemon.com>):


Thanks again guys.. This stuff is all great.  I never expected such a good response.