Am 14.06.2011 17:20, schrieb Bernard Helyer: > We just had a discussion with Andrei on IRC. Logs follow: > > <andralex> bernardh: destroy > <andralex> so I can cry > <bernardh> This could be handled by an external tool, which would not > increase the burden on the language and implementation. > <bernardh> Because suddenly you've added networking to the compiler, > which is fine, but it better be worth it. > <bernardh> And really what you add to the language isn't worth it. > <bernardh> A pragma that says you can fetch it from that? > <bernardh> A build tool could do that. > <bernardh> No need for that to be encoded in the source. > <bernardh> andralex, tl;dr - you don't add enough semantics to justify > adding this to the compiler > <andralex> bernardh: well > <andralex> the advantage is that the barrier of entry for sharing code > and using shared code is lowered > <andralex> just paste one line and you're ready to go > <bernardh> Yeah, but most projects use a build tool. > <bernardh> So that _still_ has to be set up. > <bernardh> That's non-zero. > <bernardh> If you add the capability to that tool. > <bernardh> The increase is identical to that if you added it the compiler. > <bernardh> Besides which, URLs to libraries seems better in build scripts > than the source itself. > <bernardh> andralex, _and_ that cuts down on modifications to the > compiler (you're proposing a change to the link behaviour in that case). > <bernardh> So my point remains. > <bernardh> You add burden to the language and the implementation for no > gain. > <andralex> hm > <andralex> well I mentioned to walter that rdmd could take care of that > <andralex> he wanted it to be in dmd > <andralex> his point is this: > <andralex> say I'm John Smith and I wrote some cool D code > <andralex> how do you try it? > <andralex> well it depends on some libs > <andralex> so you need to download John's code and those libs > <andralex> put them somewhere > <andralex> then build accordingly > <andralex> this proposal cuts through all that red tape > <bernardh> You didn't respond to me at all. > <andralex> ? > <andralex> You mentioned no gain > <bernardh> The build tool could refer to scripts and then the > dependencies would be automatically set up just the same. > <andralex> I just told you where the gain is > <bernardh> ^ > <andralex> who writes the scripts? > <bernardh> Library writers. > <Suprano> ME > * wilsonkk has quit (Remote host closed the connection) > <andralex> exactly > * Joseph_ has quit (Ping timeout: 276 seconds) > <bernardh> What's your point? > <andralex> so everyone will choose their own paths, their own > conventions, their own dependency setup > <bernardh> The simplest form for John > <bernardh> No, because the conventions would be set by the tool. > <mleise> I can understand both your points of view well. This feature > fits with dmds other built-in capabilities: ddoc, profiler, code > coverage, ... . Then again it is something you expect to be done once by > built tools (like Maven) and it adds some non-determinism to the compiler. > <Nekuromento_work> I think it complicates things more than it helps > <Nekuromento_work> where dmd will fetch the code? > <Nekuromento_work> how can dmd interact with code that needs custom build > sctips > <Nekuromento_work> what happens if several of my projects use one > library? will dmd keep one copy for each? > <Nekuromento_work> what happens if I use different versions? > <Nekuromento_work> etc. > <bernardh> The end result for the user would be the same . > <bernardh> Paste url in file. > <bernardh> Use code. > <bernardh> Happy. > <Nekuromento_work> the point is, It's not compiler's responsibility > <andralex> Nekuromento_work: why not? > <andralex> I mean I don't see a strong reason why not > <bernardh> andralex, because the compiler does no other build work > <andralex> hm > <bernardh> andralex, the build tool WOULD STILL BE REQUIRED, unless DMD > does a whole lot more > <andralex> well I need to go; at best we should discuss in the newsgroup > so there's an archive > <bernardh> So adding it to the compiler would only move it. > <bernardh> Unless the DIP is improved, I for one won't implement it. > <andralex> bernardh: the problem with having a build tool is that it > requires additional files > <bernardh> Waste of time in its current form. > <andralex> config, etc. > * wilsonkk ([email protected]) has joined #d > <andralex> with this it's all included in the source > <andralex> where it belongs > <bernardh> Yes but it's STILL REQUIRED > <bernardh> You haven't removed the build tool > <bernardh> only one aspect > <andralex> right > <andralex> agreed > <bernardh> So without more support, it's a useless addition. > <bernardh> That's my opinion, in the end.
<andralex> bernardh: the problem with having a build tool is that it requires additional files One additional file. I don't think having one file would be a burden to the programmer, not much more than adding pragmas in his code. But if there's central metadata repository even this additional file isn't needed - neither are pragmas - (the build-tool will ask that repo where to find the lib/module), unless the lib is kind of obscure or brand-new and thus not known by the metadata repo. And in that case: it's just a single file. (Of course it would be possible to periodically or via "build-tool update" - like apt-get update - fetch the metadata, so the server doesn't have to be asked each time.) Cheers, - Daniel
