On Sunday, 17 February 2013 at 11:20:55 UTC, Sönke Ludwig wrote:

> My question if we can get by without procedural build scripts is still
> open. If we could, it would give great benefits in simplicity of the
> system and its usage. This may require a change in conventions for some
> projects, but I think that can be worth it.
>
> Maybe it would be good to have some concrete examples of complex build
> scenarios to better judge what is possible and what may be problematic.



I think embedding procedural scripts are always a plus. Given that you already have JSON, I would vote for *cough* Javascript (V8 engine).

Am 22.02.2013 14:31, schrieb Moritz Maxeiner:
> On Friday, 22 February 2013 at 11:01:12 UTC, Sönke Ludwig wrote:
>>
>> Thanks! I've listed it on the github page: https://github.com/rejectedsoftware/dub#arch-linux
>>
>> BTW, the build process has been simplified now - dependencies are just DMD+libcurl and building works using "./build.sh" instead of using "vibe build".
> 
> Thanks for the news, I've updated both packages with the correct
> dependencies and bumped the release to 0.9.7.
> Btw. is there some way in Github to be notified (only) about new tags of
> a project (So I can update the AUR release package asap)?

I think there is none, just a commit feed that doesn't include tags. But once I have set up automatic builds, I could add a small script that makes a notification or simply uploads the new package file.

Am 23.02.2013 10:20, schrieb SomeDude:
> On Sunday, 17 February 2013 at 08:02:41 UTC, Sönke Ludwig wrote:
>> To me the most interesting open question is this: Do we actually gain from programmatic support for the build description, or does it suffice to have a good purely descriptive system? If the former should be true for more than 1% of the cases, that would definitely be a good argument against pure data.
> 
> Well, in the Java world, there is ant. It does the trick, but it's quite ugly.

And it also does the really strange thing to actually build up a procedural build description in a declarative (+ugly) language. That's definitely not what I have in mind - what I want is really a pure /description/ of the system, from which the build steps (or anything else) can be inferred.

This has the big advantage that you can decouple the two concepts and do generic things with all packages, even if the package maintainer didn't explicitly write supporting code (e.g. generate documentation, generate a project file, generate an installer, build as a DLL etc.).

The question is if we need procedural statements to create that package description or not. So far I haven't really seen a compelling example that we do. And staying with a declarative approach has the advantage that the language is _not_ more powerful than the thing that it is supposed to model, i.e. no information is lost.

An example where it is easy to mess up with a procedural language and not have a real package description anymore is if the user uses the scripting language to make decisions based on outside conditions (OS, architecture, installed libraries, time of day, whatever). The result is a description that is not really a description of the package anymore, but of the package+environment, which makes it unpredictable and thus impossible to safely make decisions about other environments (build servers, cross compilation, platform independent list of dependencies etc. pp.).

Am 23.02.2013 10:24, schrieb SomeDude:
> On Sunday, 17 February 2013 at 11:20:55 UTC, Sönke Ludwig wrote:
> 
>> My question if we can get by without procedural build scripts is still open. If we could, it would give great benefits in simplicity of the system and its usage. This may require a change in conventions for some projects, but I think that can be worth it.
>>
>> Maybe it would be good to have some concrete examples of complex build scenarios to better judge what is possible and what may be problematic.
> 
> 
> 
> I think embedding procedural scripts are always a plus. Given that you already have JSON, I would vote for *cough* Javascript (V8 engine).

If anything, DMDScript, of course ;)

(WRT procedural, I still think that non-procedural might actually be better in this case, see prev. reply)

On Sat, 2013-02-23 at 10:20 +0100, SomeDude wrote:
[…]
> Well, in the Java world, there is ant. It does the trick, but it's quite ugly.

Anyone in the Java world still using Ant is just so last decade ;-)

Maven attempts to be wholly declarative and succeeds in that all the hard work is done via plugins coded in Java or Groovy code.

