01-Sep-2013 06:05, Manu пишет:
The only compiler you can realistically use productively in windows is
DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the stars
aligned such that it would actually compile and find the linker+libs.
Walter: DMD needs to internally detect installations of various versions
of VisualStudio, and either 'just work', or amend sc.ini on its own. Or
the installer needs to amend sc.ini. Either way, leaving it to a user to
fiddle with an ini file just isn't acceptable. We had to google
solutions to this problem, and even then, we had trouble with the paths
we added to sc.ini; are spaces acceptable? Do they have quites around
them?...
I might also suggest that Microsoft supplied (ie, 'standard'), libraries
should be automatically detected and path entries added in there too:
C:\Program Files (x86)\Microsoft SDKs\...
C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
These are on basically every windows developers machine, and each of us
had to configure them ourselves.
Just find a way so that it isn't hardcoded (which Walter inevitably
seems to end up with).
Getting a workable environment:
Unsurprisingly, the Linux user was the only person happy work with a
makefile. Everybody else wanted a comfortable IDE solution (and the
linux user would prefer it too).
!!!!!!!!!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a massive
point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress
how absolutely important this is.
!!!!!!!!!
+1
Strangely I went from VisualD to Sublime Text and never look back
- it's far simpler (the overhead of having project/configuration etc.
per short snippet of code I need to try), and STABILITY issues are well,
need to be addressed.
I have come to the conclusion that treating IDE integration as ancillary
projects maintained by usually just one single member of the community
has absolutely failed.
I suggest:
* These should be made central D community projects.
* I think they should be hosted in the same github organisation as DMD.
Maybe. Though this move alone hardly buys anything unlike e.g. being
prominently featured on dlang.org download page that would rise the
number of users and bugs reported though (that you propose though).
*** As many contributors as possible should be encouraged to work with
them every day.
So true. But in case of say VisualD there simply not enough of folks
with right kind of expertise - that are familiar with VisualStudio SDK +
the number of arcane steps to build/integrate it AND have
time/inclination to work on it.
Ditto with other IDEs, it's a lot of upfront work to learn the
infrastructure + as anything interactive there is no easy test suite to
check your tweaks/hacks.
- Deprecate DMD makefiles. Seriously! Insist that contributors use
the IDE bindings to work on DMD.
While I understand the sentiment it is not a good idea. Makefiles are
crap but some modern build tool would do just fine (certainly not
specific per IDE project). _Having_ to use some IDE just hurts
automation and adds dependency AND rises the barrier of entry (we'd lose
all the editor + cmd line guys, and hell they are too amazing to lose).
Not only that but toolchains and core libraries are all about batch
processing and easily reproducible test runs - nothing like an
interactive app. Hence the large difference in mindset w.r.t. say
debugging, as batch tools are far more amendable to printf/assert style
of debugging (more specifically postmortem style, including analyzing
core dumps/stack traces).
Unless there is some organized effort behind "interactive D" things will
keep moving slowly.
--
Dmitry Olshansky
