On Sun, 2015-02-08 at 20:54 +0100, Jacob Carlborg via Digitalmars-d
wrote:
[…]
> 
> Since Rake will give you the full power of Ruby I assume you mean some high level helper constructs?

The Rake community were not really interested in supporting C and C++ builds, let alone LaTeX, with abstractions over the base infrastructure, and (I can't remember the details) there were some problems in the Rake ADG processing that meant it was hard to create good abstractions for C and C++. Rant was a Rake for processing these higher level abstractions.

Rake is basically 1977 Make without the knowledge of C, C++, Yacc, Lex, etc., where Rant was more like 2007 GNU Make.

Yes Rake can be used for C and C++ builds, but you end up having to write the abstractions, and the community (at least back then) was not interested in supporting them in the library because it wasn't Ruby oriented. Ho hummm…

It was a pity, I liked Rant, and wrote a whole LaTeX processing infrastructure. Of course, fortunately, as the Rant project was grinding to a halt I discovered SCons already had all the LaTeX stuff I had been writing.

It would have been nice if Rake had had more take up in non-Ruby areas, but it didn't and it is almost certainly too late now.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 9 February 2015 at 08:10:56 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?
>
> 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?

No, it's not. Care to read it again?

By your logic, a dub.json file or a Makefile is not code, but a .d file which contains nothing but import statements is suddenly code and you're changing your workflow to adapt to rdmd? Please.

On Monday, 9 February 2015 at 08:08:36 UTC, Dicebot wrote:
> 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? :)

Yes. As I said dozens of times already, using a source folder is currently incompatible with git submodules (unless you use add-local). Using a module list is not incompatible with anything.

On Sunday, 8 February 2015 at 20:34:19 UTC, Jacob Carlborg wrote:
> 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?

Yes, but... practically nobody uses the daemon (which is optional).
There's practically no difference in performance against a simple scan of the FS.

---
Paolo

On Sun, 2015-02-08 at 08:57 -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]

> * One more language for the maintainers to know and use.

On the other hand by replacing Make you lose two languages, so total one less language to know.

> * 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.

This applies to the entire D infrastructure (and also the C, C++, Make, Bash,..), versioning in all systems is currently a serious problem, possibly insoluble, so this would not be a new thing at all.

> * 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.

I definitely agree this is a good thing, but I have yet to see a good build system with serious traction that is purely statically typed and compiled. Maybe D could be different. Perhaps another GSoC 2015 project in here?


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

> I definitely agree this is a good thing, but I have yet to see a good
> build system with serious traction that is purely statically typed and
> compiled. Maybe D could be different. Perhaps another GSoC 2015 project
> in here?

I haven't tried Shake, but since it's in Haskell...

Atila

It looks like the core issue is that we simply have different goals in mind. When we were deciding on how the build description works back then, we basically had these:

 - The build description can be reasoned about in a generic way (not generally possible with an imperative scripting language)
 - It avoids security issues when doing so (DoS, attack surface for more sophisticated attacks), so that it can be done on a server with decent confidence and without expensive safeguards
 - It avoids dependencies on the host environment, so that reasoning about the build description can be done independently of the target platform/environment
 - Should work seamlessly for 99% of the projects, but allows to invoke external tools to handle the rest
 - Avoids any form of redundant information as far as possible (such as compiler or OS specific compiler flags)
 - Can be mapped to the typical IDE project file types, as well as to other kinds of build descriptions

The first goals are only achievable with either a declarative approach, or with a very limited imperative approach (which in the end is no more powerful than the declarative one). I also think that we can easily achieve the 99%/1% goal (if that has been reached already is difficult to tell, but with C-class language support it will most definitely be), and if we do, it's hard to justify why this approach with limited expressibility should be regarded as a failure.

I'm not sure why some people insist that it must be possible to achieve everything with one tool. Of course that is a noble goal and definitely can have its beauty, but, assuming that the 99%/1% rule holds, it may not be one that has much importance in practice (other than producing controversy). On the other hand, being able to reason about the build description without actually executing a build script on each of the interesting platforms/environments can be a big win and we'd otherwise lose some possibly important automation opportunities (mostly when talking about a public web service scale).

For me, the current solution seems to be a good trade off, ignoring the missing support for other languages for a moment. It has successfully laid the basis for a constantly growing ecosystem of pure D packages and now it's time to carefully support the more advanced use cases.

In this process, we can of course always go through the initial goals and revise them where appropriate, or evaluate any other possible approaches that can fulfill those goals. But we have to be very careful to not make the mistake and disrupt the existing ecosystem. Backwards compatibility is a must, and ideally any possible new approach should fit well with the existing system (it doesn't have to fit well with the JSON format, though, it just has to fit somehow).

One possible alternative to a full procedural build description could be the introduction of a plugin system, where each plugin is written in D and can be invoked from within the package description. I personally would like to let the selection of an approach be guided by actual use cases instead of just focusing on the maximum expressibility.

Am 07.02.2015 um 15:46 schrieb Jacob Carlborg:
> On 2015-02-05 15:11, Sönke Ludwig wrote:
>
>> There is a request to make this configurable and it's a rather trivial
>> addition. I just don't have the time to implement all feature requests
>> myself, which is basically why it is not implemented, yet.
>
> Is the reason for putting it in the home directory to be able to share
> builds between packages?
>

Exactly. It used to be stored in a ".dub" subfolder of each package before.

On 2/9/15 12:43 AM, Russel Winder via Digitalmars-d wrote:
> On Sun, 2015-02-08 at 08:57 -0800, Andrei Alexandrescu via Digitalmars-d
> wrote:
> […]
>
>> * One more language for the maintainers to know and use.
>
> On the other hand by replacing Make you lose two languages, so total one
> less language to know.

That's not elastic. By eliminating make/sh we don't automatically "forget" them making place for others :o).

>> * 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.
>
> This applies to the entire D infrastructure (and also the C, C++, Make,
> Bash,..), versioning in all systems is currently a serious problem,
> possibly insoluble, so this would not be a new thing at all.

Fewer is better. "You have a pet in the house already, so you know what it takes to keep one. Take mine too..."?

>> * 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.
>
> I definitely agree this is a good thing, but I have yet to see a good
> build system with serious traction that is purely statically typed and
> compiled. Maybe D could be different. Perhaps another GSoC 2015 project
> in here?

That would be interesting.


Andrei

On Monday, 9 February 2015 at 17:43:58 UTC, Andrei Alexandrescu wrote:
> On 2/9/15 12:43 AM, Russel Winder via Digitalmars-d wrote:
clip
>>
>> I definitely agree this is a good thing, but I have yet to see a good
>> build system with serious traction that is purely statically typed and
>> compiled. Maybe D could be different. Perhaps another GSoC 2015 project
>> in here?
>
> That would be interesting.
>
>
> Andrei

There is still time!