On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote:
1. coff/omf. Requires use of windows and visual studio/C stuff
who's locations and versions change over the years. This can be
a major headache finding the right version. Mainly because the
error messages, when using the wrong version, do not suggest
that it is a versioning error.
This isn't as severe as you make it sound. If the latest version
of VS doesn't work, the one before will. It's easy to prevent
such issues in the future. Since we never know if a new version
of VS will break things, this can be solved by one person who can
monitor the beta releases of VS and submit PRs to the appropriate
repositories if the paths change, or (as happened with VS 2015)
the C runtime library changes, or some other breakage arises.
Then DMD can get support for the new version before it's
released. Could that person be you?
2. Managing different compilers: Not too bad but if you end up
with some problems here, then it gets multiplied by the factor
of the number of issues with each compiler. if LDC has an issue
with the x64 dlls and dmd with the x32 and they are always
looking in the same place because the versions are different
and wrong, then it becomes a issue with a "factor of 4"
problem. This can become even worse when you try cross
compiling and such.
What I've done in the past is to keep the latest DMD on the
system path, then set up Command Prompt shortcuts initialized
with a different batch file to set override it with paths to
different compilers/versions. If DVM could get support for LDC
and GDC, then you'd have everything in one convenient app.
3. Re-installation can be problematic. sci.ini is overwritten.
If you hand coded the paths to get everything to work, guess
what? Well, who cares? You have plenty of time to waste, right?
Backup the sc.ini file.
4. Reinstalling one thing can break something else. This
depends on how fragile the setup was at the start.
Like what?
5. I have over 1 billion files on my system, I use it for
around 20 different non-complementary subjects(graphics, music,
programming, etc). When everything is "competing for space" and
things are not set up to work together, one seemingly unrelated
program and effect every other one. (e.g., simply by adding to
the path variable and break things with error messages that are
meaningless to the real problem)
Most ignorant people do not take those things in to account
because they oversimplify... and that usually causes problems
down the road for the rest of us.
So, what are you proposing here? Educate us. What are we supposed
to take into account? I use my computer also for graphics, music,
programming, document editing, all sorts of stuff. The only
breakage I've ever had has usually been related to anti-virus
software, though in the past there was an occasional issue with
things like SecuRom. What exactly should the D community to in
order to alleviate these major breakages you have on your system?
As D becomes increasing popular, there are going to be more
variation in the system and the flaws in it will become larger
and larger. It's best to start working on fixing those flaws
before they become too large to manage and weaken the whole
structure.
I would like to reiterate here what I mentioned earlier in this
thread -- people in the D community are currently fixing flaws
all the time. That we aren't fixing the flaws that particularly
peeve you does not mean nothing is being done. I would also like
to reiterate that if something is important enough to you, then
you could do something about it besides coming to the forums and
calling the rest of us ignorant. Write a DIP. File issues on
Bugzilla. Submit pull requests. Take on responsibility for
ensuring Visual Studio compatibility. Or do nothing, but please
don't act as if we're all just sitting here twiddling our thumbs.
