Had another 48hr game jam this weekend...

[Dmitry Olshansky]

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