Gradle makes no pretence as being either declarative or iterative, but
embraces both. As much of a specification is as declarative as possible,
but where imperative is needed it is available as Gradle specifications
are Groovy scripts with the Gradle internal DSL.

-- 
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 Saturday, 23 February 2013 at 10:21:59 UTC, Sönke Ludwig wrote:
> Am 23.02.2013 10:20, schrieb SomeDude:
>> On Sunday, 17 February 2013 at 08:02:41 UTC, Sönke Ludwig wrote:
>>> To me the most interesting open question is this: Do we actually gain
>>> from programmatic support for the build description, or does it suffice
>>> to have a good purely descriptive system? If the former should be true
>>> for more than 1% of the cases, that would definitely be a good argument
>>> against pure data.
>> 
>> Well, in the Java world, there is ant. It does the trick, but it's quite
>> ugly.
>
> And it also does the really strange thing to actually build up a
> procedural build description in a declarative (+ugly) language. That's
> definitely not what I have in mind - what I want is really a pure
> /description/ of the system, from which the build steps (or anything
> else) can be inferred.
>

In my experience, this ends up with an explosion of plugins or special cases to handle some tricks in the build. At the end, you ends up having some kind of programming language, but horribly designed.

I don't think both contradict themselves, as you can provide descriptive definition via several declaration with known names. You can also provide hooks or way to create plugins from withing the script definition. That were they belongs if you don't want user to download 10 bazillions plugins in addition to the build system.

On Saturday, 23 February 2013 at 11:21:06 UTC, Russel Winder wrote:
> On Sat, 2013-02-23 at 10:20 +0100, SomeDude wrote:
> […]
>> Well, in the Java world, there is ant. It does the trick, but it's quite ugly.
>
> Anyone in the Java world still using Ant is just so last decade ;-)
>
> Maven attempts to be wholly declarative and succeeds in that all the
> hard work is done via plugins coded in Java or Groovy code.
>

Comparing ant and maven is not appropriate here as maven is a build system + a package manager when ant only builds.

The plugin system of maven is notoriously hellish. This shows 2 things :
1/ That extending the build system is really required, and if not permitted from the build file themselves, by plugins to extends the descriptive capabilities of the descriptive language.
3/ That the benefice of having the build tool and the package manager working together is big as people plebiscite it even when the system is way worse on many other aspects.

On Saturday, 23 February 2013 at 11:21:06 UTC, Russel Winder wrote:
> Gradle makes no pretence as being either declarative or iterative, but
> embraces both. As much of a specification is as declarative as possible,
> but where imperative is needed it is available as Gradle specifications
> are Groovy scripts with the Gradle internal DSL.
> 

Do you have some link I can read about this ? This sounds like a very nice project !

On Friday, 22 February 2013 at 20:33:15 UTC, Jonathan M Davis wrote:
> On Friday, February 22, 2013 19:29:02 deadalnix wrote:
>> So I'm sorry if that appears completely stupid, but . . .
>> 
>> DUB sounds kind of like dumb. As Orbit sounds very nice,
>> especially since libraries are satellites of mars, so it make
>> sense to see other libs as artificial satellites :D
>> 
>> That is very poor, and have nothing to do with the actual
>> capabilities of each of them.
>
> Really? I see no problem with either, and if anything, I like dub better
> because it's shorter (it also starts with d). I don't feel particularly
> strongly either way though.
>
> - Jonathan M Davis

I sense deadalnix attempted yet again at being sarcastic/humorous, and failed at it. Again. :)

On Sat, 23 Feb 2013 11:20:50 +0000
Russel Winder <russel@winder.org.uk> wrote:

> On Sat, 2013-02-23 at 10:20 +0100, SomeDude wrote:
> […]
> > Well, in the Java world, there is ant. It does the trick, but it's quite ugly.
> 
> Anyone in the Java world still using Ant is just so last decade ;-)
> 

Anyone still using Java is just so last decade ;)