On 2015-02-08 01:39, Mike Parker wrote:

> But apparently this can be done now with dub.selections.json.

Yes, exactly. I just replied to someone calming updating packages automatically was a good idea. I also had to fight quite a lot to get this feature into Dub.

-- 
/Jacob Carlborg

On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:

> Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
> system using Scala programs as input.
>
> Some Scala folk got religious about Scala being the only right language
> for Scala builds, and created what has become SBT. Because of the way
> statically typed Scala works as a domain specific languages there are
> performance and expression issues that means SBT is getting a reputation
> in the very companies that should be supporting it that it is "the
> enemy".

It's kind of the same in the D community. Before Dub existed I started to work on both a package manager (Orbit) and a build tool (never officially announced). I used Ruby as the description format for package files a build scripts. Ruby is a language which allows you to create DSL's both with a declarative syntax and still support imperative code. Example:

target :foo

if System.osx
  target :foobar
end

Of course that was completely reject since it was Ruby and not D. Although, for some reason Make is acceptable in the D community. It's basically only D or a markup language that will be accepted.

-- 
/Jacob Carlborg

On Sunday, 8 February 2015 at 10:39:22 UTC, Jacob Carlborg wrote:
> On 2015-02-07 20:17, Vladimir Panteleev wrote:
>
>> I don't see how this setting is at all relevant to the problem at hand.
>
> Yes, sorry, "sourcePaths" and "importPaths" were the fields I was thinking about. Although I think "mainSourceFile" may be needed as well, otherwise dub will look for "app.d".

Neither of these will help in resolving the module path and filesystem path inconsistency, while maintaining compatibility with the git submodule approach.

On Sun, 2015-02-08 at 12:00 +0100, Jacob Carlborg via Digitalmars-d wrote:
> 
[…]
> It's kind of the same in the D community. Before Dub existed I
> started to work on both a package manager (Orbit) and a build tool
> (never officially announced). I used Ruby as the description format
> for package
> files a build scripts. Ruby is a language which allows you to create
> DSL's both with a declarative syntax and still support imperative
> code. Example:
> 
> target :foo
> 
> if System.osx
>    target :foobar
> end
> 
> Of course that was completely reject since it was Ruby and not D.


Well clearly it should be rejected, you have to s/Ruby/Python/ ;-)

I worked on Rant for a while because Rake is not up to building C and C++ systems due to lack of abstractions. As far as I can tell Rake remain the de facto standard tool in the Ruby community and absolutely nowhere else.

The demise of the Rant project and my shift to SCons as I needed a C++ and LaTeX build framework meant I dropped Ruby and moved to Python. Well there are other reasons I feel Python is better than Ruby, but whilst some are objective, many are purely subjective.

> Although, for some reason Make is acceptable in the D community.

Possibly because it pre-dates C++?

> It's basically only D or a markup language that will be accepted.

SBT has, or rather had, many things going for it, but it's problems will either get fixed or it will face a (n admittedly slow due to the energy of its adherents) slow decline into obscurity.

-- 
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 2015-02-08 at 14:59, Russel Winder via Digitalmars-d wrote:
> Well clearly it should be rejected, you have to s/Ruby/Python/ ;-)

LOL

> As far as I can tell Rake remain the de facto standard tool
> in the Ruby community and absolutely nowhere else.

That's by design. A rake gathers hay towards the person using it,
and makes the reverse, spreading, very inconvenient. :)

On 2/8/15 3:00 AM, Jacob Carlborg wrote:
> On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
>
>> Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
>> system using Scala programs as input.
>>
>> Some Scala folk got religious about Scala being the only right language
>> for Scala builds, and created what has become SBT. Because of the way
>> statically typed Scala works as a domain specific languages there are
>> performance and expression issues that means SBT is getting a reputation
>> in the very companies that should be supporting it that it is "the
>> enemy".
>
> It's kind of the same in the D community. Before Dub existed I started
> to work on both a package manager (Orbit) and a build tool (never
> officially announced). I used Ruby as the description format for package
> files a build scripts. Ruby is a language which allows you to create
> DSL's both with a declarative syntax and still support imperative code.
> Example:
>
> target :foo
>
> if System.osx
>    target :foobar
> end
>
> Of course that was completely reject since it was Ruby and not D.
> Although, for some reason Make is acceptable in the D community. It's
> basically only D or a markup language that will be accepted.

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

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.

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

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


Andrei

On 2015-02-06 12:37, Dicebot wrote:

> D is only cross-platfrom scripting language we can rely on. This is
> probably biggest problem of make (apart from bunch of legacy syntax
> crap) - any real build system needs relatively complicated build rules
> for target transformation. However we can reasonably expect working D
> compiler from anyone wanting to compile D project - which is both
> perfectly cross-platform and does not request installation of any
> additional binaries.

While this is true, in my opinion, the D syntax is not very good for a declarative DSL.

Most scripting language can be bundle with the build tool, that is linked in the executable. Ruby is my favorite because it allows to create good declarative DSL's, but I know most developers here hate it.

-- 
/Jacob Carlborg

On Sunday, 8 February 2015 at 17:59:56 UTC, Jacob Carlborg wrote:
> On 2015-02-06 12:37, Dicebot wrote:
>
>> D is only cross-platfrom scripting language we can rely on. This is
>> probably biggest problem of make (apart from bunch of legacy syntax
>> crap) - any real build system needs relatively complicated build rules
>> for target transformation. However we can reasonably expect working D
>> compiler from anyone wanting to compile D project - which is both
>> perfectly cross-platform and does not request installation of any
>> additional binaries.
>
> While this is true, in my opinion, the D syntax is not very good for a declarative DSL.
>
> Most scripting language can be bundle with the build tool, that is linked in the executable. Ruby is my favorite because it allows to create good declarative DSL's, but I know most developers here hate it.

I don't hate Ruby, I just would like that the community would
look at languages like Dylan and provide proper JIT and AOT
compilers.

Instead there is RubyMotion, which gets some heat of the
community AFAIK and focus only on iOS.

Since my TCL/Python days I am no longer into languages where JIT
or AOT isn't part of the reference platform.

--
Paulo

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

-- 
/Jacob Carlborg

On 2015-02-08 14:59, Russel Winder via Digitalmars-d wrote:

> I worked on Rant for a while because Rake is not up to building C and
> C++ systems due to lack of abstractions. As far as I can tell Rake
> remain the de facto standard tool in the Ruby community and absolutely
> nowhere else.

Since Rake will give you the full power of Ruby I assume you mean some high level helper constructs?

-- 
/Jacob Carlborg