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=190
http://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.