Re: Build managers
On Wed, 2015-02-04 at 14:17 +, Kagamin via Digitalmars-d wrote: On Monday, 2 February 2015 at 16:30:22 UTC, wobbles wrote: While I've no doubt the functionality here is good, I think following the Ant colony down the XML branch will ultimately be a pest that's hard to control. In my current job, we have ant scripts to install our dev builds that is 10k+ lines long! And noone knows all of it. A single line change gives me nightmares!! It started off nice and small, but grew to a monster. We're now moving towards gradle as we can control the install much better with a fully fledged programming environment. Should be much easier read too. Was it the type system, which gave you troubles? Groovy is said to be a dynamic language, which can be worse in managing 10kloc projects. I believe there is a crucial point here, the size of the project being build is actually irrelevant, it was that the Ant file was 10k LoC. I cannot conceive of a Gradle build system being 10k LoC, BUT if it were, then instead of all teh XML hacking to manage 10k LoC, you have a proper programming language Groovy. Groovy is optionally typed, so if you use it typeless all variables are Object. If you specify types then there is run type type checking. If you want compile time type checking of Groovy you use the @TypeChecked AST transform. If you want fully statically typed and compiled Groovy then use @CompileStatic. Yes you read that right Groovy is a fully typeless dynamic languages and it is also a fully compile-time typechecked and compile static language. What is not to like about this. As long as you are on a JVM of course. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Build managers
On Wed, 2015-02-04 at 19:26 +, Paulo Pinto via Digitalmars-d wrote: […] Well, it just manages to make my fan jump to airplane ready to takeoff mode. Improving Gradle performance is part of the Android Studio roadmap. http://tools.android.com/roadmap Looks like the Google folk working on their fork of IntelliJ IDEA are not as far down the Gradle integration as the JetBrains folk are with IntelliJ IDEA. Why don't they just pull the InteliJ IDEA stuff? Gradle has it's problems but it sounds as though yours are worse than they should be. I can't tell the difference in fan speed up between a Gradle related build and a Make-related one. My big problem is the faffing around delay after the build I get with Gradle that I do not get with SCons/Waf/CMake/Maven, and dare I say it, Ant. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Build managers
On Wed, 2015-02-04 at 14:20 +, Paulo Pinto via Digitalmars-d wrote: […] From my little experience with Gradle as part of Android Studio, be prepared for increased build times and CPU load vs Ant. I am just about to start doing things with Android now I can use Kotlin and Groovy to program the applications (*). I had assumed, because Android Studio is really IntelliJ IDEA, that people would use the build in project creation to make an IDEA project form the Gradle file. Any lengthy compilation of Android Studio over the old Eclipse thing should be an Eclipse vs IntelliJ IDEA thing, not a Groovy/Gradle thing. On the other hand if you use the Gradle build always then I can imagine slow start up the first time since it has to start the Gradle server. (*) I find Java 6 an appalling language. Android is getting some Java 7, but I want Java 8 and beyind, now. Kotlin and (static) Groovy provide this. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Build managers
On Wednesday, 4 February 2015 at 18:49:25 UTC, Russel Winder wrote: On Wed, 2015-02-04 at 14:20 +, Paulo Pinto via Digitalmars-d wrote: […] From my little experience with Gradle as part of Android Studio, be prepared for increased build times and CPU load vs Ant. I am just about to start doing things with Android now I can use Kotlin and Groovy to program the applications (*). I had assumed, because Android Studio is really IntelliJ IDEA, that people would use the build in project creation to make an IDEA project form the Gradle file. Any lengthy compilation of Android Studio over the old Eclipse thing should be an Eclipse vs IntelliJ IDEA thing, not a Groovy/Gradle thing. On the other hand if you use the Gradle build always then I can imagine slow start up the first time since it has to start the Gradle server. (*) I find Java 6 an appalling language. Android is getting some Java 7, but I want Java 8 and beyind, now. Kotlin and (static) Groovy provide this. Well, it just manages to make my fan jump to airplane ready to takeoff mode. Improving Gradle performance is part of the Android Studio roadmap. http://tools.android.com/roadmap -- Paulo
Re: Build managers
On Wednesday, 4 February 2015 at 05:25:57 UTC, ketmar wrote: On Tue, 03 Feb 2015 21:08:05 +, Paulo Pinto wrote: sorry, i mean XML per se. it's unwriteable, unreadable and unmaintainable. i just can't see the actual contents behind all that tag noise. Completly usable in any XML aware IDE. :) i.e. unusable. ;-) it's better to use binary format then, it's unreadable by humans to, but takes less space and easier to process by machine. Binary formats don't enjoy the benefits of XSLT/XQuery or ready made parsers. But I am a spoiled IDE user anyway, blame Borland. :) -- Paulo
Re: Build managers
On Wednesday, 4 February 2015 at 10:23:00 UTC, Paulo Pinto wrote: On Wednesday, 4 February 2015 at 05:25:57 UTC, ketmar wrote: On Tue, 03 Feb 2015 21:08:05 +, Paulo Pinto wrote: sorry, i mean XML per se. it's unwriteable, unreadable and unmaintainable. i just can't see the actual contents behind all that tag noise. Completly usable in any XML aware IDE. :) i.e. unusable. ;-) it's better to use binary format then, it's unreadable by humans to, but takes less space and easier to process by machine. Binary formats don't enjoy the benefits of XSLT/XQuery or ready made parsers. But I am a spoiled IDE user anyway, blame Borland. :) -- Paulo XML's only redeeming feature - it's so messed up that it forced people to write XQuery.
Re: Build managers
On Monday, 2 February 2015 at 16:30:22 UTC, wobbles wrote: While I've no doubt the functionality here is good, I think following the Ant colony down the XML branch will ultimately be a pest that's hard to control. In my current job, we have ant scripts to install our dev builds that is 10k+ lines long! And noone knows all of it. A single line change gives me nightmares!! It started off nice and small, but grew to a monster. We're now moving towards gradle as we can control the install much better with a fully fledged programming environment. Should be much easier read too. Was it the type system, which gave you troubles? Groovy is said to be a dynamic language, which can be worse in managing 10kloc projects.
Re: Build managers
On Monday, 2 February 2015 at 16:30:22 UTC, wobbles wrote: While I've no doubt the functionality here is good, I think following the Ant colony down the XML branch will ultimately be a pest that's hard to control. In my current job, we have ant scripts to install our dev builds that is 10k+ lines long! And noone knows all of it. A single line change gives me nightmares!! It started off nice and small, but grew to a monster. We're now moving towards gradle as we can control the install much better with a fully fledged programming environment. Should be much easier read too. Seems strange to be talking about dub as, ahem, Antique software already. Surely it's still salvageable? From my little experience with Gradle as part of Android Studio, be prepared for increased build times and CPU load vs Ant. -- Paulo
Re: Build managers
On Tue, 03 Feb 2015 21:08:05 +, Paulo Pinto wrote: sorry, i mean XML per se. it's unwriteable, unreadable and unmaintainable. i just can't see the actual contents behind all that tag noise. Completly usable in any XML aware IDE. :) i.e. unusable. ;-) it's better to use binary format then, it's unreadable by humans to, but takes less space and easier to process by machine. signature.asc Description: PGP signature
Re: Build managers
On Tuesday, 3 February 2015 at 16:29:21 UTC, Jonathan Marler
wrote:
On Monday, 2 February 2015 at 16:06:00 UTC, Atila Neves wrote:
XML? Please, no. Anything but XML.
FWIW, here's the same data written in ASON (the first language
example anyway)
https://github.com/marler8997/mored/wiki/ASON-(Application-Specific-Object-Notation)
Language {
Name D
Extensions [d di]
Compiler Application=dmd {
CompileCommand {cmd} -c {source}
-of{ObjectDir}/{source}.obj {includesArgument}
LinkCommand {cmd} {objects} {libraries}
-of{OutputDir}/{name}{extension} {includes}
IncludesArgument -I{include}
StaticLibraryArgument -lib
DynamicLibraryArgument -lib
Platform Type=windows {
Targets [win32 win64]
CompilerLocation C:/D/dmd2/windows/bin
StandardLibrary include=false
C:/D/dmd2/windows/lib/phobos.lib
BinaryExtension .exe
DynamicLibraryExtension .dll
StaticLibraryExtension .lib
Compatibility { }
}
Platform type=linux {
CompilerLocation C:/D/dmd2/windows/bin
StandardLibrary include=false
C:/D/dmd2/windows/lib/phobos.lib
BinaryExtension
DynamicLibraryExtension .so
StaticLibraryExtension .s
Compatibility {
Language objectsOnly=true c
}
}
Profile Name=Release {
LinkCommand -release
}
Profile Name=Debug {
CompileCommand -debug -gc
LinkCommand -debug -gc
}
Profile Name=Unittest {
CompileCommand -unittest -gc
LinkCommand -unittest -gc
}
Project {
SourceDir {project_dir}
OutputDir clean=true {project_dir}/bin/{target}
ObjectDir clean=true {project_dir}/obj/{target}
ResourceDir
Includes []
ProvidesModules []
target {hostPlatform}
}
}
}
+1 for the fact it uses the easy to read JSON notation, but
allows comments!
Re: Build managers
On Monday, 2 February 2015 at 16:06:00 UTC, Atila Neves wrote:
XML? Please, no. Anything but XML.
FWIW, here's the same data written in ASON (the first language
example anyway)
https://github.com/marler8997/mored/wiki/ASON-(Application-Specific-Object-Notation)
Language {
Name D
Extensions [d di]
Compiler Application=dmd {
CompileCommand {cmd} -c {source} -of{ObjectDir}/{source}.obj
{includesArgument}
LinkCommand {cmd} {objects} {libraries}
-of{OutputDir}/{name}{extension} {includes}
IncludesArgument -I{include}
StaticLibraryArgument -lib
DynamicLibraryArgument -lib
Platform Type=windows {
Targets [win32 win64]
CompilerLocation C:/D/dmd2/windows/bin
StandardLibrary include=false
C:/D/dmd2/windows/lib/phobos.lib
BinaryExtension .exe
DynamicLibraryExtension .dll
StaticLibraryExtension .lib
Compatibility { }
}
Platform type=linux {
CompilerLocation C:/D/dmd2/windows/bin
StandardLibrary include=false
C:/D/dmd2/windows/lib/phobos.lib
BinaryExtension
DynamicLibraryExtension .so
StaticLibraryExtension .s
Compatibility {
Language objectsOnly=true c
}
}
Profile Name=Release {
LinkCommand -release
}
Profile Name=Debug {
CompileCommand -debug -gc
LinkCommand -debug -gc
}
Profile Name=Unittest {
CompileCommand -unittest -gc
LinkCommand -unittest -gc
}
Project {
SourceDir {project_dir}
OutputDir clean=true {project_dir}/bin/{target}
ObjectDir clean=true {project_dir}/obj/{target}
ResourceDir
Includes []
ProvidesModules []
target {hostPlatform}
}
}
}
Re: Build managers
On Monday, 2 February 2015 at 21:48:03 UTC, ketmar wrote: On Tue, 03 Feb 2015 05:56:51 +1300, Rikki Cattermole wrote: On 3/02/2015 5:35 a.m., ketmar wrote: On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote: Languages ... i can't even read that linenoise. There is three sets of files if I remember. First system level. Second user level. Lastly, project level. They override each other. The first two shouldn't need to be modified much. Mostly at first install. The last one is on a case by case basis for flexibility. And only one must be provided. So while yes there is probably a better way, I didn't choose it at the time. So if somebody was keen to take this up, then yes, that better way should be found. sorry, i mean XML per se. it's unwriteable, unreadable and unmaintainable. i just can't see the actual contents behind all that tag noise. Completly usable in any XML aware IDE. :) -- Paulo
Re: Build managers
On Tue, 03 Feb 2015 05:56:51 +1300, Rikki Cattermole wrote: On 3/02/2015 5:35 a.m., ketmar wrote: On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote: Languages ... i can't even read that linenoise. There is three sets of files if I remember. First system level. Second user level. Lastly, project level. They override each other. The first two shouldn't need to be modified much. Mostly at first install. The last one is on a case by case basis for flexibility. And only one must be provided. So while yes there is probably a better way, I didn't choose it at the time. So if somebody was keen to take this up, then yes, that better way should be found. sorry, i mean XML per se. it's unwriteable, unreadable and unmaintainable. i just can't see the actual contents behind all that tag noise. signature.asc Description: PGP signature
Re: Build managers
On Mon, 2015-02-02 at 23:54 +1300, Rikki Cattermole via Digitalmars-d wrote: So I'm going to through a massive spanner in the works here. I want to clarify something first. I love dub and what it stands for. I don't want to change it. I think there is an undercurrent that Dub does need to evolve somewhat. Just before dub came about, I was working on a build manager as well. Except it was based heavily on Maven, but had more native usage. And I am working on the SCons tool – well not actually doing much just now as it all seems to work as those who use it, use it. We should also note that Maven is rapidly following Ant into obscurity as Gradle takes up the central role for all build to do with JVM and Android. The reason I believe this should at least be made out in the open is that we have people who want more control over their project building and dub will not provide that. Especially mixing c/c++ and D. There was a recent suggestion to split dub up into a package manager and builder. This might be a worthwhile alternative as a builder. Here was the spec that I wrote for it: […humans should never have to manually write XML…] Personally I would propose that a build specification should be as declarative as possible but no more, i.e. there is always a need for an element of programming of build. Thus a framework based on an internal DSL has to be the right choice. SCons is on Python, Gradle is on Groovy. SCons is entirely focused on mixed C, C++, Fortran and D systems. It is not perfect, it needs work – not least working on Python 3. Gradle is JVM-based, but now has C++ native code abilities. It is not beyond the bounds of possibility that a D capability could be created. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Build managers
On Monday, 2 February 2015 at 12:16:51 UTC, Russel Winder wrote: Personally I would propose that a build specification should be as declarative as possible but no more, i.e. there is always a need for an element of programming of build. Thus a framework based on an internal DSL has to be the right choice. SCons is on Python, Gradle is on Groovy. I agree 100%. Declarative where possible (with sensible defaults), full general-purpose programming language where needed. I'm not sure how to approach that using D unless I go the Groovy way: a scripting language that accepts all D code as valid code. Or just use D and have a main function in the build description file. It means more boilerplate, but I guess not that much. Atila SCons is entirely focused on mixed C, C++, Fortran and D systems. It is not perfect, it needs work – not least working on Python 3. Gradle is JVM-based, but now has C++ native code abilities. It is not beyond the bounds of possibility that a D capability could be created. I doubt the D community will embrace having to write Groovy to configure their builds, but I could be wrong. Atila
Re: Build managers
XML? Please, no. Anything but XML.
Atila
On Monday, 2 February 2015 at 10:54:16 UTC, Rikki Cattermole
wrote:
So I'm going to through a massive spanner in the works here.
I want to clarify something first. I love dub and what it
stands for. I don't want to change it.
Just before dub came about, I was working on a build manager as
well. Except it was based heavily on Maven, but had more native
usage.
The reason I believe this should at least be made out in the
open is that we have people who want more control over their
project building and dub will not provide that. Especially
mixing c/c++ and D.
There was a recent suggestion to split dub up into a package
manager and builder. This might be a worthwhile alternative as
a builder.
Here was the spec that I wrote for it:
Languages
Language
NameD/Name
Extensions
Extensiond/Extension
Extensiondi/Extension
/Extensions
Compilers
Compiler
Applicationdmd/Application
CompileCommand{cmd} -c {source}
-of{ObjectDir}/{source}.obj {includesArgument}/CompileCommand
LinkCommand{cmd} {objects} {libraries}
-of{OuputDir}/{name}{extension} {includes}/LinkCommand
IncludesArgument
-I{include}/IncludesArgument
StaticLibraryArgument
-lib/StaticLibraryArgument
DynamicLibraryArgument
-lib/DynamicLibraryArgument
Platforms
Platform
Typewindows/Type
Targets
Targetwin32/Target
Targetwin64/Target
/Targets
CompilerLocationC:/D/dmd2/windows/bin//CompilerLocation
StandardLibrary
include=falseC:/D/dmd2/windows/lib/phobos.lib/StandardLibrary
BinaryExtension.exe/BinaryExtension
DynamicLibraryExtension.dll/DynamicLibraryExtension
StaticLibraryExtension.lib/StaticLibraryExtension
Compatibility
/Compatibility
/Platform
Platform
Typelinux/Type
BinaryExtension/BinaryExtension
DynamicLibraryExtension.so/DynamicLibraryExtension
StaticLibraryExtension.a/StaticLibraryExtension
Compatibility
Language
objectsOnly=truec/Language
/Compatibility
/Platform
/Platforms
Profiles
Profile default=true
NameRelease/Name
LinkCommand
-release/LinkCommand
/Profile
Profile
NameDebug/Name
CompileCommand -debug
-gc/CompileCommand
LinkCommand -debug
-gc/LinkCommand
/Profile
Profile
NameUnittest/Name
CompileCommand -unittest
-gc/CompileCommand
LinkCommand -unittest
-gc/LinkCommand
/Profile
/Profiles
Project
SourceDir{project_dir}/src/SourceDir
OutputDir
clean=true{project_dir}/bin/{target}/OutputDir
ObjectDir
clean=true{project_dir}/obj/{target}/ObjectDir
ResourceDir{project_dir}/resources/ResourceDir
Includes
/Includes
ProvidesModules
/ProvidesModules
target{hostPlatform}/target
Re: Build managers
On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote: Languages ... i can't even read that linenoise. signature.asc Description: PGP signature
Re: Build managers
On 3/02/2015 5:35 a.m., ketmar wrote: On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote: Languages ... i can't even read that linenoise. There is three sets of files if I remember. First system level. Second user level. Lastly, project level. They override each other. The first two shouldn't need to be modified much. Mostly at first install. The last one is on a case by case basis for flexibility. And only one must be provided. So while yes there is probably a better way, I didn't choose it at the time. So if somebody was keen to take this up, then yes, that better way should be found.
Re: Build managers
On 3/02/2015 5:30 a.m., wobbles wrote: While I've no doubt the functionality here is good, I think following the Ant colony down the XML branch will ultimately be a pest that's hard to control. In my current job, we have ant scripts to install our dev builds that is 10k+ lines long! And noone knows all of it. A single line change gives me nightmares!! It started off nice and small, but grew to a monster. Yeash, I'm glad I outgrew it early on. We're now moving towards gradle as we can control the install much better with a fully fledged programming environment. Should be much easier read too. Seems strange to be talking about dub as, ahem, Antique software already. Surely it's still salvageable? Dub has a different scope, just D code. I'm not suggesting a new build tool, just an alternative part of one ;)
Re: Build managers
While I've no doubt the functionality here is good, I think
following the Ant colony down the XML branch will ultimately be a
pest that's hard to control.
In my current job, we have ant scripts to install our dev builds
that is 10k+ lines long! And noone knows all of it. A single line
change gives me nightmares!! It started off nice and small, but
grew to a monster.
We're now moving towards gradle as we can control the install
much better with a fully fledged programming environment. Should
be much easier read too.
Seems strange to be talking about dub as, ahem, Antique software
already. Surely it's still salvageable?
On Monday, 2 February 2015 at 16:06:00 UTC, Atila Neves wrote:
XML? Please, no. Anything but XML.
Atila
On Monday, 2 February 2015 at 10:54:16 UTC, Rikki Cattermole
wrote:
So I'm going to through a massive spanner in the works here.
I want to clarify something first. I love dub and what it
stands for. I don't want to change it.
Just before dub came about, I was working on a build manager
as well. Except it was based heavily on Maven, but had more
native usage.
The reason I believe this should at least be made out in the
open is that we have people who want more control over their
project building and dub will not provide that. Especially
mixing c/c++ and D.
There was a recent suggestion to split dub up into a package
manager and builder. This might be a worthwhile alternative as
a builder.
Here was the spec that I wrote for it:
Languages
Language
NameD/Name
Extensions
Extensiond/Extension
Extensiondi/Extension
/Extensions
Compilers
Compiler
Applicationdmd/Application
CompileCommand{cmd} -c {source}
-of{ObjectDir}/{source}.obj {includesArgument}/CompileCommand
LinkCommand{cmd} {objects} {libraries}
-of{OuputDir}/{name}{extension} {includes}/LinkCommand
IncludesArgument
-I{include}/IncludesArgument
StaticLibraryArgument
-lib/StaticLibraryArgument
DynamicLibraryArgument
-lib/DynamicLibraryArgument
Platforms
Platform
Typewindows/Type
Targets
Targetwin32/Target
Targetwin64/Target
/Targets
CompilerLocationC:/D/dmd2/windows/bin//CompilerLocation
StandardLibrary
include=falseC:/D/dmd2/windows/lib/phobos.lib/StandardLibrary
BinaryExtension.exe/BinaryExtension
DynamicLibraryExtension.dll/DynamicLibraryExtension
StaticLibraryExtension.lib/StaticLibraryExtension
Compatibility
/Compatibility
/Platform
Platform
Typelinux/Type
BinaryExtension/BinaryExtension
DynamicLibraryExtension.so/DynamicLibraryExtension
StaticLibraryExtension.a/StaticLibraryExtension
Compatibility
Language
objectsOnly=truec/Language
/Compatibility
/Platform
/Platforms
Profiles
Profile default=true
NameRelease/Name
LinkCommand
-release/LinkCommand
/Profile
Profile
NameDebug/Name
CompileCommand -debug
-gc/CompileCommand
LinkCommand -debug
-gc/LinkCommand
/Profile
Profile
NameUnittest/Name
CompileCommand -unittest
-gc/CompileCommand
LinkCommand -unittest
-gc/LinkCommand
