digitalmars.D - Build managers
- Rikki Cattermole (297/297) Feb 02 2015 So I'm going to through a massive spanner in the works here.
- Russel Winder via Digitalmars-d (22/43) Feb 02 2015 And I am working on the SCons tool – well not actually doing much just...
- Atila Neves (12/27) Feb 02 2015 I agree 100%. Declarative where possible (with sensible
- Atila Neves (4/314) Feb 02 2015 XML? Please, no. Anything but XML.
- wobbles (13/337) Feb 02 2015 While I've no doubt the functionality here is good, I think
- Rikki Cattermole (4/15) Feb 02 2015 Dub has a different scope, just D code. I'm not suggesting a new build
- Kagamin (4/14) Feb 04 2015 Was it the type system, which gave you troubles? Groovy is said
- Russel Winder via Digitalmars-d (20/37) Feb 04 2015 I believe there is a crucial point here, the size of the project being
- Paulo Pinto (5/17) Feb 04 2015 From my little experience with Gradle as part of Android Studio,
- Russel Winder via Digitalmars-d (19/22) Feb 04 2015 I am just about to start doing things with Android now I can use
- Paulo Pinto (9/35) Feb 04 2015 Well, it just manages to make my fan jump to airplane ready to
- Russel Winder via Digitalmars-d (16/24) Feb 04 2015 Looks like the Google folk working on their fork of IntelliJ IDEA are
- Jonathan Marler (58/59) Feb 03 2015 FWIW, here's the same data written in ASON (the first language
- CraigDillabaugh (4/63) Feb 03 2015 +1 for the fact it uses the easy to read JSON notation, but
- ketmar (3/4) Feb 02 2015 ...
- Rikki Cattermole (12/16) Feb 02 2015 There is three sets of files if I remember.
- ketmar (4/25) Feb 02 2015 sorry, i mean XML per se. it's unwriteable, unreadable and=20
- Paulo Pinto (4/34) Feb 03 2015 Completly usable in any XML aware IDE. :)
- ketmar (3/8) Feb 03 2015 i.e. unusable. ;-) it's better to use binary format then, it's unreadabl...
- Paulo Pinto (6/17) Feb 04 2015 Binary formats don't enjoy the benefits of XSLT/XQuery or ready
- Idan Arye (3/22) Feb 04 2015 XML's only redeeming feature - it's so messed up that it forced
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>
<Name>D</Name>
<Extensions>
<Extension>d</Extension>
<Extension>di</Extension>
</Extensions>
<Compilers>
<Compiler>
<Application>dmd</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>
<Type>windows</Type>
<Targets>
<Target>win32</Target>
<Target>win64</Target>
</Targets>
<CompilerLocation>C:/D/dmd2/windows/bin/</CompilerLocation>
<StandardLibrary
include="false">C:/D/dmd2/windows/lib/phobos.lib</StandardLibrary>
<BinaryExtension>.exe</BinaryExtension>
<DynamicLibraryExtension>.dll</DynamicLibraryExtension>
<StaticLibraryExtension>.lib</StaticLibraryExtension>
<Compatibility>
</Compatibility>
</Platform>
<Platform>
<Type>linux</Type>
<BinaryExtension></BinaryExtension>
<DynamicLibraryExtension>.so</DynamicLibraryExtension>
<StaticLibraryExtension>.a</StaticLibraryExtension>
<Compatibility>
<Language objectsOnly="true">c</Language>
</Compatibility>
</Platform>
</Platforms>
<Profiles>
<Profile default="true">
<Name>Release</Name>
<LinkCommand> -release</LinkCommand>
</Profile>
<Profile>
<Name>Debug</Name>
<CompileCommand> -debug -gc</CompileCommand>
<LinkCommand> -debug -gc</LinkCommand>
</Profile>
<Profile>
<Name>Unittest</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>
</Project>
</Compiler>
</Compilers>
</Language>
<Language>
<Name>C</Name>
<Extensions>
<Extension>c</Extension>
</Extensions>
<Compilers>
<Compiler>
<Application>gcc</Application>
<CompileCommand>{cmd} -c {source} -o{ObjectDir}/{source}.obj
{includesArgument}</CompileCommand>
<LinkCommand>{cmd} {objects} {libraries}
-o{OuputDir}/{name}{extension} {includes}</LinkCommand>
<IncludesArgument> -I{include}</IncludesArgument>
<StaticLibraryArgument> -lib</StaticLibraryArgument>
<DynamicLibraryArgument> -lib</DynamicLibraryArgument>
<Platforms>
<Platform>
<Type>windows</Type>
<Targets>
<Target>win32</Target>
<Target>win64</Target>
</Targets>
<CompilerLocation>C:/MinGW/bin/</CompilerLocation>
<BinaryExtension>.exe</BinaryExtension>
<DynamicLibraryExtension>.dll</DynamicLibraryExtension>
<StaticLibraryExtension>.lib</StaticLibraryExtension>
<Compatibility>
<Language objectsOnly="true">C++</Language>
</Compatibility>
</Platform>
<Platform>
<Type>linux</Type>
<BinaryExtension></BinaryExtension>
<DynamicLibraryExtension>.so</DynamicLibraryExtension>
<StaticLibraryExtension>.a</StaticLibraryExtension>
<Compatibility>
<Language objectsOnly="true">C++</Language>
<Language objectsOnly="true"
requireStandardLibrary="true">D</Language>
</Compatibility>
</Platform>
</Platforms>
<Profiles>
<Profile default="true">
<Name>Release</Name>
</Profile>
<Profile>
<Name>Debug</Name>
<CompileCommand> -ggdb</CompileCommand>
<LinkCommand> -ggdb</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>
<Include>{project_dir}/headers</Include>
</Includes>
<ProvidesModules>
</ProvidesModules>
<target>{hostPlatform}</target>
</Project>
</Compiler>
</Compilers>
</Language>
<Language>
<Name>C++</Name>
<Extensions>
<Extension>cpp</Extension>
</Extensions>
<Compilers>
<Compiler>
<Application>g++</Application>
<CompileCommand>{cmd} -c {source} -o{ObjectDir}/{source}.obj
{includesArgument}</CompileCommand>
<LinkCommand>{cmd} {objects} {libraries}
-o{OuputDir}/{name}{extension} {includes}</LinkCommand>
<IncludesArgument> -I{include}</IncludesArgument>
<StaticLibraryArgument> -lib</StaticLibraryArgument>
<DynamicLibraryArgument> -lib</DynamicLibraryArgument>
<Platforms>
<Platform>
<Type>windows</Type>
<Targets>
<Target>win32</Target>
<Target>win64</Target>
</Targets>
<CompilerLocation>C:/MinGW/bin/</CompilerLocation>
<BinaryExtension>.exe</BinaryExtension>
<DynamicLibraryExtension>.dll</DynamicLibraryExtension>
<StaticLibraryExtension>.lib</StaticLibraryExtension>
<Compatibility>
<Language>C</Language>
</Compatibility>
</Platform>
<Platform>
<Type>linux</Type>
<BinaryExtension></BinaryExtension>
<DynamicLibraryExtension>.so</DynamicLibraryExtension>
<StaticLibraryExtension>.a</StaticLibraryExtension>
<Compatibility>
<CompatibilityLanguage>C</CompatibilityLanguage>
<CompatibilityLanguage objectsOnly="true"
requireStandardLibrary="true">D</CompatibilityLanguage>
</Compatibility>
</Platform>
</Platforms>
<Profiles>
<Profile default="true">
<Name>Release</Name>
</Profile>
<Profile>
<Name>Debug</Name>
<CompileCommand> -ggdb</CompileCommand>
<LinkCommand> -ggdb</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>
<Include>{project_dir}/headers</Include>
</Includes>
<ProvidesModules>
</ProvidesModules>
<Target>{hostPlatform}</Target>
<Repositories>
<Repository>
<Name>Main Repository</Name>
<BaseURL>http://example.com/repo</BaseURL>
</Repository>
<Repository>
<Name>Local repository</Name>
<Directory>{bspDataDir}/repo</Directory>
</Repository>
</Repositories>
</Project>
</Compiler>
</Compilers>
</Language>
</Languages>
If targets is not specified for a platform of a compiler then check
against it's type.
The type insignifies the binary of the compiler is in. Not the output it
produces.
The output of a compiler is the type.
The type should match one of these:
windows
linux
osx
freeBSD
solaris
posix
Targets are made up of the platform and a more specific information.
win32
win64
<Project>
<Name>ABC project</Name>
<Version>x.y.z</Version>
<Description>An amazing project!</Description>
<Profile>Release</Profile>
<ProvidesModules>
<Module>project.abc.test</Module>
</ProvidesModules>
<Developers>
<Developer>Person here person company.com</Developer>
</Developers>
<VCS>https://example.com/repo/abc.git</VCS>
<URL>http://example.com/project/abc</URL>
<Dependencies>
<Dependency>
<Name>DEF project</Name>
<Version>i.j.k</Version>
<Module>project.def.test</Module>
<Directory>{ProjectDir}/../DEF</Directory>
</Dependency>
</Dependencies>
</Project>
Configuration 'flattening' occurs in these steps
1. Load all files and keep output seperate
2. Create list of all languages which have unique names
3. Add to list of languages a new version of each language that has
conflicts
If append is available append to previous value for property otherwise
overide.
Prefer the later files not the first ones.
4. For each project in languages create a new one and use it as the base
then overlay the projects configuration.
5. For each project created in last step gather the application, compile
command, link command, includes, dynamic library and static library
arguments.
6. Create base command to be executed for each project for storage.
Make sure 1-4 can be made into a cached file. (Preferably a mmfile).
Folder structure
~/.bsp/languages.xml
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/project.xml
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/languages.xml
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/src
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/bin/win32/bin.dll
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/bin/win32/bin.lib
project_dir/project.xml
project_dir/languages.xml
project_dir/project_cached.xml
e.g. project_dir/bin/win32/bin.dll
e.g. project_dir/src
e.g. project_dir/obj/win32/bin.obj
e.g. project_dir/obj/win32/dependencies/m.o.d.u.l.e/bin.lib
e.g. project_dir/resources
Feb 02 2015
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.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
Feb 02 2015
"Atila Neves" <atila.neves gmail.com> 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. AtilaSCons 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
Feb 02 2015
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>
<Name>D</Name>
<Extensions>
<Extension>d</Extension>
<Extension>di</Extension>
</Extensions>
<Compilers>
<Compiler>
<Application>dmd</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>
<Type>windows</Type>
<Targets>
<Target>win32</Target>
<Target>win64</Target>
</Targets>
<CompilerLocation>C:/D/dmd2/windows/bin/</CompilerLocation>
<StandardLibrary
include="false">C:/D/dmd2/windows/lib/phobos.lib</StandardLibrary>
<BinaryExtension>.exe</BinaryExtension>
<DynamicLibraryExtension>.dll</DynamicLibraryExtension>
<StaticLibraryExtension>.lib</StaticLibraryExtension>
<Compatibility>
</Compatibility>
</Platform>
<Platform>
<Type>linux</Type>
<BinaryExtension></BinaryExtension>
<DynamicLibraryExtension>.so</DynamicLibraryExtension>
<StaticLibraryExtension>.a</StaticLibraryExtension>
<Compatibility>
<Language objectsOnly="true">c</Language>
</Compatibility>
</Platform>
</Platforms>
<Profiles>
<Profile default="true">
<Name>Release</Name>
<LinkCommand> -release</LinkCommand>
</Profile>
<Profile>
<Name>Debug</Name>
<CompileCommand> -debug -gc</CompileCommand>
<LinkCommand> -debug -gc</LinkCommand>
</Profile>
<Profile>
<Name>Unittest</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>
</Project>
</Compiler>
</Compilers>
</Language>
<Language>
<Name>C</Name>
<Extensions>
<Extension>c</Extension>
</Extensions>
<Compilers>
<Compiler>
<Application>gcc</Application>
<CompileCommand>{cmd} -c {source}
-o{ObjectDir}/{source}.obj {includesArgument}</CompileCommand>
<LinkCommand>{cmd} {objects} {libraries}
-o{OuputDir}/{name}{extension} {includes}</LinkCommand>
<IncludesArgument> -I{include}</IncludesArgument>
<StaticLibraryArgument> -lib</StaticLibraryArgument>
<DynamicLibraryArgument> -lib</DynamicLibraryArgument>
<Platforms>
<Platform>
<Type>windows</Type>
<Targets>
<Target>win32</Target>
<Target>win64</Target>
</Targets>
<CompilerLocation>C:/MinGW/bin/</CompilerLocation>
<BinaryExtension>.exe</BinaryExtension>
<DynamicLibraryExtension>.dll</DynamicLibraryExtension>
<StaticLibraryExtension>.lib</StaticLibraryExtension>
<Compatibility>
<Language objectsOnly="true">C++</Language>
</Compatibility>
</Platform>
<Platform>
<Type>linux</Type>
<BinaryExtension></BinaryExtension>
<DynamicLibraryExtension>.so</DynamicLibraryExtension>
<StaticLibraryExtension>.a</StaticLibraryExtension>
<Compatibility>
<Language objectsOnly="true">C++</Language>
<Language objectsOnly="true"
requireStandardLibrary="true">D</Language>
</Compatibility>
</Platform>
</Platforms>
<Profiles>
<Profile default="true">
<Name>Release</Name>
</Profile>
<Profile>
<Name>Debug</Name>
<CompileCommand> -ggdb</CompileCommand>
<LinkCommand> -ggdb</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>
<Include>{project_dir}/headers</Include>
</Includes>
<ProvidesModules>
</ProvidesModules>
<target>{hostPlatform}</target>
</Project>
</Compiler>
</Compilers>
</Language>
<Language>
<Name>C++</Name>
<Extensions>
<Extension>cpp</Extension>
</Extensions>
<Compilers>
<Compiler>
<Application>g++</Application>
<CompileCommand>{cmd} -c {source}
-o{ObjectDir}/{source}.obj {includesArgument}</CompileCommand>
<LinkCommand>{cmd} {objects} {libraries}
-o{OuputDir}/{name}{extension} {includes}</LinkCommand>
<IncludesArgument> -I{include}</IncludesArgument>
<StaticLibraryArgument> -lib</StaticLibraryArgument>
<DynamicLibraryArgument> -lib</DynamicLibraryArgument>
<Platforms>
<Platform>
<Type>windows</Type>
<Targets>
<Target>win32</Target>
<Target>win64</Target>
</Targets>
<CompilerLocation>C:/MinGW/bin/</CompilerLocation>
<BinaryExtension>.exe</BinaryExtension>
<DynamicLibraryExtension>.dll</DynamicLibraryExtension>
<StaticLibraryExtension>.lib</StaticLibraryExtension>
<Compatibility>
<Language>C</Language>
</Compatibility>
</Platform>
<Platform>
<Type>linux</Type>
<BinaryExtension></BinaryExtension>
<DynamicLibraryExtension>.so</DynamicLibraryExtension>
<StaticLibraryExtension>.a</StaticLibraryExtension>
<Compatibility>
<CompatibilityLanguage>C</CompatibilityLanguage>
<CompatibilityLanguage objectsOnly="true"
requireStandardLibrary="true">D</CompatibilityLanguage>
</Compatibility>
</Platform>
</Platforms>
<Profiles>
<Profile default="true">
<Name>Release</Name>
</Profile>
<Profile>
<Name>Debug</Name>
<CompileCommand> -ggdb</CompileCommand>
<LinkCommand> -ggdb</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>
<Include>{project_dir}/headers</Include>
</Includes>
<ProvidesModules>
</ProvidesModules>
<Target>{hostPlatform}</Target>
<Repositories>
<Repository>
<Name>Main Repository</Name>
<BaseURL>http://example.com/repo</BaseURL>
</Repository>
<Repository>
<Name>Local repository</Name>
<Directory>{bspDataDir}/repo</Directory>
</Repository>
</Repositories>
</Project>
</Compiler>
</Compilers>
</Language>
</Languages>
If targets is not specified for a platform of a compiler then
check
against it's type.
The type insignifies the binary of the compiler is in. Not the
output it produces.
The output of a compiler is the type.
The type should match one of these:
windows
linux
osx
freeBSD
solaris
posix
Targets are made up of the platform and a more specific
information.
win32
win64
<Project>
<Name>ABC project</Name>
<Version>x.y.z</Version>
<Description>An amazing project!</Description>
<Profile>Release</Profile>
<ProvidesModules>
<Module>project.abc.test</Module>
</ProvidesModules>
<Developers>
<Developer>Person here person company.com</Developer>
</Developers>
<VCS>https://example.com/repo/abc.git</VCS>
<URL>http://example.com/project/abc</URL>
<Dependencies>
<Dependency>
<Name>DEF project</Name>
<Version>i.j.k</Version>
<Module>project.def.test</Module>
<Directory>{ProjectDir}/../DEF</Directory>
</Dependency>
</Dependencies>
</Project>
Configuration 'flattening' occurs in these steps
1. Load all files and keep output seperate
2. Create list of all languages which have unique names
3. Add to list of languages a new version of each language that
has conflicts
If append is available append to previous value for property
otherwise overide.
Prefer the later files not the first ones.
4. For each project in languages create a new one and use it as
the base then overlay the projects configuration.
5. For each project created in last step gather the
application, compile command, link command, includes, dynamic
library and static library arguments.
6. Create base command to be executed for each project for
storage.
Make sure 1-4 can be made into a cached file. (Preferably a
mmfile).
Folder structure
~/.bsp/languages.xml
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/project.xml
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/languages.xml
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/src
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/bin/win32/bin.dll
e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/bin/win32/bin.lib
project_dir/project.xml
project_dir/languages.xml
project_dir/project_cached.xml
e.g. project_dir/bin/win32/bin.dll
e.g. project_dir/src
e.g. project_dir/obj/win32/bin.obj
e.g. project_dir/obj/win32/dependencies/m.o.d.u.l.e/bin.lib
e.g. project_dir/resources
Feb 02 2015
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> <Name>D</Name> <Extensions> <Extension>d</Extension> <Extension>di</Extension> </Extensions> <Compilers> <Compiler> <Application>dmd</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> <Type>windows</Type> <Targets> <Target>win32</Target> <Target>win64</Target> </Targets> <CompilerLocation>C:/D/dmd2/windows/bin/</CompilerLocation> <StandardLibrary include="false">C:/D/dmd2/windows/lib/phobos.lib</StandardLibrary> <BinaryExtension>.exe</BinaryExtension> <DynamicLibraryExtension>.dll</DynamicLibraryExtension> <StaticLibraryExtension>.lib</StaticLibraryExtension> <Compatibility> </Compatibility> </Platform> <Platform> <Type>linux</Type> <BinaryExtension></BinaryExtension> <DynamicLibraryExtension>.so</DynamicLibraryExtension> <StaticLibraryExtension>.a</StaticLibraryExtension> <Compatibility> <Language objectsOnly="true">c</Language> </Compatibility> </Platform> </Platforms> <Profiles> <Profile default="true"> <Name>Release</Name> <LinkCommand> -release</LinkCommand> </Profile> <Profile> <Name>Debug</Name> <CompileCommand> -debug -gc</CompileCommand> <LinkCommand> -debug -gc</LinkCommand> </Profile> <Profile> <Name>Unittest</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> </Project> </Compiler> </Compilers> </Language> <Language> <Name>C</Name> <Extensions> <Extension>c</Extension> </Extensions> <Compilers> <Compiler> <Application>gcc</Application> <CompileCommand>{cmd} -c {source} -o{ObjectDir}/{source}.obj {includesArgument}</CompileCommand> <LinkCommand>{cmd} {objects} {libraries} -o{OuputDir}/{name}{extension} {includes}</LinkCommand> <IncludesArgument> -I{include}</IncludesArgument> <StaticLibraryArgument> -lib</StaticLibraryArgument> <DynamicLibraryArgument> -lib</DynamicLibraryArgument> <Platforms> <Platform> <Type>windows</Type> <Targets> <Target>win32</Target> <Target>win64</Target> </Targets> <CompilerLocation>C:/MinGW/bin/</CompilerLocation> <BinaryExtension>.exe</BinaryExtension> <DynamicLibraryExtension>.dll</DynamicLibraryExtension> <StaticLibraryExtension>.lib</StaticLibraryExtension> <Compatibility> <Language objectsOnly="true">C++</Language> </Compatibility> </Platform> <Platform> <Type>linux</Type> <BinaryExtension></BinaryExtension> <DynamicLibraryExtension>.so</DynamicLibraryExtension> <StaticLibraryExtension>.a</StaticLibraryExtension> <Compatibility> <Language objectsOnly="true">C++</Language> <Language objectsOnly="true" requireStandardLibrary="true">D</Language> </Compatibility> </Platform> </Platforms> <Profiles> <Profile default="true"> <Name>Release</Name> </Profile> <Profile> <Name>Debug</Name> <CompileCommand> -ggdb</CompileCommand> <LinkCommand> -ggdb</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> <Include>{project_dir}/headers</Include> </Includes> <ProvidesModules> </ProvidesModules> <target>{hostPlatform}</target> </Project> </Compiler> </Compilers> </Language> <Language> <Name>C++</Name> <Extensions> <Extension>cpp</Extension> </Extensions> <Compilers> <Compiler> <Application>g++</Application> <CompileCommand>{cmd} -c {source} -o{ObjectDir}/{source}.obj {includesArgument}</CompileCommand> <LinkCommand>{cmd} {objects} {libraries} -o{OuputDir}/{name}{extension} {includes}</LinkCommand> <IncludesArgument> -I{include}</IncludesArgument> <StaticLibraryArgument> -lib</StaticLibraryArgument> <DynamicLibraryArgument> -lib</DynamicLibraryArgument> <Platforms> <Platform> <Type>windows</Type> <Targets> <Target>win32</Target> <Target>win64</Target> </Targets> <CompilerLocation>C:/MinGW/bin/</CompilerLocation> <BinaryExtension>.exe</BinaryExtension> <DynamicLibraryExtension>.dll</DynamicLibraryExtension> <StaticLibraryExtension>.lib</StaticLibraryExtension> <Compatibility> <Language>C</Language> </Compatibility> </Platform> <Platform> <Type>linux</Type> <BinaryExtension></BinaryExtension> <DynamicLibraryExtension>.so</DynamicLibraryExtension> <StaticLibraryExtension>.a</StaticLibraryExtension> <Compatibility> <CompatibilityLanguage>C</CompatibilityLanguage> <CompatibilityLanguage objectsOnly="true" requireStandardLibrary="true">D</CompatibilityLanguage> </Compatibility> </Platform> </Platforms> <Profiles> <Profile default="true"> <Name>Release</Name> </Profile> <Profile> <Name>Debug</Name> <CompileCommand> -ggdb</CompileCommand> <LinkCommand> -ggdb</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> <Include>{project_dir}/headers</Include> </Includes> <ProvidesModules> </ProvidesModules> <Target>{hostPlatform}</Target> <Repositories> <Repository> <Name>Main Repository</Name> <BaseURL>http://example.com/repo</BaseURL> </Repository> <Repository> <Name>Local repository</Name> <Directory>{bspDataDir}/repo</Directory> </Repository> </Repositories> </Project> </Compiler> </Compilers> </Language> </Languages> If targets is not specified for a platform of a compiler then check against it's type. The type insignifies the binary of the compiler is in. Not the output it produces. The output of a compiler is the type. The type should match one of these: windows linux osx freeBSD solaris posix Targets are made up of the platform and a more specific information. win32 win64 <Project> <Name>ABC project</Name> <Version>x.y.z</Version> <Description>An amazing project!</Description> <Profile>Release</Profile> <ProvidesModules> <Module>project.abc.test</Module> </ProvidesModules> <Developers> <Developer>Person here person company.com</Developer> </Developers> <VCS>https://example.com/repo/abc.git</VCS> <URL>http://example.com/project/abc</URL> <Dependencies> <Dependency> <Name>DEF project</Name> <Version>i.j.k</Version> <Module>project.def.test</Module> <Directory>{ProjectDir}/../DEF</Directory> </Dependency> </Dependencies> </Project> Configuration 'flattening' occurs in these steps 1. Load all files and keep output seperate 2. Create list of all languages which have unique names 3. Add to list of languages a new version of each language that has conflicts If append is available append to previous value for property otherwise overide. Prefer the later files not the first ones. 4. For each project in languages create a new one and use it as the base then overlay the projects configuration. 5. For each project created in last step gather the application, compile command, link command, includes, dynamic library and static library arguments. 6. Create base command to be executed for each project for storage. Make sure 1-4 can be made into a cached file. (Preferably a mmfile). Folder structure ~/.bsp/languages.xml e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/project.xml e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/languages.xml e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/src e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/bin/win32/bin.dll e.g. ~/.bsp/repo/m.o.d.u.l.e/v.e.r.s.i.o.n/bin/win32/bin.lib project_dir/project.xml project_dir/languages.xml project_dir/project_cached.xml e.g. project_dir/bin/win32/bin.dll e.g. project_dir/src e.g. project_dir/obj/win32/bin.obj e.g. project_dir/obj/win32/dependencies/m.o.d.u.l.e/bin.lib e.g. project_dir/resources
Feb 02 2015
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 ;)
Feb 02 2015
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.
Feb 04 2015
On Wed, 2015-02-04 at 14:17 +0000, Kagamin via Digitalmars-d wrote:On Monday, 2 February 2015 at 16:30:22 UTC, wobbles wrote: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.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_winderWhile 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.
Feb 04 2015
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
Feb 04 2015
On Wed, 2015-02-04 at 14:20 +0000, 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.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
Feb 04 2015
On Wednesday, 4 February 2015 at 18:49:25 UTC, Russel Winder wrote:On Wed, 2015-02-04 at 14:20 +0000, 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 -- Paulo[…] 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.
Feb 04 2015
On Wed, 2015-02-04 at 19:26 +0000, 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/roadmapLooks 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.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
Feb 04 2015
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}" } } }
Feb 03 2015
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:+1 for the fact it uses the easy to read JSON notation, but allows comments!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}" } } }
Feb 03 2015
On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote:<Languages>... i can't even read that linenoise.=
Feb 02 2015
On 3/02/2015 5:35 a.m., ketmar wrote:On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote: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.<Languages>... i can't even read that linenoise.
Feb 02 2015
On Tue, 03 Feb 2015 05:56:51 +1300, Rikki Cattermole wrote:On 3/02/2015 5:35 a.m., ketmar wrote:sorry, i mean XML per se. it's unwriteable, unreadable and=20 unmaintainable. i just can't see the actual contents behind all that tag=20 noise.=On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote:=20 There is three sets of files if I remember. First system level. Second user level. Lastly, project level. =20 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. =20 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.<Languages>... i can't even read that linenoise.
Feb 02 2015
On Monday, 2 February 2015 at 21:48:03 UTC, ketmar wrote:On Tue, 03 Feb 2015 05:56:51 +1300, Rikki Cattermole wrote:Completly usable in any XML aware IDE. :) -- PauloOn 3/02/2015 5:35 a.m., ketmar 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.On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote: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.<Languages>... i can't even read that linenoise.
Feb 03 2015
On Tue, 03 Feb 2015 21:08:05 +0000, Paulo Pinto wrote:i.e. unusable. ;-) it's better to use binary format then, it's unreadable=20 by humans to, but takes less space and easier to process by machine.=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.=20 Completly usable in any XML aware IDE. :)
Feb 03 2015
On Wednesday, 4 February 2015 at 05:25:57 UTC, ketmar wrote:On Tue, 03 Feb 2015 21:08:05 +0000, Paulo Pinto wrote:Binary formats don't enjoy the benefits of XSLT/XQuery or ready made parsers. But I am a spoiled IDE user anyway, blame Borland. :) -- Pauloi.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.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. :)
Feb 04 2015
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:XML's only redeeming feature - it's so messed up that it forced people to write XQuery.On Tue, 03 Feb 2015 21:08:05 +0000, Paulo Pinto wrote:Binary formats don't enjoy the benefits of XSLT/XQuery or ready made parsers. But I am a spoiled IDE user anyway, blame Borland. :) -- Pauloi.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.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. :)
Feb 04 2015