On Thursday, 27 July 2017 at 23:37:41 UTC, Jonathan M Davis wrote:
On Thursday, July 27, 2017 11:55:21 Ali Çehreli via
Digitalmars-d-learn wrote:
On 07/27/2017 11:47 AM, Adam D. Ruppe wrote:
> On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote:
>> But the issue was about missing symbols, not anything
>> "extra". If datatime.d is there but nothing is using it,
>> why should it matter?
>
> YOU were using it with an `import std.datetime;` line. With
> the file still there, it sees it referenced from your code
> and loads the file... but since it is no longer used
> upstream, the .lib doesn't contain it and thus missing
> symbol.
So, the actual problem is that given both
datetime/package.d and
datetime.d,
the import statement prefers the file. It could produce a
compilation error.
If we don't want that extra check by the compiler, it would be
better to keep datetime.d with a warning in it about the
change. The warning could say "please remove this file". :)
I think that this should obviously be a compilation error as
should any case where you've basically declared the same module
twice. And really, I don't see any reason to support extracting
the new zip on the old folder. We've never said that that would
work, and if you think it through, it really isn't all that
reasonable to expect that it would work. The list of files
changes from release to release (even if removals are rare),
and the layout of the directories could change. So long as the
sc.ini or dmd.conf does ther right thing, then that really
isn't a problem. Obviously, it's more of a pain if folks are
making manual changes, but we've never promised that the
directory structure of each release would be identical or that
copying one compiler release on top of another would work.
- Jonathan M Davis
You are not being very logical.
The zip file as N files in it. No matter what those files are, it
should be a closed system. That is, if I insert or add(not
replace) M file to the directory structure it should not break D,
period!
Why? Because NO file in the zip should be referencing any file
not in the zip unless it is designed to behave that way(e.g., an
external lib or whatever).
If an old external program is referencing a file in dmd2 that
isn't in the new zip it should err.
Why? Because suppose you have an old program that references some
old file in dmd2 dir and you upgrade dmd2 by extracting the zip.
The program MAY still work and use broke functionality that will
go undetected but be harmful.
Why? Because dmd.exe is reference a file it shouldn't and it
should know it shouldn't yet it does so anyways. It really has
nothing to do with the file being in the dir but that dmd is
being stupid because no one bothered to sanity checks because
they are too lazy/think it's irrelevant because it doesn't effect
them.
I should be able to put any extra files anywhere in the dmd2 dir
structure and it should NOT break dmd.
It's like if I put a text file in some OS directory and the OS
decides to use that file and crash the OS and not boot... it
could happen, but it shouldn't.
In fact, all of phobos should be versioned. Each module should
have a version id embedded in it. Each release all the versions
are updated before shipping.
