## digitalmars.D.learn - Some Basic Question

Jay Kyburz <jay jaykyburz.com> writes:
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

Aug 14 2006
Sean Kelly <sean f4.ca> writes:
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

Aug 14 2006
Frank Benoit <keinfarbton nospam.xyz> writes:
 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.

to compile and link an executable in one step. It searches for all files
and calls dmd with the right parameters.

Aug 15 2006
Jay Kyburz <jay jaykyburz.com> writes:
 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

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

Thanks guys!

Aug 15 2006
Frank Benoit <keinfarbton nospam.xyz> writes:
 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?

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 :)

Aug 15 2006
Derek Parnell <derek psyc.ward> writes:
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
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
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!"

Aug 15 2006
Lutger <lutger.blijdestijn gmail.com> writes:
Derek Parnell wrote:

No, I suggest you use a different naming convention. I would have your
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?

Aug 15 2006
Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Lutger wrote:
Derek Parnell wrote:

No, I suggest you use a different naming convention. I would have your
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

Aug 15 2006
Lutger <lutger.blijdestijn gmail.com> writes:
Kirk McDonald wrote:
Lutger wrote:
Derek Parnell wrote:

No, I suggest you use a different naming convention. I would have your
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.

I've noticed that unfortunatly, it can create quite a mess. I'm coming
from C++, I don't know how Java handles it. Does it enforce it that hard?

Maybe I've misunderstood it, I thought Derek Parnell meant the following:

module foo.bar; // corresponds to foo/bar.d
class Bar // don't do this, use a different name
{
...
}
To avoid names such foo.bar.Bar, "if you stick to one class per file."
This is something different than naming source file and module different.

Aug 15 2006
Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Lutger wrote:
Kirk McDonald wrote:

Lutger wrote:

Derek Parnell wrote:

No, I suggest you use a different naming convention. I would have your
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.

I've noticed that unfortunatly, it can create quite a mess. I'm coming
from C++, I don't know how Java handles it. Does it enforce it that hard?

Java mandates that each source file contain a single class with the same
name as the file. Java is more strictly object-oriented than C++ or D,
and can't have anything outside of a class.

Maybe I've misunderstood it, I thought Derek Parnell meant the following:

module foo.bar; // corresponds to foo/bar.d
class Bar // don't do this, use a different name
{
...
}
To avoid names such foo.bar.Bar, "if you stick to one class per file."
This is something different than naming source file and module different.

Well, that's fine. I see nothing wrong with that.

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

Aug 15 2006
Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 16 Aug 2006 00:31:47 +0200, Lutger wrote:

Derek Parnell wrote:

No, I suggest you use a different naming convention. I would have your
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?

It is a personal POV of course, but I do it to avoid source code looking
like its hard to read. In other words, the references would look like ...

auto x = new  foo_m.Foo;

rather than
auto x = new Foo.Foo;

The duplication of symbols can get confusing after a while.

In Build, the class called 'Source' is contained in the module 'source.d'
and this makes a lot of code look strange. Especially when using static
members of the class.

foreach(Source s; source.Source.AllFiles) ...

But each to their own.

--
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
16/08/2006 10:18:56 AM

Aug 15 2006
Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:
On Wed, 16 Aug 2006 00:31:47 +0200, Lutger wrote:

Derek Parnell wrote:

No, I suggest you use a different naming convention. I would have your
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
{
...
}

than the class? Does it have something to do with importing magic?

It is a personal POV of course, but I do it to avoid source code looking
like its hard to read. In other words, the references would look like ...

auto x = new  foo_m.Foo;

rather than
auto x = new Foo.Foo;

The duplication of symbols can get confusing after a while.

In Build, the class called 'Source' is contained in the module 'source.d'
and this makes a lot of code look strange. Especially when using static
members of the class.

foreach(Source s; source.Source.AllFiles) ...

But each to their own.

Why do you access Source above in two different ways, in the same line?
with base name "Source" and later with FQN "source.Source"?

--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Aug 17 2006
Derek Parnell <derek psyc.ward> writes:
On Thu, 17 Aug 2006 12:04:50 +0100, Bruno Medeiros wrote:

foreach(Source s; source.Source.AllFiles) ...

Why do you access Source above in two different ways, in the same line?
with base name "Source" and later with FQN "source.Source"?

Because I mis-quoted myself. ;-)

foreach(source.Source s; source.Source.AllFiles) ...

There, is that better sir?

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

Aug 17 2006
Sean Kelly <sean f4.ca> writes:
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

Aug 15 2006
Jay Kyburz <jay jaykyburz.com> writes:
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.

Aug 15 2006