November 28, 2016
On Monday, 28 November 2016 at 04:15:28 UTC, Walter Bright wrote:
> Having this new switch means that users can independently adjust the file structure as they see fit on their own time schedule.

I had asked for this feature in a post on this very forum, but at this time I only faced incomprehension.

http://forum.dlang.org/thread/kelnnikayrncidcwaczy@forum.dlang.org

> After many projects spent thinking of this issue, I came to the conclusion that being able to specify, on the
> command line, the module name of the module currently being
> compiled, thus allowing to override it to be inferred to
> the basename of the file, would solve this problem.

The current module system is too rigid, and requiring the directory structure to match the module hierarchy is too much of a constraint (and yes, I'm talking about separate compilation here).

Finally! :-)

November 27, 2016
On 11/27/2016 10:45 PM, Sebastien Alaiwan wrote:
> On Monday, 28 November 2016 at 04:15:28 UTC, Walter Bright wrote:
>> Having this new switch means that users can independently adjust the file
>> structure as they see fit on their own time schedule.
>
> I had asked for this feature in a post on this very forum, but at this time I
> only faced incomprehension.
>
> http://forum.dlang.org/thread/kelnnikayrncidcwaczy@forum.dlang.org

I knew it had come up before, but didn't remember where or when. Thanks for the link.


> The current module system is too rigid, and requiring the directory structure to
> match the module hierarchy is too much of a constraint (and yes, I'm talking
> about separate compilation here).
>
> Finally! :-)

Yes, looks like you prevailed!

November 28, 2016
On 11/28/2016 06:15 AM, Walter Bright wrote:
> On 11/27/2016 6:11 PM, Dicebot wrote:
>> On 11/28/2016 01:15 AM, Walter Bright wrote:
>>> https://issues.dlang.org/show_bug.cgi?id=16798 https://github.com/dlang/dmd/pull/6286
>>
>> In this specific case "and refactoring the package/module names is undesirable for various reasons" is not truly relevant - refactoring of dmd package stucture IS much desirable on its own even if there are no other reasons to do so.
> 
> The thing is, I also want to convert the dmd back end to D, and continue using it as a back end for DMC++. Some people want to use various parts of dmd for libraries.

Still it would be nice to get your preference/approval for some of dmd package models proposed here - it will come up again anyway.

> Having this new switch means that users can independently adjust the file structure as they see fit on their own time schedule.

No objections here.



November 28, 2016
On 11/28/2016 1:43 AM, Dicebot wrote:
> Still it would be nice to get your preference/approval for some of dmd
> package models proposed here - it will come up again anyway.

I know. But I am unsure what the right arrangement is. At least this switch converts the problem from a crisis to an annoyance.

November 28, 2016
On Sunday, 27 November 2016 at 23:15:45 UTC, Walter Bright wrote:

> I came up with another solution that does not require any source code changes:
>
> https://issues.dlang.org/show_bug.cgi?id=16798
> https://github.com/dlang/dmd/pull/6286

I would prefer moving all files to a "ddmd" directory. This would make it compatible with DCD.

--
/Jacob Carlborg
November 28, 2016
On Monday, 28 November 2016 at 12:13:44 UTC, Walter Bright wrote:
> On 11/28/2016 1:43 AM, Dicebot wrote:
>> Still it would be nice to get your preference/approval for some of dmd
>> package models proposed here - it will come up again anyway.
>
> I know. But I am unsure what the right arrangement is. At least this switch converts the problem from a crisis to an annoyance.

If you want to keep using the DMD backend for DMC++, I guess you plan to have:
- The header files available somewhere, in sync with the D files
- The D code compiled as a static library

Or am I missing something ?
If it's the case, then it won't make much of a difference what D hierarchy the D modules have, will it ?
November 28, 2016
On 11/28/2016 6:01 AM, Mathias Lang wrote:
> If you want to keep using the DMD backend for DMC++, I guess you plan to have:
> - The header files available somewhere, in sync with the D files

The backend header files will eventually go away, until then, they stay in sync.

> - The D code compiled as a static library

No.

> Or am I missing something ?
> If it's the case, then it won't make much of a difference what D hierarchy the D
> modules have, will it ?

The point of the new switch is then it won't matter what the D hierarchy is and decisions about DMC++ needn't affect DMD.
November 28, 2016
On 11/28/2016 4:43 AM, Jacob Carlborg wrote:
> On Sunday, 27 November 2016 at 23:15:45 UTC, Walter Bright wrote:
>
>> I came up with another solution that does not require any source code changes:
>>
>> https://issues.dlang.org/show_bug.cgi?id=16798
>> https://github.com/dlang/dmd/pull/6286
>
> I would prefer moving all files to a "ddmd" directory. This would make it
> compatible with DCD.

Nothing about this proposal positively or negatively affects such movement. And that's the point!

1 2
Next ›   Last »