Community

I've noticed that, when passed multiple files at once, DMD is generally buggy
in ways that I can't reproduce in small test cases. This includes things like
magically ignoring __gshared variables, and not being able to convert a type
to an alias to the same type, for example, not being able to convert a size_t
to a uint on 32-bit, or not being able to convert a float[] to an R where R is
a template parameter instantiated as float[].
I have two questions:
1. Has anyone experienced similar things and if so are they further along
than me at creating decent test cases?
2. I'm used to using Code::Blocks, but want to switch to Visual D because it
seems to work a lot better for the most part. However, by default it seems to
pass all project files to the compiler at once, where Code::Blocks compiles
one file at a time. This means I have to deal with DMD's bugginess when
passed mutliple files at once. Does anyone know how to make Visual D work
Code::Blocks style, i.e. compile each file to an object file and link them
afterwords?

"dsimcha" <dsimcha@yahoo.com> wrote in message
news:i9529m$2d4b$1@digitalmars.com...
> I've noticed that, when passed multiple files at once, DMD is generally
> buggy
> in ways that I can't reproduce in small test cases. This includes things
> like
> magically ignoring __gshared variables, and not being able to convert a
> type
> to an alias to the same type, for example, not being able to convert a
> size_t
> to a uint on 32-bit, or not being able to convert a float[] to an R where
> R is
> a template parameter instantiated as float[].
>
> I have two questions:
>
> 1. Has anyone experienced similar things and if so are they further along
> than me at creating decent test cases?
>
> 2. I'm used to using Code::Blocks, but want to switch to Visual D because
> it
> seems to work a lot better for the most part. However, by default it
> seems to
> pass all project files to the compiler at once, where Code::Blocks
> compiles
> one file at a time. This means I have to deal with DMD's bugginess when
> passed mutliple files at once. Does anyone know how to make Visual D work
> Code::Blocks style, i.e. compile each file to an object file and link them
> afterwords?
Don't they support setting up custom tools? I always do that and just define
my own command line calls.

dsimcha wrote:
> I've noticed that, when passed multiple files at once, DMD is generally buggy
> in ways that I can't reproduce in small test cases. This includes things like
> magically ignoring __gshared variables, and not being able to convert a type
> to an alias to the same type, for example, not being able to convert a size_t
> to a uint on 32-bit, or not being able to convert a float[] to an R where R is
> a template parameter instantiated as float[].
>
> I have two questions:
>
> 1. Has anyone experienced similar things and if so are they further along
> than me at creating decent test cases?
I haven't run into something similar lately, but what you describe
sounds like issues with forward references, maybe in combination with
circular imports. Building multiple files at once can change the point
where you enter the vicious import circle.
Could it be related to any of these?
http://d.puremagic.com/issues/show_bug.cgi?id=190http://d.puremagic.com/issues/show_bug.cgi?id=3979>
> 2. I'm used to using Code::Blocks, but want to switch to Visual D because it
> seems to work a lot better for the most part. However, by default it seems to
> pass all project files to the compiler at once, where Code::Blocks compiles
> one file at a time. This means I have to deal with DMD's bugginess when
> passed mutliple files at once. Does anyone know how to make Visual D work
> Code::Blocks style, i.e. compile each file to an object file and link them
> afterwords?
I have that option on my todo list, but didn't implement it so far
because I was not aware of any problems with compiling multiple files.
I don't know if this is really an option for a larger project, but what
you can do is select "Custom Build Tool" for all files in the "Common
Properties" setting of the project property dialog and enter your own
command line and output file. But be warned: you will not get any
automatic dependency detection.
As editing the settings for a lot of files might be very annoying, you
might want to set it for one file and then edit the project file with a
text editor to copy the settings to other files.
Rainer

dsimcha wrote:
> I've noticed that, when passed multiple files at once, DMD is generally buggy
> in ways that I can't reproduce in small test cases. This includes things like
> magically ignoring __gshared variables, and not being able to convert a type
> to an alias to the same type, for example, not being able to convert a size_t
> to a uint on 32-bit, or not being able to convert a float[] to an R where R is
> a template parameter instantiated as float[].
>
> I have two questions:
>
> 1. Has anyone experienced similar things and if so are they further along
> than me at creating decent test cases?
Phobos and Druntime are built by passing all the files to dmd at once, and it
works without problems. No attempt was made to tweak the order the files were
presented to dmd to make it work, I just aggregated them all.

== Quote from Rainer Schuetze (r.sagitario@gmx.de)'s article
> Could it be related to any of these?
> http://d.puremagic.com/issues/show_bug.cgi?id=190
> http://d.puremagic.com/issues/show_bug.cgi?id=3979
Yep, these look like at least part of the problem. Glad someone else has already
reduced them to sane test cases so I don't have to. Reducing compiler bugs that
only seem to occur in non-trivial, multi-module projects to decent test cases is a
huge PITA.
Anyhow, the project in question is a very messy codebase because it grew very
organically. It's basically a haphazard collection of research prototype
algorithms for predicting gene expression from DNA sequence, and every time I
think of a new idea, I tend to just put it wherever I can make it fit and almost
never bother with non-trivial refactoring. Therefore, there are cyclic imports
**everywhere**.
> I have that option on my todo list, but didn't implement it so far
> because I was not aware of any problems with compiling multiple files.
> I don't know if this is really an option for a larger project, but what
> you can do is select "Custom Build Tool" for all files in the "Common
> Properties" setting of the project property dialog and enter your own
> command line and output file. But be warned: you will not get any
> automatic dependency detection.
> As editing the settings for a lot of files might be very annoying, you
> might want to set it for one file and then edit the project file with a
> text editor to copy the settings to other files.
> Rainer
Since build process automation is by far the biggest reason why I use an IDE
instead of a plain old editor, I'd rather just stick with Code::Blocks for now.
Could you please bump this up the todo list, given that building multiple files
simultaneously is buggy in ways that probably aren't going to get fixed too soon?

