On 04/04/2024 10:55 PM, Paolo Invernizzi wrote:
> https://github.com/dlang/dmd/pull/16348
> 
> *sigh*
> 
> /P

I can certainly see it being used with shared libraries.

However there will need to be some changes or at least acknowledgement for cli args per file and support passing it via the import path switch.

On Thursday, 4 April 2024 at 10:18:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 04/04/2024 10:55 PM, Paolo Invernizzi wrote:
>> https://github.com/dlang/dmd/pull/16348
>> 
>> *sigh*
>> 
>> /P
>
> I can certainly see it being used with shared libraries.

If you mean shared code for libraries, I don't see how. Isn't dub the *official* tool to use for library? What's the problem in revamping the way dub download / organise / handle source distributions?

On 05/04/2024 12:07 AM, Paolo Invernizzi wrote:
> On Thursday, 4 April 2024 at 10:18:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 04/04/2024 10:55 PM, Paolo Invernizzi wrote:
>>> https://github.com/dlang/dmd/pull/16348
>>>
>>> *sigh*
>>>
>>> /P
>>
>> I can certainly see it being used with shared libraries.
> 
> If you mean shared code for libraries, I don't see how. Isn't dub the *official* tool to use for library? What's the problem in revamping the way dub download / organise / handle source distributions?

No I meant shared libraries.

Specifically the distribution of the source files that act as the interface to it.

That way you have the .sar file and the .dll and that's everything you need to use it.

On Thursday, 4 April 2024 at 11:10:04 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> On 05/04/2024 12:07 AM, Paolo Invernizzi wrote:
>> On Thursday, 4 April 2024 at 10:18:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> On 04/04/2024 10:55 PM, Paolo Invernizzi wrote:
>>>> https://github.com/dlang/dmd/pull/16348
>>>>
>>>> *sigh*
>>>>
>>>> /P
>>>
>>> I can certainly see it being used with shared libraries.
>> 
>> If you mean shared code for libraries, I don't see how. Isn't dub the *official* tool to use for library? What's the problem in revamping the way dub download / organise / handle source distributions?
>
> No I meant shared libraries.
>
> Specifically the distribution of the source files that act as the interface to it.
>
> That way you have the .sar file and the .dll and that's everything you need to use it.

Aren't 'di' sources the target solution for library API? What's the problem in distributing a zip or tar?

In C++ you usually have a specific "include" directory with all you need, what's the burden in doing a zip with the shared library binary and the 'di' directories?

/P

On 05/04/2024 1:27 AM, Paolo Invernizzi wrote:
> On Thursday, 4 April 2024 at 11:10:04 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>
>> On 05/04/2024 12:07 AM, Paolo Invernizzi wrote:
>>> On Thursday, 4 April 2024 at 10:18:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>>> On 04/04/2024 10:55 PM, Paolo Invernizzi wrote:
>>>>> https://github.com/dlang/dmd/pull/16348
>>>>>
>>>>> *sigh*
>>>>>
>>>>> /P
>>>>
>>>> I can certainly see it being used with shared libraries.
>>>
>>> If you mean shared code for libraries, I don't see how. Isn't dub the *official* tool to use for library? What's the problem in revamping the way dub download / organise / handle source distributions?
>>
>> No I meant shared libraries.
>>
>> Specifically the distribution of the source files that act as the interface to it.
>>
>> That way you have the .sar file and the .dll and that's everything you need to use it.
> 
> Aren't 'di' sources the target solution for library API? What's the problem in distributing a zip or tar?
> 
> In C++ you usually have a specific "include" directory with all you need, what's the burden in doing a zip with the shared library binary and the 'di' directories?
> 
> /P

You can and probably will still zip them up.

Getting the number of files down makes it a bit easier to work with when moving them around or using it.

I may like the idea of it, but not enough to be arguing for it, so my main concern is making sure Walter isn't simplifying it down to a point where we will have issues with it.

I.e. recommending the spec should be a little more complicated than what the code he has written so far (my improved spec): https://gist.github.com/rikkimax/d75bdd1cb9eb9aa7bacb532b69ed398c

On Thursday, 4 April 2024 at 12:33:58 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> On 05/04/2024 1:27 AM, Paolo Invernizzi wrote:
>> On Thursday, 4 April 2024 at 11:10:04 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> [...]
>> 
>> Aren't 'di' sources the target solution for library API? What's the problem in distributing a zip or tar?
>> 
>> In C++ you usually have a specific "include" directory with all you need, what's the burden in doing a zip with the shared library binary and the 'di' directories?
>> 
>> /P
>
> You can and probably will still zip them up.
>
> Getting the number of files down makes it a bit easier to work with when moving them around or using it.
>
> I may like the idea of it, but not enough to be arguing for it, so my main concern is making sure Walter isn't simplifying it down to a point where we will have issues with it.
>
> I.e. recommending the spec should be a little more complicated than what the code he has written so far (my improved spec): https://gist.github.com/rikkimax/d75bdd1cb9eb9aa7bacb532b69ed398c

Package manager should take care of moving files around following a given configuration, not users.

Let the package manager be cool enough to handle the specific problem that SAR files are supposed to solve.

On Thursday, 4 April 2024 at 12:27:00 UTC, Paolo Invernizzi wrote:
> On Thursday, 4 April 2024 at 11:10:04 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>
>> On 05/04/2024 12:07 AM, Paolo Invernizzi wrote:
>>> On Thursday, 4 April 2024 at 10:18:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>>> On 04/04/2024 10:55 PM, Paolo Invernizzi wrote:
>>>>> https://github.com/dlang/dmd/pull/16348
>>>>>
>>>>> *sigh*
>>>>>
>>>>> /P
>>>>
>>>> I can certainly see it being used with shared libraries.
>>> 
>>> If you mean shared code for libraries, I don't see how. Isn't dub the *official* tool to use for library? What's the problem in revamping the way dub download / organise / handle source distributions?
>>
>> No I meant shared libraries.
>>
>> Specifically the distribution of the source files that act as the interface to it.
>>
>> That way you have the .sar file and the .dll and that's everything you need to use it.
>
> Aren't 'di' sources the target solution for library API? What's the problem in distributing a zip or tar?
>
> In C++ you usually have a specific "include" directory with all you need, what's the burden in doing a zip with the shared library binary and the 'di' directories?
>
> /P

The .di feature is a big flop of D. They are nearly useless, their generation is dumb since no code analysis is done for removing useless imports. It should analyze the code and: check if the type import is used or not. Also, public imports are always kept.
There's no reason nowadays to use auto DI generation. One must either completely ignore this feature or just create their own DI files.