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

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

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

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

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?

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.

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? :)

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

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

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?