"dsimcha" <dsimcha@yahoo.com> wrote in message
news:i957sg$2otm$1@digitalmars.com...
> == Quote from Rainer Schuetze (r.sagitario@gmx.de)'s article
>> I have that option on my todo list, but didn't implement it so far
>> because I was not aware of any problems with compiling multiple files.
>> I don't know if this is really an option for a larger project, but what
>> you can do is select "Custom Build Tool" for all files in the "Common
>> Properties" setting of the project property dialog and enter your own
>> command line and output file. But be warned: you will not get any
>> automatic dependency detection.
>> As editing the settings for a lot of files might be very annoying, you
>> might want to set it for one file and then edit the project file with a
>> text editor to copy the settings to other files.
>> Rainer
>
> Since build process automation is by far the biggest reason why I use an
> IDE
> instead of a plain old editor, I'd rather just stick with Code::Blocks for
> now.
> Could you please bump this up the todo list, given that building multiple
> files
> simultaneously is buggy in ways that probably aren't going to get fixed
> too soon?
I find that rdmd works just as well as any IDE (if not better) for
automating the build process of D programs. Particularly if you apply the
"Combined" patch here: http://d.puremagic.com/issues/show_bug.cgi?id=4930
Although it doesn't do one-at-a-time building ATM, so I guess that wouldn't
help in your case.

On Wed, 13 Oct 2010 14:15:00 -0700, Walter Bright wrote:
> dsimcha wrote:
>> I've noticed that, when passed multiple files at once, DMD is generally
>> buggy in ways that I can't reproduce in small test cases. This
>> includes things like magically ignoring __gshared variables, and not
>> being able to convert a type to an alias to the same type, for example,
>> not being able to convert a size_t to a uint on 32-bit, or not being
>> able to convert a float[] to an R where R is a template parameter
>> instantiated as float[].
>>
>> I have two questions:
>>
>> 1. Has anyone experienced similar things and if so are they further
>> along than me at creating decent test cases?
>
> Phobos and Druntime are built by passing all the files to dmd at once,
> and it works without problems. No attempt was made to tweak the order
> the files were presented to dmd to make it work, I just aggregated them
> all.
It's not quite true that it works without problems. I reported bug 3979
because I was unable to include the new std.process in Phobos without
changing the order of the files passed to DMD.
-Lars

I'm also having problems with VisualD + DMD, I made a posting in the
bugs forums about it, but unfortunately no one did answer yet:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.bugs&artnum=25536
Am 13.10.2010 21:45, schrieb dsimcha:
> I've noticed that, when passed multiple files at once, DMD is generally buggy
> in ways that I can't reproduce in small test cases. This includes things like
> magically ignoring __gshared variables, and not being able to convert a type
> to an alias to the same type, for example, not being able to convert a size_t
> to a uint on 32-bit, or not being able to convert a float[] to an R where R is
> a template parameter instantiated as float[].
>
> I have two questions:
>
> 1. Has anyone experienced similar things and if so are they further along
> than me at creating decent test cases?
>
> 2. I'm used to using Code::Blocks, but want to switch to Visual D because it
> seems to work a lot better for the most part. However, by default it seems to
> pass all project files to the compiler at once, where Code::Blocks compiles
> one file at a time. This means I have to deal with DMD's bugginess when
> passed mutliple files at once. Does anyone know how to make Visual D work
> Code::Blocks style, i.e. compile each file to an object file and link them
> afterwords?
--
Kind Regards
Benjamin Thaut

On Wednesday 13 October 2010 23:28:40 Benjamin Thaut wrote:
> I'm also having problems with VisualD + DMD, I made a posting in the
> bugs forums about it, but unfortunately no one did answer yet:
>
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group
> =digitalmars.D.bugs&artnum=25536
The bugs forum is not for posting to. The bugtracker sends information on the
creation of and changes to bug reports. You sign up for the list if you want to
see those messages. Pretty much no one is going to pay attention to anything
that you post to the bug list directly. Typically, you'd post to the D list or
the D-Learn list (D being for general stuff and Learn for questions about how the
language works and anything related to learning D).
- Jonathan M Davis

On 10/14/10 8:28 AM, Benjamin Thaut wrote:
> I'm also having problems with VisualD + DMD, I made a posting in the
> bugs forums about it, but unfortunately no one did answer yet:
Uh, afaik the digitalmars.D.bugs forum just mirrors the changes from the
puremagic D bugzilla, and thus is not quite the best place for discussions.