https://d.puremagic.com/issues/show_bug.cgi?id=11546

What's the story here?
Why aren't string imports written to the .deps file? Hard to tooling that
works properly without that info.

On Wednesday, 20 November 2013 at 08:35:37 UTC, Manu wrote:
> https://d.puremagic.com/issues/show_bug.cgi?id=11546
>
> What's the story here?
> Why aren't string imports written to the .deps file? Hard to tooling that
> works properly without that info.

I fixed that some time ago, see the -deps=filename switch.

On Wednesday, 20 November 2013 at 14:13:42 UTC, robert wrote:
> On Wednesday, 20 November 2013 at 08:35:37 UTC, Manu wrote:
>> https://d.puremagic.com/issues/show_bug.cgi?id=11546
>>
>> What's the story here?
>> Why aren't string imports written to the .deps file? Hard to tooling that
>> works properly without that info.
>
> I fixed that some time ago, see the -deps=filename switch.

Ooops, just the other way round: -deps without filename. Reason for stdout: There were some people concerned about adding another command line switch, so I just recyclied -deps. The output of -deps=filename wasn't changed for backwards compatibility.

Best regards,

Robert

On Wednesday, 20 November 2013 at 14:17:54 UTC, robert wrote:
> The output of -deps=filename wasn't changed for backwards compatibility.

Is this actually a real concern? There are not that much tools that use that file output and I can't imagine why they would want to keep incorrect dependency handling in presence of string imports. Doing an early warning about future change should be enough.

On 2013-11-20 15:17, robert wrote:

> The output of -deps=filename wasn't changed for backwards compatibility.

If the output wasn't there in the first place wouldn't it be possible to add new information in a backwards compatible way?

-- 
/Jacob Carlborg

20-Nov-2013 18:45, Dicebot пишет:
> On Wednesday, 20 November 2013 at 14:17:54 UTC, robert wrote:
>> The output of -deps=filename wasn't changed for backwards compatibility.
>
> Is this actually a real concern?

Indeed it's not like it's we are shipping an OS kernel update. Why not just notify/wait a bit/do the change?



-- 
Dmitry Olshansky

>
> If the output wasn't there in the first place wouldn't it be possible to add new information in a backwards compatible way?

No, the format of the file does not allow that. Whether compatibility is a concern or not was not for me to decide. I assumed it is not a good idea to break tools this abruptly. I thought it would be better to add just a new way of getting dependencies (which has an extensible format, btw.), the old one can then be deprecated and removed sometime in the future.

On 20.11.2013 22:42, Robert wrote:
>>
>> If the output wasn't there in the first place wouldn't it be possible
>> to add new information in a backwards compatible way?
>
> No, the format of the file does not allow that. Whether compatibility is
> a concern or not was not for me to decide. I assumed it is not a good
> idea to break tools this abruptly. I thought it would be better to add
> just a new way of getting dependencies (which has an extensible format,
> btw.), the old one can then be deprecated and removed sometime in the
> future.
>

I created a pull request to add string import dependencies by replacing the protection attribute with "string": https://github.com/D-Programming-Language/dmd/pull/2835

Visual D just ignores the new lines, but newer versions can support it.

I don't think the other output of -deps (without filename) is needed for make-like build tools.