February 08, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2015-02-08 17:57, Andrei Alexandrescu wrote: > Ehm. This part sounds unnecessarily a bit political - NIH syndrome, > closemindedness of the D folks toward using anything else but D and > make, and such. I'm just sharing my experience since I've tried this before. I would not recommend using any other language than D unless it has the community's blessing. I'm just trying to save him the trouble. > I do remember one action I took "against" Ruby - replacing a 109 line > Ruby installer script with 13 lines of makefile code: > https://github.com/D-Programming-Language/installer/pull/10/files. It > would be difficult to construct an argument against that work. I specially remember you saying something along the lines that it took me two years to consider D instead of Ruby for Orbit. > Ruby and Python have all my respect as an outsider of their respective > communities: they have users who enjoy them and get work done using > them. That's always a good thing in my book. > > That said, I wouldn't feel easy appealing to Ruby or Python for D > internal work for reasons that I consider entirely practical and > non-political: > > * One more language for the maintainers to know and use. Same thing with make or shell scripts. > * One more dependency. Although scripting languages are ubiquitous > enough, I can tell from direct experience that versioning and dependent > packages can be quite a hassle. Only for building the tool. The scripting language would be built-in to the executable. > * Escaping into a high-level language seems as much "cheating" as > escaping into a low-level language. If C or C++ would be needed instead > of D for a task, it is worthwhile exploring how to make D a better > replacement for them . This has been historically a good and important > goal to pursue. Similarly I'd rather explore what it takes to expand D > into high-level territory instead of escaping into a high-level language. It's just that the syntax Ruby has, in my opinion, is better suited for a declarative DSL, i.e. call methods without parentheses, blocks/trailing delegates, top level execution of code. -- /Jacob Carlborg |
February 08, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 2015-02-03 22:02, H. S. Teoh via Digitalmars-d wrote: > Second generation build algorithms are centered around *not* scanning, > but taking advantage of modern OSes providing APIs for file change > notification. Rather than scan the whole source tree every time, it > takes the changeset as input -- either from the OS, or from some other > source of information. By leveraging OS features, we can obtain this > info on an as-needed basis instead of an O(n) scan. Does this require some kind of daemon running in the background? -- /Jacob Carlborg |
February 08, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 2015-02-04 19:07, Vladimir Panteleev wrote: > You mean via extern(C)? > > You can use pragma(lib), and the compiler will emit a linker instruction > to add the specified library. I'm not sure about the platform support, > though. No, I mean like this: module mylib.foo; void foo () {} module mylib.bar; void bar () {} $ rdmd mylib/foo.d The above command will obviously not compile "bar.d". What I mean is that it's no longer enough to pass a single file and let RDMD track the dependencies. -- /Jacob Carlborg |
February 08, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On 2015-02-05 09:56, Atila Neves wrote: > It depends on how you define "out of the box", I guess. I define it as what's included in a newly installed operating system. The biggest issue here is Windows vs Posix. -- /Jacob Carlborg |
February 09, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Sunday, 8 February 2015 at 21:02:14 UTC, Jacob Carlborg wrote:
> The above command will obviously not compile "bar.d". What I mean is that it's no longer enough to pass a single file and let RDMD track the dependencies.
OK, but the obviously trivial fix is to either import bar, or create a module that imports all other modules in the library. It's not really enough justification for switching build tools, is it?
|
February 09, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Sunday, 8 February 2015 at 19:52:26 UTC, Jacob Carlborg wrote:
> On 2015-02-08 12:06, Vladimir Panteleev wrote:
>
>> Neither of these will help in resolving the module path and filesystem
>> path inconsistency, while maintaining compatibility with the git
>> submodule approach.
>
> I'm not exactly sure what you're looking for but with these fields you can configure the source directory to be something else than "source/src".
I've explained it countless times in this thread. Sorry, I see no reason do it once again, this subthread is long enough already.
|
February 09, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On Monday, 9 February 2015 at 07:15:23 UTC, Vladimir Panteleev wrote:
> On Sunday, 8 February 2015 at 21:02:14 UTC, Jacob Carlborg wrote:
>> The above command will obviously not compile "bar.d". What I mean is that it's no longer enough to pass a single file and let RDMD track the dependencies.
>
> OK, but the obviously trivial fix is to either import bar, or create a module that imports all other modules in the library. It's not really enough justification for switching build tools, is it?
Is it really any different justification from avoiding ./source folder? :)
|
February 09, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 2015-02-09 08:15, Vladimir Panteleev wrote: > OK, but the obviously trivial fix is to either import bar, or create a > module that imports all other modules in the library. It's not really > enough justification for switching build tools, is it? I thought the whole point of this thread was that you don't like to change you're code structure/workflow, i.e. one should not adapt the code to the tool. Now you're suggesting I do that? -- /Jacob Carlborg |
February 09, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 2015-02-09 08:15, Vladimir Panteleev wrote: > OK, but the obviously trivial fix is to either import bar, or create a > module that imports all other modules in the library. It's not really > enough justification for switching build tools, is it? Setting up dependencies between modules just to satisfy a build tool doesn't sound like the right solution. In Phobos we're currently trying to minimize the dependencies between modules -- /Jacob Carlborg |
February 09, 2015 Re: Git, the D package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Monday, 9 February 2015 at 08:16:24 UTC, Jacob Carlborg wrote:
> On 2015-02-09 08:15, Vladimir Panteleev wrote:
>
>> OK, but the obviously trivial fix is to either import bar, or create a
>> module that imports all other modules in the library. It's not really
>> enough justification for switching build tools, is it?
>
> Setting up dependencies between modules just to satisfy a build tool doesn't sound like the right solution. In Phobos we're currently trying to minimize the dependencies between modules
Ugh... what does that have to do with anything? How is a meta-module which imports every other module in a library different from a Makefile or a dub.json file which explicitly lists all .d files in the project - other than have a .d extension?
|
Copyright © 1999-2021 by the D Language Foundation