www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Errors compiling DSSS

reply "Daren Scot Wilson" <darenw darenscotwilson.com> writes:
I'm trying to compile DSSS from the current svn trunk.  My info 
is from http://www.dsource.org/projects/dsss   The build gets 
stuck, spewing many errors.   Note that I'm trying to build DSSS 
itself, not use DSSS to build something else. (I may be back 
later with those kinds of questions.)   I'm using 64-bit Linux 
(Ubuntu) using dmd
DMD64 D Compiler v2.056


The command to build
make -f Makefile.dmd.posix


The part of the build output around where the errors start is 
this:

g++ -g  nchoosedc.o nwhereami.o -o choosedc
./choosedc
Ignore any error from GDC or DMD in the following lines.
/usr/local/src/DSSS/src-co/trunk/rebuild/./testtango.d(3): Error: 
function testtango.A.toUtf8 does not override any function
make[1]: Leaving directory 
`/usr/local/src/DSSS/src-co/trunk/rebuild'
cp -f rebuild/defaults/dmd-posix rebuild/rebuild.conf/default
./rebuild/rebuild -full -Irebuild sss/main.d -ofdsss
hcf/path.d(88): octal literals 0100 are deprecated, use 
std.conv.octal!100 instead
rebuild/util/booltype.d(364): Error: function 
util.booltype.Bool.toString of type char[]() overrides but is not 
covariant with object.Object.toString of type string()
hcf/path.d(88): octal literals 0100 are deprecated, use 
std.conv.octal!100 instead
rebuild/util/linetoken.d(50): Error: cannot implicitly convert 
expression (",") of type string to char[]
rebuild/util/linetoken.d(50): Error: cannot implicitly convert 
expression ("//") of type string to char[]
rebuild/util/linetoken.d(50): Error: cannot implicitly convert 
expression ("\\") of type string to char[]


After all the "cannot implicitly convert" errors there are 
several like this:

hcf/path.d(88): octal literals 0100 are deprecated, use 
std.conv.octal!100 instead


svn info says:

Path: .
URL: http://svn.dsource.org/projects/dsss/trunk
Repository Root: http://svn.dsource.org/projects/dsss
Repository UUID: 2894d018-631f-0410-8ed0-857076f880b1
Revision: 945
Node Kind: directory
Schedule: normal
Last Changed Author: Gregor
Last Changed Rev: 945
Last Changed Date: 2009-04-17 10:26:11 -0700 (Fri, 17 Apr 2009)
Nov 26 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
AFAIK, dsss is very old and designed for D1.


On Tue, Nov 27, 2012 at 4:53 AM, Daren Scot Wilson <
darenw darenscotwilson.com> wrote:


 I'm trying to compile DSSS from the current svn trunk.  My info is from
 http://www.dsource.org/**projects/dsss<http://www.dsource.org/projects/dsss> 
The build gets stuck, spewing many errors.   Note that I'm trying to
 build DSSS itself, not use DSSS to build something else. (I may be back
 later with those kinds of questions.)   I'm using 64-bit Linux (Ubuntu)
 using dmd
 DMD64 D Compiler v2.056


 The command to build
 make -f Makefile.dmd.posix


 The part of the build output around where the errors start is this:

 g++ -g  nchoosedc.o nwhereami.o -o choosedc
 ./choosedc
 Ignore any error from GDC or DMD in the following lines.
 /usr/local/src/DSSS/src-co/**trunk/rebuild/./testtango.d(3)**: Error:
 function testtango.A.toUtf8 does not override any function
 make[1]: Leaving directory `/usr/local/src/DSSS/src-co/**trunk/rebuild'
 cp -f rebuild/defaults/dmd-posix rebuild/rebuild.conf/default
 ./rebuild/rebuild -full -Irebuild sss/main.d -ofdsss
 hcf/path.d(88): octal literals 0100 are deprecated, use std.conv.octal!100
 instead
 rebuild/util/booltype.d(364): Error: function util.booltype.Bool.toString
 of type char[]() overrides but is not covariant with object.Object.toString
 of type string()
 hcf/path.d(88): octal literals 0100 are deprecated, use std.conv.octal!100
 instead
 rebuild/util/linetoken.d(50): Error: cannot implicitly convert expression
 (",") of type string to char[]
 rebuild/util/linetoken.d(50): Error: cannot implicitly convert expression
 ("//") of type string to char[]
 rebuild/util/linetoken.d(50): Error: cannot implicitly convert expression
 ("\\") of type string to char[]


 After all the "cannot implicitly convert" errors there are several like
 this:

 hcf/path.d(88): octal literals 0100 are deprecated, use std.conv.octal!100
 instead


 svn info says:

 Path: .
 URL: http://svn.dsource.org/**projects/dsss/trunk<http://svn.dsource.org/projects/dsss/trunk>
 Repository Root: http://svn.dsource.org/**projects/dsss<http://svn.dsource.org/projects/dsss>
 Repository UUID: 2894d018-631f-0410-8ed0-**857076f880b1
 Revision: 945
 Node Kind: directory
 Schedule: normal
 Last Changed Author: Gregor
 Last Changed Rev: 945
 Last Changed Date: 2009-04-17 10:26:11 -0700 (Fri, 17 Apr 2009)




-- 
Bye,
Gor Gyolchanyan.
Nov 26 2012
parent reply "Daren Scot Wilson" <darenw darenscotwilson.com> writes:
On Tuesday, 27 November 2012 at 05:34:14 UTC, Gor Gyolchanyan 
wrote:

 AFAIK, dsss is very old and designed for D1.


 On Tue, Nov 27, 2012 at 4:53 AM, Daren Scot Wilson <
 darenw darenscotwilson.com> wrote:


 I'm trying to compile DSSS from the current svn trunk.  My 
 info is from
 http://www.dsource.org/**projects/dsss<http://www.dsource.org/projects/dsss>
  The build gets stuck, spewing many errors.   Note that I'm 
 trying to
 build DSSS itself, not use DSSS to build something else.





Ah.  So then, what is the currently fashionable build system in 
the D world?
Nov 26 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I'd recommend RDMD. It can compile (and run) the given module and it's
entire import tree. No build scripts are necessary.
Very convenient with pragma(lib, "...")


On Tue, Nov 27, 2012 at 9:55 AM, Daren Scot Wilson <
darenw darenscotwilson.com> wrote:


 On Tuesday, 27 November 2012 at 05:34:14 UTC, Gor Gyolchanyan wrote:


 AFAIK, dsss is very old and designed for D1.


 On Tue, Nov 27, 2012 at 4:53 AM, Daren Scot Wilson <
 darenw darenscotwilson.com> wrote:

  I'm trying to compile DSSS from the current svn trunk.  My info is from

 http://www.dsource.org/****projects/dsss<http://www.dsource.org/**projects/dsss>
 <http://www.**dsource.org/projects/dsss<http://www.dsource.org/projects/dsss>


  The build gets stuck, spewing many errors.   Note that I'm trying to
 build DSSS itself, not use DSSS to build something else.




 Ah.  So then, what is the currently fashionable build system in the D
 world?



-- 
Bye,
Gor Gyolchanyan.



 Nov 26 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 08:13, Gor Gyolchanyan wrote:

 I'd recommend RDMD. It can compile (and run) the given module and it's
 entire import tree. No build scripts are necessary.
 Very convenient with pragma(lib, "...")


RDMD is quite good for compiling executables. It won't work for 
compiling libraries. Quite often a build script is needed to avoid 
repeating the same compiler/linker flags over and over again.

-- 
/Jacob Carlborg



 Nov 26 2012



 next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


The convenience of RDMD comes from the fact, that it looks into the source
files to determine what to do. I think it would be even more convenient to
make a build tool for D, which would read special comments (much like DDOC,
but dedicated to build process) for compiler flags and other build
variables.


On Tue, Nov 27, 2012 at 11:38 AM, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-27 08:13, Gor Gyolchanyan wrote:


 I'd recommend RDMD. It can compile (and run) the given module and it's
 entire import tree. No build scripts are necessary.
 Very convenient with pragma(lib, "...")


 RDMD is quite good for compiling executables. It won't work for compiling
 libraries. Quite often a build script is needed to avoid repeating the same
 compiler/linker flags over and over again.

 --
 /Jacob Carlborg




-- 
Bye,
Gor Gyolchanyan.



 Nov 26 2012



prev sibling next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


Just like DDOC adds auxiliary information to create documentation, build
comments would add auxiliary information to create build scripts (which a
tool could just use right away without generating garbage in the form of
build script files).


On Tue, Nov 27, 2012 at 11:44 AM, Gor Gyolchanyan <
gor.f.gyolchanyan gmail.com> wrote:


 The convenience of RDMD comes from the fact, that it looks into the source
 files to determine what to do. I think it would be even more convenient to
 make a build tool for D, which would read special comments (much like DDOC,
 but dedicated to build process) for compiler flags and other build
 variables.


 On Tue, Nov 27, 2012 at 11:38 AM, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-27 08:13, Gor Gyolchanyan wrote:


 I'd recommend RDMD. It can compile (and run) the given module and it's
 entire import tree. No build scripts are necessary.
 Very convenient with pragma(lib, "...")


 RDMD is quite good for compiling executables. It won't work for compiling
 libraries. Quite often a build script is needed to avoid repeating the same
 compiler/linker flags over and over again.

 --
 /Jacob Carlborg




 --
 Bye,
 Gor Gyolchanyan.




-- 
Bye,
Gor Gyolchanyan.



 Nov 26 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 08:47, Gor Gyolchanyan wrote:

 Just like DDOC adds auxiliary information to create documentation, build
 comments would add auxiliary information to create build scripts (which
 a tool could just use right away without generating garbage in the form
 of build script files).


These special comments would just be the build script. I see no 
advantage of having any form of special comments for a build tool. The 
only advantage could be if you only have a single source file, then you 
can safe a file by combining the source file and build file.

Besides from this, it would be just like any other build script. If you 
put the build configuration in a separate build script you can much 
easier use whatever full blown language you want, Ruby, Python or even 
D. I can assure you, there's no point in trying to invent a new 
"language" for these kind of things.

-- 
/Jacob Carlborg



 Nov 27 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


The benefit is standardization. There will no longer be an annoying mess of
tons of different build systems with tons of different rules. This is the
same reason why there's DDOC and not external tool.


On Tue, Nov 27, 2012 at 4:24 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-27 08:47, Gor Gyolchanyan wrote:


 Just like DDOC adds auxiliary information to create documentation, build
 comments would add auxiliary information to create build scripts (which
 a tool could just use right away without generating garbage in the form
 of build script files).


 These special comments would just be the build script. I see no advantage
 of having any form of special comments for a build tool. The only advantage
 could be if you only have a single source file, then you can safe a file by
 combining the source file and build file.

 Besides from this, it would be just like any other build script. If you
 put the build configuration in a separate build script you can much easier
 use whatever full blown language you want, Ruby, Python or even D. I can
 assure you, there's no point in trying to invent a new "language" for these
 kind of things.

 --
 /Jacob Carlborg




-- 
Bye,
Gor Gyolchanyan.



 Nov 27 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 13:35, Gor Gyolchanyan wrote:

 The benefit is standardization. There will no longer be an annoying mess
 of tons of different build systems with tons of different rules. This is
 the same reason why there's DDOC and not external tool.


I don't think it's right to add a build tool to the compiler. There can 
be a standard built tool even if it's not in the compiler.

-- 
/Jacob Carlborg



 Nov 27 2012



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 13:42, Jacob Carlborg wrote:


 I don't think it's right to add a build tool to the compiler. There can
 be a standard built tool even if it's not in the compiler.


I mean, DSSS was basically the standard build tool back in the D1 days. 
Unfortunately it's not maintained any more. One problem with DSSS was 
that it used its own copy of the DMD front end. This was before the 
compiler got the "-deps" swithc, which is what RDMD uses.

It doesn't help that the compiler is poorly designed/structured with no 
regard to support third party tools using the compiler as a library.

-- 
/Jacob Carlborg



 Nov 27 2012



prev sibling  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


There's a good reason why all libraries come with their build scripts,
rather then rely on the client to build them as necessary. The reason is
that the source code is where the necessary building conditions are
defined, even if as a separate file. You can't write anything more, then a
100 LOC source file without having to make a build script. The source files
in a project heavily depend on the build script to produce the correct
result. This is why I don't see any reason why building process should be
separated from the source code.


On Tue, Nov 27, 2012 at 4:42 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-27 13:35, Gor Gyolchanyan wrote:


 The benefit is standardization. There will no longer be an annoying mess
 of tons of different build systems with tons of different rules. This is
 the same reason why there's DDOC and not external tool.


 I don't think it's right to add a build tool to the compiler. There can be
 a standard built tool even if it's not in the compiler.

 --
 /Jacob Carlborg




-- 
Bye,
Gor Gyolchanyan.



 Nov 27 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 13:50, Gor Gyolchanyan wrote:

 There's a good reason why all libraries come with their build scripts,
 rather then rely on the client to build them as necessary. The reason is
 that the source code is where the necessary building conditions are
 defined, even if as a separate file. You can't write anything more, then
 a 100 LOC source file without having to make a build script. The source
 files in a project heavily depend on the build script to produce the
 correct result. This is why I don't see any reason why building process
 should be separated from the source code.


I don't understand what you're saying. Of course the build scripts need 
to be shipped with the library. I just don't think you should put the 
build script inline with the source code. I think it should be a 
separate file.

-- 
/Jacob Carlborg



 Nov 27 2012



 next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


Why do you think so? The build script is inseparable from the project
source files. What makes the build script necessary to be separate?


On Tue, Nov 27, 2012 at 7:42 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-27 13:50, Gor Gyolchanyan wrote:


 There's a good reason why all libraries come with their build scripts,
 rather then rely on the client to build them as necessary. The reason is
 that the source code is where the necessary building conditions are
 defined, even if as a separate file. You can't write anything more, then
 a 100 LOC source file without having to make a build script. The source
 files in a project heavily depend on the build script to produce the
 correct result. This is why I don't see any reason why building process
 should be separated from the source code.


 I don't understand what you're saying. Of course the build scripts need to
 be shipped with the library. I just don't think you should put the build
 script inline with the source code. I think it should be a separate file.

 --
 /Jacob Carlborg




-- 
Bye,
Gor Gyolchanyan.



 Nov 27 2012



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 16:50, Gor Gyolchanyan wrote:

 Why do you think so? The build script is inseparable from the project
 source files. What makes the build script necessary to be separate?


In which source file would you put the build script?

As I said before. I think it's easier to have the build script in a full 
blown language if it's a separate file.

I would also think that one could have various tasks in a build script. 
For example: running tests, generating documentation and so on.

-- 
/Jacob Carlborg



 Nov 27 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 16:50, Gor Gyolchanyan wrote:

 Why do you think so? The build script is inseparable from the project
 source files. What makes the build script necessary to be separate?


BTW, how should the compiler handle these build settings? I mean, the 
compiler need to first find the file containing the build settings, 
somehow. Either by convention or by specify on the command line the file 
containing the build settings.

The problem, if you can have build settings in any source file, is that 
the compiler will first need to scan all source files for these 
settings. Then it needs to rescan the files again for the regular 
compile phase.

-- 
/Jacob Carlborg



 Nov 27 2012



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/27/12 10:42 AM, Jacob Carlborg wrote:

 On 2012-11-27 13:50, Gor Gyolchanyan wrote:

 There's a good reason why all libraries come with their build scripts,
 rather then rely on the client to build them as necessary. The reason is
 that the source code is where the necessary building conditions are
 defined, even if as a separate file. You can't write anything more, then
 a 100 LOC source file without having to make a build script. The source
 files in a project heavily depend on the build script to produce the
 correct result. This is why I don't see any reason why building process
 should be separated from the source code.


 I don't understand what you're saying. Of course the build scripts need
 to be shipped with the library. I just don't think you should put the
 build script inline with the source code. I think it should be a
 separate file.


I think it's best to offer the choice.

Andrei



 Nov 27 2012



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/27/12 7:35 AM, Gor Gyolchanyan wrote:

 The benefit is standardization. There will no longer be an annoying mess
 of tons of different build systems with tons of different rules. This is
 the same reason why there's DDOC and not external tool.


Even with --shebang there are odd limitations of the shebang line length 
etc. I think it would make sense to add options in the form of a 
stylized comment below the shebang line. That comment can be read and 
parsed by rdmd appropriately. For example:


/**rdmdoptions
-L-lmylib
*/
...

What would be some useful options to add, aside from those already 
supported?


Andrei



 Nov 27 2012



 next sibling parent reply Robert <jfanatiker gmx.at>  writes:



 /**rdmdoptions
 -L-lmylib
 */
 ...
 
 What would be some useful options to add, aside from those already 
 supported?
 


Providing arbitrary compiler flags would already be a huge gain. So one
can pass libs, -I include paths, ...



 Nov 27 2012



  parent reply "jerro" <a a.com>  writes:


 Providing arbitrary compiler flags would already be a huge 
 gain. So one
 can pass libs, -I include paths, ...


You can already pass -I and -L and they are passed on to DMD 
(along with any other flags that rdmd doesn't recognize AFAIK.



 Nov 27 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/27/12 12:37 PM, jerro wrote:

 Providing arbitrary compiler flags would already be a huge gain. So one
 can pass libs, -I include paths, ...


 You can already pass -I and -L and they are passed on to DMD (along with
 any other flags that rdmd doesn't recognize AFAIK.


The advantage would be that you get to wire the options inside the 
script instead of requiring them in the invocation thereof.

Again, --shebang does help there but my experience with it has been 
terrible: I recall on one OS the shebang line was silently truncated so 
some of my options were not passed although I was convinced they were.


Andrei



 Nov 27 2012



  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


I didn't see a single example of build script usage where it wasn't tied to
the sources and where the sources could be easily compiled without it. The
sources define what the binary will look like and so do the build scripts.
That's why I think it's a good idea to combine them.

As for the question "where to put those comments?":
There was an enhancement issue in bugzilla about allowing modules to be
named "package" in which case they are imported by their package name
alone. The build comments in those modules would be propagated to the
entire package and the subpackages would be able to override.


On Tue, Nov 27, 2012 at 9:40 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/27/12 12:37 PM, jerro wrote:


 Providing arbitrary compiler flags would already be a huge gain. So one

 can pass libs, -I include paths, ...


 You can already pass -I and -L and they are passed on to DMD (along with
 any other flags that rdmd doesn't recognize AFAIK.


 The advantage would be that you get to wire the options inside the script
 instead of requiring them in the invocation thereof.

 Again, --shebang does help there but my experience with it has been
 terrible: I recall on one OS the shebang line was silently truncated so
 some of my options were not passed although I was convinced they were.


 Andrei




-- 
Bye,
Gor Gyolchanyan.



 Nov 27 2012



prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com>  writes:


On Tuesday, 27 November 2012 at 16:04:47 UTC, Andrei Alexandrescu 
wrote:



 /**rdmdoptions
 -L-lmylib
 */
 ...



 ("compiler options", "-L-lmylib") module main;
...

Maybe... sorry I don't know if this would work with current UDA.



 Nov 27 2012



  parent reply 1100110 <0b1100110 gmail.com>  writes:


On 11/27/2012 02:37 PM, Jesse Phillips wrote:

 On Tuesday, 27 November 2012 at 16:04:47 UTC, Andrei Alexandrescu wrote:



 /**rdmdoptions
 -L-lmylib
 */
 ...



  ("compiler options", "-L-lmylib") module main;
 ...

 Maybe... sorry I don't know if this would work with current UDA.


pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");



 Nov 28 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 20:23, 1100110 wrote:


 pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");


How would the compiler handle flags which add new import paths? Should 
it first scan all source files after this special pragma(build). Then 
rescan the source files again to see if any new pragma(build) was found. 
Then, yet again, it need to rescan the files for the regular compile phase.

-- 
/Jacob Carlborg



 Nov 28 2012



 next sibling parent reply 1100110 <0b1100110 gmail.com>  writes:


On 11/28/2012 01:32 PM, Jacob Carlborg wrote:

 On 2012-11-28 20:23, 1100110 wrote:


 pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");


 How would the compiler handle flags which add new import paths? Should
 it first scan all source files after this special pragma(build). Then
 rescan the source files again to see if any new pragma(build) was found.
 Then, yet again, it need to rescan the files for the regular compile phase.


Oops, should have left off rdmd...  It was meant to be an alternate 
place for command-line flags.

Good question.  You could require it to be in the file passed to the 
compiler, which I like.  Or you could simply look for pragma(build) at 
the same time you look for imports.  look *once* per file.

I don't know how the compiler handles the arguments passed internally.
You know what? Just say it's in the file passed to rdmd.  If you need 
something more complex that a simple place to put the args, you need 
something bigger than what this can give.


rdmd main.d

cat main.d
module main

import std.stdio;
import std.string;
static import(file.jpg);//I forget the syntax...
pragma(build, "-jviews -src -O -release -inline");
pragma(lib, "ssl");
pragma(lib, "dl");
pragma(lib, "event_pthreads");

void main(){} blah blah blah...
EOF

If that doesn't cover 99% of your use-case, you obviously need something 
way bigger.

Tell people to compile using rdmd main.d.  If args are passed on the 
cmdline, then don't even bother looking for pragma(build).



 Nov 28 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 21:25, 1100110 wrote:


 Good question.  You could require it to be in the file passed to the
 compiler, which I like.


RDMD will pass all files to the compiler, how would it know which one to 
look in? Or should RDMD handle the pragma?


 Or you could simply look for pragma(build) at
 the same time you look for imports.  look *once* per file.


That won't work. Example:

module foo;

import bar.baz;

module main;

pragma(build, "-I/usr/local/include/d/barlib/");

If compiler sees the "foo" module first it will fail to find "bar.baz" 
since it doesn't yet know about the import path added in the "main" module.


 I don't know how the compiler handles the arguments passed internally.
 You know what? Just say it's in the file passed to rdmd.  If you need
 something more complex that a simple place to put the args, you need
 something bigger than what this can give.


Yes, that's what I'm trying to say. Why settle with that when we could 
support both simple projects with a single source file and more complex 
ones with many files.


 rdmd main.d

 cat main.d
 module main

 import std.stdio;
 import std.string;
 static import(file.jpg);//I forget the syntax...
 pragma(build, "-jviews -src -O -release -inline");
 pragma(lib, "ssl");
 pragma(lib, "dl");
 pragma(lib, "event_pthreads");

 void main(){} blah blah blah...
 EOF

 If that doesn't cover 99% of your use-case, you obviously need something
 way bigger.


How about this use case, building a library. RDMD cannot handle this.


 Tell people to compile using rdmd main.d.  If args are passed on the
 cmdline, then don't even bother looking for pragma(build).



-- 
/Jacob Carlborg



 Nov 28 2012



prev sibling  parent reply 1100110 <0b1100110 gmail.com>  writes:


On 11/28/2012 01:32 PM, Jacob Carlborg wrote:

 On 2012-11-28 20:23, 1100110 wrote:


 pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");


 How would the compiler handle flags which add new import paths? Should
 it first scan all source files after this special pragma(build). Then
 rescan the source files again to see if any new pragma(build) was found.
 Then, yet again, it need to rescan the files for the regular compile phase.


I'll obviously need a little help defining the semantics.  =P

I can see this going 3 different ways, with different levels of complexity.

Halt and run this cmd(Gor wants.  I can sense his longing from here..)



 Nov 28 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 21:29, 1100110 wrote:


 I'll obviously need a little help defining the semantics.  =P

 I can see this going 3 different ways, with different levels of complexity.

 Halt and run this cmd(Gor wants.  I can sense his longing from here..)


If you put the flags on the command line or in a separate file then you 
won't have this problems.

-- 
/Jacob Carlborg



 Nov 28 2012



prev sibling  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


awesome idea! and that can be put into static if-s and such!!


On Wed, Nov 28, 2012 at 11:23 PM, 1100110 <0b1100110 gmail.com> wrote:


 On 11/27/2012 02:37 PM, Jesse Phillips wrote:


 On Tuesday, 27 November 2012 at 16:04:47 UTC, Andrei Alexandrescu wrote:



 /**rdmdoptions
 -L-lmylib
 */
 ...



  ("compiler options", "-L-lmylib") module main;
 ...

 Maybe... sorry I don't know if this would work with current UDA.


 pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");




-- 
Bye,
Gor Gyolchanyan.



 Nov 28 2012



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 11/28/2012 3:04 AM, Andrei Alexandrescu wrote:

 Even with --shebang there are odd limitations of the shebang line length
 etc. I think it would make sense to add options in the form of a
 stylized comment below the shebang line. That comment can be read and
 parsed by rdmd appropriately. For example:


 /**rdmdoptions
 -L-lmylib
 */
 ...


There's gotta be a better syntax than that!



 Nov 28 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/28/12 8:00 AM, Walter Bright wrote:

 On 11/28/2012 3:04 AM, Andrei Alexandrescu wrote:

 Even with --shebang there are odd limitations of the shebang line length
 etc. I think it would make sense to add options in the form of a
 stylized comment below the shebang line. That comment can be read and
 parsed by rdmd appropriately. For example:


 /**rdmdoptions
 -L-lmylib
 */
 ...


 There's gotta be a better syntax than that!


I think so too. Ideas?

Andrei



 Nov 28 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


How about:

//! -L-lmylib


On Wed, Nov 28, 2012 at 6:29 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/28/12 8:00 AM, Walter Bright wrote:


 On 11/28/2012 3:04 AM, Andrei Alexandrescu wrote:


 Even with --shebang there are odd limitations of the shebang line length
 etc. I think it would make sense to add options in the form of a
 stylized comment below the shebang line. That comment can be read and
 parsed by rdmd appropriately. For example:


 /**rdmdoptions
 -L-lmylib
 */
 ...


 There's gotta be a better syntax than that!


 I think so too. Ideas?

 Andrei




-- 
Bye,
Gor Gyolchanyan.



 Nov 28 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/28/12 10:43 AM, Gor Gyolchanyan wrote:

 How about:

 //! -L-lmylib


Sux for multiple lines.

Andrei



 Nov 28 2012



 next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


But not as bad as the "rdmdoptions".

//! line1
//! line2
//! line3

Doesn't look THAT terrible.


On Wed, Nov 28, 2012 at 8:22 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/28/12 10:43 AM, Gor Gyolchanyan wrote:


 How about:

 //! -L-lmylib


 Sux for multiple lines.

 Andrei



-- 
Bye,
Gor Gyolchanyan.



 Nov 28 2012



prev sibling  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 28 November 2012 16:22, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 On 11/28/12 10:43 AM, Gor Gyolchanyan wrote:

 How about:

 //! -L-lmylib



 Sux for multiple lines.

 Andrei


Wouldn't keeping it on the shebang work?




-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Nov 28 2012



  parent  1100110 <0b1100110 gmail.com>  writes:


On 11/28/2012 02:52 PM, Iain Buclaw wrote:

 On 28 November 2012 16:22, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:

 On 11/28/12 10:43 AM, Gor Gyolchanyan wrote:

 How about:

 //! -L-lmylib



 Sux for multiple lines.

 Andrei


 Wouldn't keeping it on the shebang work?




Yeah and so would pragma(lib).  But only for that specific case.  =P 
shebang only takes one (1) argument.



 Nov 28 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 17:04, Andrei Alexandrescu wrote:


 Even with --shebang there are odd limitations of the shebang line length
 etc. I think it would make sense to add options in the form of a
 stylized comment below the shebang line. That comment can be read and
 parsed by rdmd appropriately. For example:


 /**rdmdoptions
 -L-lmylib
 */
 ...

 What would be some useful options to add, aside from those already
 supported?


I don't know why anyone would bother implementing this. What's needed is 
a proper build tool. That includes build scripts that can be written in 
a full blow language.

-- 
/Jacob Carlborg



 Nov 28 2012



 next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


I think that would be a huge mistake. Why would anyone want to invent a
full blown language and a big pain in the butt just to build a project if
the project can build itself by looking at the source code?


On Wed, Nov 28, 2012 at 7:48 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-27 17:04, Andrei Alexandrescu wrote:

  Even with --shebang there are odd limitations of the shebang line length

 etc. I think it would make sense to add options in the form of a
 stylized comment below the shebang line. That comment can be read and
 parsed by rdmd appropriately. For example:


 /**rdmdoptions
 -L-lmylib
 */
 ...

 What would be some useful options to add, aside from those already
 supported?


 I don't know why anyone would bother implementing this. What's needed is a
 proper build tool. That includes build scripts that can be written in a
 full blow language.

 --
 /Jacob Carlborg




-- 
Bye,
Gor Gyolchanyan.



 Nov 28 2012



 next sibling parent reply "jerro" <a a.com>  writes:


On Wednesday, 28 November 2012 at 15:51:50 UTC, Gor Gyolchanyan 
wrote:

 I think that would be a huge mistake. Why would anyone want to 
 invent a
 full blown language and a big pain in the butt just to build a 
 project if
 the project can build itself by looking at the source code?


The build system could be a library written in D, then you 
wouldn't need to invent a new language.



 Nov 28 2012



 next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


Precisely!


On Wed, Nov 28, 2012 at 8:59 PM, jerro <a a.com> wrote:


 On Wednesday, 28 November 2012 at 15:51:50 UTC, Gor Gyolchanyan wrote:


 I think that would be a huge mistake. Why would anyone want to invent a
 full blown language and a big pain in the butt just to build a project if
 the project can build itself by looking at the source code?


 The build system could be a library written in D, then you wouldn't need
 to invent a new language.




-- 
Bye,
Gor Gyolchanyan.



 Nov 28 2012



  parent reply "jerro" <a a.com>  writes:


On Wednesday, 28 November 2012 at 17:02:25 UTC, Gor Gyolchanyan 
wrote:

 Precisely!


 On Wed, Nov 28, 2012 at 8:59 PM, jerro <a a.com> wrote:


 On Wednesday, 28 November 2012 at 15:51:50 UTC, Gor 
 Gyolchanyan wrote:


 I think that would be a huge mistake. Why would anyone want 
 to invent a
 full blown language and a big pain in the butt just to build 
 a project if
 the project can build itself by looking at the source code?


 The build system could be a library written in D, then you 
 wouldn't need
 to invent a new language.




I mean't writing a D build library and using it to write build 
scripts separate from the source files that are being build. 
That's quite different from embedding build instructions into 
comments inside the source files.



 Nov 28 2012



  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


Still better, then a completely separate thing.


On Wed, Nov 28, 2012 at 9:09 PM, jerro <a a.com> wrote:


 On Wednesday, 28 November 2012 at 17:02:25 UTC, Gor Gyolchanyan wrote:


 Precisely!


 On Wed, Nov 28, 2012 at 8:59 PM, jerro <a a.com> wrote:

  On Wednesday, 28 November 2012 at 15:51:50 UTC, Gor Gyolchanyan wrote:

  I think that would be a huge mistake. Why would anyone want to invent a

 full blown language and a big pain in the butt just to build a project
 if
 the project can build itself by looking at the source code?


 The build system could be a library written in D, then you wouldn't need
 to invent a new language.




 I mean't writing a D build library and using it to write build scripts
 separate from the source files that are being build. That's quite different
 from embedding build instructions into comments inside the source files.




-- 
Bye,
Gor Gyolchanyan.



 Nov 28 2012



prev sibling  parent  "Rob T" <rob ucora.com>  writes:


On Wednesday, 28 November 2012 at 16:59:25 UTC, jerro wrote:

 On Wednesday, 28 November 2012 at 15:51:50 UTC, Gor Gyolchanyan 
 wrote:

 I think that would be a huge mistake. Why would anyone want to 
 invent a
 full blown language and a big pain in the butt just to build a 
 project if
 the project can build itself by looking at the source code?


 The build system could be a library written in D, then you 
 wouldn't need to invent a new language.


That would be very nice. I'm currently not at all happy with the 
build systems I've tried out and I'd definitely be willing to try 
something new.

I also don't like having to learn a separate complicated script 
language that has no use other than to build a project - to me 
that's a massive time sink that should be unnecessary.

The ultimate would be for D to build itself, but of course you'll 
need to configure something to tell it where to build to, where 
to install to, etc.

I just don't see why building a source project has to be 
difficult, or why build systems have to be so terrible at doing 
it.

--rt



 Nov 28 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 16:51, Gor Gyolchanyan wrote:

 I think that would be a huge mistake. Why would anyone want to invent a
 full blown language and a big pain in the butt just to build a project
 if the project can build itself by looking at the source code?


Where on earth did I say anyone should invent a new language. I said use 
a separate file for the build script and use an already existing 
language like Ruby, Python, D or whatever.

On the other hand you and Andrei is starting to invent a new language. 
And you're putting them in comments. Talk about killing syntax highlighting.

-- 
/Jacob Carlborg



 Nov 28 2012



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/28/12 10:48 AM, Jacob Carlborg wrote:

 On 2012-11-27 17:04, Andrei Alexandrescu wrote:


 Even with --shebang there are odd limitations of the shebang line length
 etc. I think it would make sense to add options in the form of a
 stylized comment below the shebang line. That comment can be read and
 parsed by rdmd appropriately. For example:


 /**rdmdoptions
 -L-lmylib
 */
 ...

 What would be some useful options to add, aside from those already
 supported?


 I don't know why anyone would bother implementing this. What's needed is
 a proper build tool. That includes build scripts that can be written in
 a full blow language.


I disagree.

Andrei



 Nov 28 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 17:23, Andrei Alexandrescu wrote:


 I disagree.


How would you handle the following with your comments:

* Platform specific flags
* Adding/ignoring certain files
* Invoking separate build systems to handle foreign languages
* Different flags for debug and release builds

That's just mentioning a few cases.

Also, in which source file would you put these special comments?

-- 
/Jacob Carlborg



 Nov 28 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/28/12 2:20 PM, Jacob Carlborg wrote:

 On 2012-11-28 17:23, Andrei Alexandrescu wrote:


 I disagree.


 How would you handle the following with your comments:

 * Platform specific flags * Adding/ignoring certain files * Invoking
 separate build systems to handle foreign languages * Different flags
 for debug and release builds

 That's just mentioning a few cases.

 Also, in which source file would you put these special comments?


The tool would have inherent limitations. What I disagree with is this
umbrella statement:


 What's needed
 is a proper build tool. That includes build scripts that can be
 written in a full blow language.


I recall you have written such a tool (Orbit), so it is natural to have 
a vested interest in promoting it and argue for its usefulness. Such 
arguments don't eliminate the need for simpler tools that obviate 
Orbit's use for a subset of cases.


Andrei



 Nov 28 2012



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 20:39, Andrei Alexandrescu wrote:


 I recall you have written such a tool (Orbit), so it is natural to have
 a vested interest in promoting it and argue for its usefulness. Such
 arguments don't eliminate the need for simpler tools that obviate
 Orbit's use for a subset of cases.


1. Orbit is a package manager, not a build tool (although I'm developing 
that as well). A package manager deals with a packages, a build tool 
deals with files

2. I would not create a tool that cannot be used in the most simple uses 
cases. I'm thinking of scale. From the most simple use cases to the more 
advance use cases.

The build tool I'm developing will work like this. In it's most simple 
usage it can be used as:

$ build main.d

Which will do basically what RDMD does, but without running the 
executable. You can also pass arbitrary compile and link flags:

$ build main.d -release -L-lcurl

So far still just basically what RDMD does. The interesting thing is 
when you need to do more advanced build setups or avoiding repeating 
compile flags. Then you can start using a build script. The most simple 
build script will look something like this:

target :main

If there's a file named "main.d" it will build an executable, just like 
RDMD does. If there's a folder named "main" it will build a library of 
all files in that folder, recursively. Not something that RDMD can 
currently handle.

Adding some flags to the build script:

target :main do
   flags :build << "-release"
   flags :link << "-lcurl"
end

Then adding some special settings for a platform:

target :main do
   flags.build << "-release"
   flags.link << "-lcurl"

   if platform.windows
     flags.link << "some flag"
   end
end

Then adding a task for creating a release of the software:

task :release do

end

-- 
/Jacob Carlborg



 Nov 28 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 20:39, Andrei Alexandrescu wrote:


 I recall you have written such a tool (Orbit), so it is natural to have
 a vested interest in promoting it and argue for its usefulness. Such
 arguments don't eliminate the need for simpler tools that obviate
 Orbit's use for a subset of cases.


BTW, I'm not arguing for this just because I'm building a tool. I'm 
arguing because the existing tools are not good enough, or does not do 
enough of what I want. RDMD is good enough for what it does, but it's 
not enough for what I need. I use it every day when compiling single or 
just a few source files.

I was a happy DSSS user back in the days of D1 and still are for the few 
projects I have left written in D1. I have no problem in using someones 
other tool if it does what I want. I'm just saying that if we want to 
have a standard/de facto build tool in the D community it needs be able 
to handle all kinds of projects, not just simple scripts. It do need to 
be able to handle those simple projects making it simple enough to use 
to be useful.

-- 
/Jacob Carlborg



 Nov 28 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 17:23, Andrei Alexandrescu wrote:


 I disagree.


Have you looked at the makefile for any of the D projects, how would you 
do that with your comments?

-- 
/Jacob Carlborg



 Nov 28 2012



  parent reply 1100110 <0b1100110 gmail.com>  writes:


On 11/28/2012 01:33 PM, Jacob Carlborg wrote:

 On 2012-11-28 17:23, Andrei Alexandrescu wrote:


 I disagree.


 Have you looked at the makefile for any of the D projects, how would you
 do that with your comments?


If you need something that complex then you need something that complex.


It doesn't change the fact that most of the time, I simply create a 
shell file that says: rdmd -O -g -gc --version=web main.d

or similar.  Its all I need 99% of the time.



 Nov 28 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 21:32, 1100110 wrote:


 If you need something that complex then you need something that complex.


 It doesn't change the fact that most of the time, I simply create a
 shell file that says: rdmd -O -g -gc --version=web main.d

 or similar.  Its all I need 99% of the time.


It also doesn't change the fact that these uses cases can be supported 
by the same tool. Just try to think about it a bit not just rushing on 
with the first idea that pops up.

-- 
/Jacob Carlborg



 Nov 28 2012



  parent reply 1100110 <0b1100110 gmail.com>  writes:


On 11/28/2012 03:11 PM, Jacob Carlborg wrote:

 On 2012-11-28 21:32, 1100110 wrote:


 If you need something that complex then you need something that complex.


 It doesn't change the fact that most of the time, I simply create a
 shell file that says: rdmd -O -g -gc --version=web main.d

 or similar. Its all I need 99% of the time.


 It also doesn't change the fact that these uses cases can be supported
 by the same tool. Just try to think about it a bit not just rushing on
 with the first idea that pops up.


Of course.  I just can't remember the last time I needed something more 
complex than a shell script.  It would be *really* nice if the syntax 
were nice and simple.  Makefiles kick my  $$.  Implicit rules, and all 
that.

I would prefer stupidly simple to "Dang it stop calling gcc.  Where are 
you even getting the idea that I need gcc, much less want it.(yes gcc is 
linker, but it was trying to compile D files as C files.)"



 Nov 28 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 22:24, 1100110 wrote:


 Of course.  I just can't remember the last time I needed something more
 complex than a shell script.  It would be *really* nice if the syntax
 were nice and simple.  Makefiles kick my  $$.  Implicit rules, and all
 that.


I'm just trying to stop you guys from investing in a new build system 
that cannot be used for the whole community.

In most cases I also just need a shell script containing some 
compile/link flags. But what I don't like is that I need to duplicate 
the shell script, one version for Posix and one version for Windows. 
That's why I'm advocating for using build scripts written in a full blow 
language that already exists and works cross platform.

I do also manage DWT which requires a bit more complex build system then 
a simple shell script with some compile flags.

Also, I can't for my life understand why the compiler can't have flags 
for handling common linking flags, like adding a library or a search 
path for libraries. That should of course be platform independent. If 
the compiler won't do that I'll add that to my build tool.

-- 
/Jacob Carlborg



 Nov 28 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/29/12 2:36 AM, Jacob Carlborg wrote:

 On 2012-11-28 22:24, 1100110 wrote:


 Of course. I just can't remember the last time I needed something more
 complex than a shell script. It would be *really* nice if the syntax
 were nice and simple. Makefiles kick my  $$. Implicit rules, and all
 that.


 I'm just trying to stop you guys from investing in a new build system
 that cannot be used for the whole community.

 In most cases I also just need a shell script containing some
 compile/link flags. But what I don't like is that I need to duplicate
 the shell script, one version for Posix and one version for Windows.
 That's why I'm advocating for using build scripts written in a full blow
 language that already exists and works cross platform.


Why not use D for that full-blown language? I know you insist on using 
Ruby, and I fail to grasp why we'd have D users learn Ruby in addition 
to D, when D is presumably already installed (since this is all about 
building D programs!) and D is as convenient for build scripting as Ruby.

Andrei



 Nov 29 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 14:55, Andrei Alexandrescu wrote:


 Why not use D for that full-blown language? I know you insist on using
 Ruby, and I fail to grasp why we'd have D users learn Ruby in addition
 to D, when D is presumably already installed (since this is all about
 building D programs!) and D is as convenient for build scripting as Ruby.


I still think it's possible to have a smaller, less verbose and more 
simplistic build scripts written in Ruby. BUT I would choose a proper 
build tool with build scripts written in D any day over having to use 
shell scripts or your special kind of comments.

-- 
/Jacob Carlborg



 Nov 29 2012



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/29/12 9:04 AM, Jacob Carlborg wrote:

 On 2012-11-29 14:55, Andrei Alexandrescu wrote:


 Why not use D for that full-blown language? I know you insist on using
 Ruby, and I fail to grasp why we'd have D users learn Ruby in addition
 to D, when D is presumably already installed (since this is all about
 building D programs!) and D is as convenient for build scripting as Ruby.


 I still think it's possible to have a smaller, less verbose and more
 simplistic build scripts written in Ruby.


Since you think (as opposed to believe), then there are reasons. What 
are those reasons, and what steps can we take to obviate them from the D 
side?


 BUT I would choose a proper
 build tool with build scripts written in D any day over having to use
 shell scripts or your special kind of comments.


Then why not work on it? A tool using D is much more likely to be 
accepted by the community than one using Ruby, and the latter will 
probably never be part of the official distro. I plan to change your 
Ruby installer creation scripts into shell scripts as soon as I'll have 
a minute.


Andrei



 Nov 29 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 15:28, Andrei Alexandrescu wrote:


 Since you think (as opposed to believe), then there are reasons. What
 are those reasons, and what steps can we take to obviate them from the D
 side?


Some features Ruby has that makes it less verbose to use:

* No semicolons
* Calling a method without parentheses
* Code can be executed basically every where. Global scope, module scope 
, class scope, method scope and function scope
* Blocks
* Easy to integrate into an application
* Relaxed syntax for associative array literals
* Dynamic typing can probably help as well

Actually, I'm a bit concerned about how I would do the actual 
integration if the build script was written in D. In Ruby it's easy, 
just do something like (written in D using libruby) :



target :foo do
end

// Handling the build script in D

string content = read(buildScript);
BuildScriptContext context = new BuildScriptContext;
context.instance_eval(content);

// access what's needed from "context"
string target = context.target;

writeln(target); // prints "foo"


 Then why not work on it? A tool using D is much more likely to be
 accepted by the community than one using Ruby, and the latter will
 probably never be part of the official distro.


That's not fair. I'm doing the best I can. I'm working on several D 
relate projects (including a build tool) and I don't have much time to 
work at D at all. I would really like to be able to work on these 
projects full time. But I don't know how to make money on that.


 I plan to change your
 Ruby installer creation scripts into shell scripts as soon as I'll have
 a minute.


How is that any better? Yeah I do know that you prefer shell scripts 
over Ruby. But you're arguing that I should use D instead of Ruby and 
then you're going to use shell script.

-- 
/Jacob Carlborg



 Nov 29 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/29/12 3:39 PM, Jacob Carlborg wrote:

 On 2012-11-29 15:28, Andrei Alexandrescu wrote:


 Since you think (as opposed to believe), then there are reasons. What
 are those reasons, and what steps can we take to obviate them from the D
 side?


 Some features Ruby has that makes it less verbose to use:

 * No semicolons
 * Calling a method without parentheses
 * Code can be executed basically every where. Global scope, module scope
 , class scope, method scope and function scope
 * Blocks
 * Easy to integrate into an application
 * Relaxed syntax for associative array literals
 * Dynamic typing can probably help as well


That's a good list. Some don't really affect small scripts, but some are 
important to address (e.g. running code everywhere). The way I've seen 
this done in frameworks is by using a declarative approach in 
conjunction with the Hollywood principle.


 Actually, I'm a bit concerned about how I would do the actual
 integration if the build script was written in D. In Ruby it's easy,
 just do something like (written in D using libruby) :



 target :foo do
 end


You should picture that this doesn't make any sense to someone not 
knowing Ruby (beyond a possible misspelling of "voodoo").


 // Handling the build script in D

 string content = read(buildScript);
 BuildScriptContext context = new BuildScriptContext;
 context.instance_eval(content);

 // access what's needed from "context"
 string target = context.target;

 writeln(target); // prints "foo"


I don't understand how this comparison works (but maybe that's not 
important).


 Then why not work on it? A tool using D is much more likely to be
 accepted by the community than one using Ruby, and the latter will
 probably never be part of the official distro.


 That's not fair. I'm doing the best I can. I'm working on several D
 relate projects (including a build tool) and I don't have much time to
 work at D at all. I would really like to be able to work on these
 projects full time. But I don't know how to make money on that.


Money has nothing to do with it. It's your time. Why work on something 
that may be successful instead of something that will definitely not be? 
You have been pushing for Ruby ever since build and distro tools came 
about. Drop Ruby. I know you like it. But it's not going to work here. 
Just drop it.


 I plan to change your
 Ruby installer creation scripts into shell scripts as soon as I'll have
 a minute.


 How is that any better?


It is better because it's only requiring the shell and understanding of 
shell scripting instead of yet another language. Everyone building stuff 
on Unix would know the shell.

Just so it's clear what we're talking about:

https://github.com/D-Programming-Language/installer/blob/master/osx/make.rb

This is a good example of gratuitous use of Ruby in a framework that 
ALREADY uses a makefile AND a shell script. I actually have the rewrite 
of this to a shell script somewhere, I found it so needless that I sat 
down and figured whether there's any advantage to not using the shell there.


 Yeah I do know that you prefer shell scripts
 over Ruby.


It's not me, it's you. You prefer Ruby over the more sensible shell 
scripting for this case.


 But you're arguing that I should use D instead of Ruby and
 then you're going to use shell script.


Drop Ruby.


Andrei



 Nov 29 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 22:45, Andrei Alexandrescu wrote:




 target :foo do
 end


 You should picture that this doesn't make any sense to someone not
 knowing Ruby (beyond a possible misspelling of "voodoo").


That would look like this in D :

target("foo", {

});


 I don't understand how this comparison works (but maybe that's not
 important).


I'm just showing how to handle the Ruby code in D.


 Money has nothing to do with it.


It has everything to do with it.

1. I want to live
2. To live I need to eat
3. Food cost money
4. To make money I need to work
5. I don't use D in my work
6. I basically need to work eight hours a day
7. And I need to sleep eight hours a night
8. As said, I need to eat and do other things as well that take time
9. Not much time left for D

If I could use D in my work or even better by job was to work on these D 
projects I could get things done a lot sooner.

It has everything to do with money.


 It's your time. Why work on something
 that may be successful instead of something that will definitely not be?


These comments will more than definitely not be successful.


 You have been pushing for Ruby ever since build and distro tools came
 about. Drop Ruby. I know you like it. But it's not going to work here.
 Just drop it.


I said a build tool need to support build scripts written in a full 
blown language. I mentioned Ruby, Python and D. I don't know where Ruby 
was brought into the discussion.


 It is better because it's only requiring the shell


That doesn't matter. What's matter is what comes pre-installed on a 
given operating system. Since this will only run on Mac OS X and Mac OS 
X comes pre-installed with Ruby there's no problem.

  and understanding of

 shell scripting instead of yet another language.


Shell script is yet another language and a quite horrible one. I mean, I 
can't have spaces around the equal sign when assigning a variable.


Everyone building stuff on Unix would know the shell.


Fair enough.


 Just so it's clear what we're talking about:

 https://github.com/D-Programming-Language/installer/blob/master/osx/make.rb


I know.


 This is a good example of gratuitous use of Ruby in a framework that
 ALREADY uses a makefile AND a shell script. I actually have the rewrite
 of this to a shell script somewhere, I found it so needless that I sat
 down and figured whether there's any advantage to not using the shell
 there.


No, there's no advantage of not using the shell. The Ruby script mostly 
call shell command and other commands anyway. I just don't like shell 
script.


 Yeah I do know that you prefer shell scripts
 over Ruby.


 It's not me, it's you. You prefer Ruby over the more sensible shell
 scripting for this case.


 But you're arguing that I should use D instead of Ruby and
 then you're going to use shell script.


 Drop Ruby.


Now you're just mean.

-- 
/Jacob Carlborg



 Nov 29 2012



prev sibling  parent reply "Rob T" <rob ucora.com>  writes:


On Thursday, 29 November 2012 at 14:04:32 UTC, Jacob Carlborg 
wrote:

 I still think it's possible to have a smaller, less verbose and 
 more simplistic build scripts written in Ruby. BUT I would 
 choose a proper build tool with build scripts written in D any 
 day over having to use shell scripts or your special kind of 
 comments.


The very last thing I would want to do is to futz around 
installing Ruby and learning Ruby for the sole purpose of 
building a D application. Think about how massive a time sink 
that is for anyone who has no other reason to invest their 
valuable time into Ruby. I got sucked into this trap with Make, 
which wasted many hours of what should have been productive time, 
and I saw the exact same issues repeat when I investigated scons 
as a potential alternative. I just fail to see why this kind of 
complexity is necessary at all. If we can fix the problem at the 
source, then we should do it, rather than pile more mess on top 
of the existing pile of mess.

I do however think you have a good point wrt the use of 
"comments" for doing this stuff. Please do not use comments for 
this, make it a part of the language for real, like CTFE or 
something.

For example I find that implementing the ddoc system as 
"comments" was a mistake, because when you do it in that way, you 
think of those constructs as being comments like any other, and 
that limits the thinking concerning what can (or could have been) 
done with them. Ddoc could and should be much more than it is, 
even if it was started off in a limited way, it at least could 
have the potential to expand in a more useful way.

--rt



 Nov 29 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 19:53, Rob T wrote:


 The very last thing I would want to do is to futz around installing Ruby
 and learning Ruby for the sole purpose of building a D application.


Ruby would not be a runtime dependency. It's embedded in the tool just 
like any other library. BTW, I never heard anyone complain about the 
DSSS build scripts. Which is completely custom, something like a 
combination of ini files and statements. Ruby is at least a real 
language. An example from DSSS:

version (build) {
     pragma(link, "example");
}

If I recall correctly, you need to use that exact syntax. If you move 
the first brace to a new line it won't work. That's the problem one get 
when using custom "languages" for these kind of things.


 Think about how massive a time sink that is for anyone who has no other
 reason to invest their valuable time into Ruby. I got sucked into this
 trap with Make, which wasted many hours of what should have been
 productive time, and I saw the exact same issues repeat when I
 investigated scons as a potential alternative. I just fail to see why
 this kind of complexity is necessary at all. If we can fix the problem
 at the source, then we should do it, rather than pile more mess on top
 of the existing pile of mess.


What's the difference compared to any other build tool. Where you have 
to learn some kind of special syntax. This is a special syntax as well, 
just happens to be a real language as well.


 I do however think you have a good point wrt the use of "comments" for
 doing this stuff. Please do not use comments for this, make it a part of
 the language for real, like CTFE or something.


I don't think that will work. How will the compiler handling imports 
paths? I need to have all imports path before starting to compile. 
Otherwise it needs to rescan the source files several times.

-- 
/Jacob Carlborg



 Nov 29 2012



 next sibling parent reply "Rob T" <rob ucora.com>  writes:


On Thursday, 29 November 2012 at 20:47:49 UTC, Jacob Carlborg 
wrote:

 On 2012-11-29 19:53, Rob T wrote:
 Ruby would not be a runtime dependency. It's embedded in the 
 tool just like any other library.


OK, that's better,


 If I recall correctly, you need to use that exact syntax. If 
 you move the first brace to a new line it won't work. That's 
 the problem one get when using custom "languages" for these 
 kind of things.


OK, but the idea is to get rid of DSSS like systems, partly for 
the same sort of reasons.


 What's the difference compared to any other build tool. Where 
 you have to learn some kind of special syntax. This is a 
 special syntax as well, just happens to be a real language as 
 well.


For the moment, let's talk about ddoc, or unit testing in D. 
That's the difference, it's not an external tool set, it's 
instead a a part of the standard language feature set. BTW, IMO 
ddoc was implemented poorly, using comments, which I fully agree 
with you would be a vary bad way to go about implementing the 
feature. In that case, I would rather use Ruby.


 the language for real, like CTFE or something.


 I don't think that will work. How will the compiler handling 
 imports paths? I need to have all imports path before starting 
 to compile. Otherwise it needs to rescan the source files 
 several times.


Perhaps a better choice of an analogy would be the way unit 
testing is done rather than CTFE, however I will have to be 
specialized for the particular task.

I would say that the build specific code would have to go into 
the main.d file, but since libraries do not have a "main" file, 
the build process code would have to go into another file, 
perhaps named "build.d", that contains the entire build section 
which the compiler uses to kick off the build process. The 
build.d files can be chained so that multiple related projects 
can be constructed.

In any event, I'd ask how do the current build systems do it? 
They read and parse through the source files to learn about 
dependencies OR a programmer specifies all of it manually, which 
is a complete nightmare to maintain on large projects. Now, if 
things were designed correctly, I don't see why a semi-automated 
build, using internally specified build options for manual 
tweaking where needed, cannot be done with an embedded build 
system.

Another analogy is to think about languages that have embedded 
reflection - unfortunately D currently lacks a generalized 
solution for reflection, but you can see hints of the potential 
it offers. Simplifying how builds are performed through 
"reflection" will increase productivity, and will potentially 
offer new ways of solving old problems well past what was 
considered possible before.

Clearly, I don't have all the answers, this is an idea being 
thought out on the fly, so how it will work is entirely up for 
discussion. I'm just trying to think outside the box, looking for 
something much more sensible than the same old messy build system.

--rt



 Nov 29 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 23:06, Rob T wrote:


 For the moment, let's talk about ddoc, or unit testing in D. That's the
 difference, it's not an external tool set, it's instead a a part of the
 standard language feature set. BTW, IMO ddoc was implemented poorly,
 using comments, which I fully agree with you would be a vary bad way to
 go about implementing the feature. In that case, I would rather use Ruby.


The built-in support for unit testing is too simplistic. I think one 
needs an external tool anyway that makes use of the built-in support 
unit tests.

I just want to be able to do something like:

$ test a.d b.d

And it will run all unit tests in the modules "a" and "b". In D I need 
to manually creating a test module which imports all modules I want to 
test. This will give the most basic functionality. This is a few things 
of that's missing:

* Run a single test
* Names or context for the tests
* Nice report of which tests failed
* Continue running other tests if a given test failed


 I would say that the build specific code would have to go into the
 main.d file, but since libraries do not have a "main" file, the build
 process code would have to go into another file, perhaps named
 "build.d", that contains the entire build section which the compiler
 uses to kick off the build process. The build.d files can be chained so
 that multiple related projects can be constructed.


That's the exact same thing as I'm proposing, except it's the compiler 
handling it.


 In any event, I'd ask how do the current build systems do it? They read
 and parse through the source files to learn about dependencies


No, they:

1. Run "$ dmd -o- -c main.d -deps=deps.txt" which will write out all 
dependencies of "main.d" to "deps.txt"

2. Read the "deps.txt" file and pass all files to dmd


 OR a programmer specifies all of it manually, which is a complete nightmare
 to maintain on large projects.


I completely agree.


 Now, if things were designed correctly, I
 don't see why a semi-automated build, using internally specified build
 options for manual tweaking where needed, cannot be done with an
 embedded build system.


If it was designed correctly the compiler would be built as a library. 
The build tool could the use this library to get all the dependencies of 
a given source file.


 Another analogy is to think about languages that have embedded
 reflection - unfortunately D currently lacks a generalized solution for
 reflection, but you can see hints of the potential it offers.
 Simplifying how builds are performed through "reflection" will increase
 productivity, and will potentially offer new ways of solving old
 problems well past what was considered possible before.


Do you have any example?

-- 
/Jacob Carlborg



 Nov 30 2012



 next sibling parent reply "Rob T" <rob ucora.com>  writes:


On Friday, 30 November 2012 at 08:05:25 UTC, Jacob Carlborg wrote:

 That's the exact same thing as I'm proposing, except it's the 
 compiler handling it.


Which would be better because it is integrated and not an 
external tool.


 In any event, I'd ask how do the current build systems do it? 
 They read
 and parse through the source files to learn about dependencies


 No, they:

 1. Run "$ dmd -o- -c main.d -deps=deps.txt" which will write 
 out all dependencies of "main.d" to "deps.txt"


Personally, I don't see how that would work using the current 
form of the output. I tried it with Make to figure out 
dependencies and the problem I immediately ran into was that the 
output did not contain full path information for the projects 
modules, and without that information, there was no way to 
combine builds from related project under a separate folder. What 
I find, is that with D, people seem to be building in simple 
ways, everything under one folder. This works perhaps for many 
people, but not for everyone. Currently I want send all build 
output to a separate folder outside my project folder onto a 
separate drive, but I can't do something even that simple. Sure I 
can hack it with perhaps a symbolic, but that's a hack which 
sucks.


 2. Read the "deps.txt" file and pass all files to dmd

 OR a programmer specifies all of it manually, which is a 
 complete nightmare
 to maintain on large projects.


 I completely agree.


 Now, if things were designed correctly, I
 don't see why a semi-automated build, using internally 
 specified build
 options for manual tweaking where needed, cannot be done with 
 an
 embedded build system.


 If it was designed correctly the compiler would be built as a 
 library. The build tool could the use this library to get all 
 the dependencies of a given source file.


No doubt the compiler should be a library. Why isn't it? If it 
was a library, then perhaps it could use itself in some very 
interesting ways. The compiler should also accept plugins for 
extensibility. I have not looked at the code yet, but I suspect 
what we have under the hood will make me want to cry.


 Another analogy is to think about languages that have embedded
 reflection - unfortunately D currently lacks a generalized 
 solution for
 reflection, but you can see hints of the potential it offers.
 Simplifying how builds are performed through "reflection" will 
 increase
 productivity, and will potentially offer new ways of solving 
 old
 problems well past what was considered possible before.


 Do you have any example?


If there's information inside the source, then the compiler could 
use that information during a build. A very simple example of 
this, would be the imports. So instead of manually dumping a deps 
file, and working some build script magic, the compiler could 
have that information available internally, thereby saving the 
programmer from hacking away at an external build script to get 
it. My guess that's the least of the advantages, there's probably 
a lot more that could be done.

To me, building is just an ugly hack and patch process caused by 
a broken system that is unable to build itself. It's a total 
mess. The best place to fix the problem is right at the source.

--rt



 Nov 30 2012



 next sibling parent  "Dan" <dbdavidson yahoo.com>  writes:


On Friday, 30 November 2012 at 17:12:10 UTC, Rob T wrote:

 On Friday, 30 November 2012 at 08:05:25 UTC, Jacob Carlborg 
 wrote:

 That's the exact same thing as I'm proposing, except it's the 
 compiler handling it.


 Which would be better because it is integrated and not an 
 external tool.


Why would it be better and why would you care one way or the 
other? Some people are pointing out that integration of features 
related to code, but that are not actual code is not necessarily 
desirable (e.g. comment processing). Many of us use git, so why 
don't we have dmd do our diffs against the git repository for us 
as well? Hyperbole, but what happened to the single 
responsibility principle? Let the compiler do its thing, compile 
- but let a more knowledgeable entity than the source give it its 
flags.

What I don't understand is how the writer of source would know 
how it is to be built everywhere and in every way a client might 
want it. They probably wouldn't - so leave the description of 
that out of the source entirely.

When rdmd does work for the simple case, you would not complain: 
well this stinks having to type rdmd instead of dmd. No, you'd 
use it and be happy with its simplicity. Lack of integration into 
dmd has not hurt at all. It does not satisfy all cases - but it 
seems it adds great value without disrupting dmd. Why wouldn't a 
more complex build system want the same thing?

[snip]

 No doubt the compiler should be a library. Why isn't it?


20/20 hindsight maybe.


 If it was a library, then perhaps it could use itself in some 
 very interesting ways. The compiler should also accept plugins 
 for extensibility. I have not looked at the code yet, but I 
 suspect what we have under the hood will make me want to cry.


The beauty of encapsulation ... don't look.


 To me, building is just an ugly hack and patch process caused 
 by a broken system that is unable to build itself. It's a total 
 mess. The best place to fix the problem is right at the source.


I don't think it is that bad at all - but then I'm using rdmd for 
everything for now. And I agree that the best place to fix the 
problem is right at the source... the problem is which source. I 
would say the build source, not the D source as they serve 
different purposes. Right now we don't have standard build source 
is the issue and it sounds like you are advocating the two go 
together.



 Nov 30 2012



prev sibling next sibling parent reply "jerro" <a a.com>  writes:


 In any event, I'd ask how do the current build systems do it? 
 They read
 and parse through the source files to learn about dependencies


 No, they:

 1. Run "$ dmd -o- -c main.d -deps=deps.txt" which will write 
 out all dependencies of "main.d" to "deps.txt"


 Personally, I don't see how that would work using the current 
 form of the output. I tried it with Make to figure out 
 dependencies and the problem I immediately ran into was that 
 the output did not contain full path information for the 
 projects modules, and without that information, there was no 
 way to combine builds from related project under a separate 
 folder.


It's easy to work around that. It's certainly orders of magnitude 
easier than parsing the source files. Besides, parsing them isn't 
even enough because imports can be inside static if blocks or 
templates. You need pretty much an entire D frontend to correctly 
find dependencies from source files.



 Nov 30 2012



  parent reply "Rob T" <rob ucora.com>  writes:


On Friday, 30 November 2012 at 17:59:23 UTC, jerro wrote:

 It's easy to work around that. It's certainly orders of 
 magnitude easier than parsing the source files. Besides, 
 parsing them isn't even enough because imports can be inside 
 static if blocks or templates. You need pretty much an entire D 
 frontend to correctly find dependencies from source files.


It may be easy, but it's not obvious, which makes it hard. That's 
the problem with external builds.

You make a very good point about the static ifs and so on, which 
means the best place to get that kind of information is directly 
from the compiler during the build process, but why assume that 
the compiler can only partly build rather than perform full 
builds, including an installation?

It just seems like a good idea to use D as the build language 
rather than something else.



 Nov 30 2012



 next sibling parent reply "jerro" <a a.com>  writes:


On Friday, 30 November 2012 at 19:16:56 UTC, Rob T wrote:

 On Friday, 30 November 2012 at 17:59:23 UTC, jerro wrote:

 It's easy to work around that. It's certainly orders of 
 magnitude easier than parsing the source files. Besides, 
 parsing them isn't even enough because imports can be inside 
 static if blocks or templates. You need pretty much an entire 
 D frontend to correctly find dependencies from source files.


 It may be easy, but it's not obvious, which makes it hard. 
 That's the problem with external builds.


If you are writing a build tool, I don't imagine writing those 
few extra lines to convert relative paths to absolute would be a 
problem.


 You make a very good point about the static ifs and so on, 
 which means the best place to get that kind of information is 
 directly from the compiler during the build process


And you already can get that info from the compiler using -deps 
flag.



 Nov 30 2012



  parent reply "Rob T" <rob ucora.com>  writes:


On Friday, 30 November 2012 at 19:35:38 UTC, jerro wrote:

 If you are writing a build tool, I don't imagine writing those 
 few extra lines to convert relative paths to absolute would be 
 a problem.


How does the script know what is a relative path and what is not? 
It's not that easy, and the programmer should not have to be 
fooling around solving non-productive problems like this.


 You make a very good point about the static ifs and so on, 
 which means the best place to get that kind of information is 
 directly from the compiler during the build process


 And you already can get that info from the compiler using -deps 
 flag.


But it does not supply enough information and the -deps thing 
externalizes the build process, which only supports the 
externalized build mess. The whole thing was designed based on 
using an external build process, but I don't think it has to be 
done in that way.



 Nov 30 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-30 21:02, Rob T wrote:

 On Friday, 30 November 2012 at 19:35:38 UTC, jerro wrote:

 If you are writing a build tool, I don't imagine writing those few
 extra lines to convert relative paths to absolute would be a problem.


 How does the script know what is a relative path and what is not? It's
 not that easy, and the programmer should not have to be fooling around
 solving non-productive problems like this.


The -deps output contains the full path for all source files, or is the 
something I'm missing here?

-- 
/Jacob Carlborg



 Dec 01 2012



  parent reply "Rob T" <rob ucora.com>  writes:


On Saturday, 1 December 2012 at 13:19:45 UTC, Jacob Carlborg 
wrote:

 The -deps output contains the full path for all source files, 
 or is the something I'm missing here?


When I use -deps, I do get full path for everything except for my 
own code, which only shows the path relative to where dmd is 
being run, so there's no easy way to determine what is a relative 
path  and what is a full path.

However, I just had a thought to try using -I./src (specify ./ 
for local project source folder) and in that case I can at least 
determine which paths are relative paths, so maybe I can use that 
to replace the ./ with a full path.

BTW, I somehow missed the -od option, and although I'm having 
some linker issues to sort out, it seems that it will do exactly 
what I want. It may be almost possible to completely do away with 
a script, at least for some builds, but is there a way to specify 
a final installation folder, or will a script be required for 
that?

Thanks for the input, I'm still learning something new about D 
every day.

--rt



 Dec 01 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-12-01 23:21, Rob T wrote:

 On Saturday, 1 December 2012 at 13:19:45 UTC, Jacob Carlborg wrote:

 The -deps output contains the full path for all source files, or is
 the something I'm missing here?


 When I use -deps, I do get full path for everything except for my own
 code, which only shows the path relative to where dmd is being run, so
 there's no easy way to determine what is a relative path  and what is a
 full path.


Aha, I didn't notice that. I don't understand why it would be hard to 
determine if a path is relative or not, just use std.path.isAbsolute.


 BTW, I somehow missed the -od option, and although I'm having some
 linker issues to sort out, it seems that it will do exactly what I want.
 It may be almost possible to completely do away with a script, at least
 for some builds, but is there a way to specify a final installation
 folder, or will a script be required for that?

 Thanks for the input, I'm still learning something new about D every day.


The only option the compiler is giving you is the -of flag. It will 
place the resulting binary in the path given with the -of flag.

-- 
/Jacob Carlborg



 Dec 02 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-30 20:16, Rob T wrote:


 It just seems like a good idea to use D as the build language rather
 than something else.


You can do that with an external build tool as well.

-- 
/Jacob Carlborg



 Dec 01 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-30 18:12, Rob T wrote:


 Personally, I don't see how that would work using the current form of
 the output. I tried it with Make to figure out dependencies and the
 problem I immediately ran into was that the output did not contain full
 path information for the projects modules, and without that information,
 there was no way to combine builds from related project under a separate
 folder. What I find, is that with D, people seem to be building in
 simple ways, everything under one folder. This works perhaps for many
 people, but not for everyone. Currently I want send all build output to
 a separate folder outside my project folder onto a separate drive, but I
 can't do something even that simple. Sure I can hack it with perhaps a
 symbolic, but that's a hack which sucks.


That command will output the full path to the source files. Am I missing 
something?

Example of output: http://pastebin.com/mCWGHyn7

When you say "build output" are you referring to the object files? In 
that cases these flags are available:

   -odobjdir      write object & library files to directory objdir
   -offilename    name output file to filename



 No doubt the compiler should be a library. Why isn't it?


I don't know. The compiler is fairly old, especially the backend.


 If it was a
 library, then perhaps it could use itself in some very interesting ways.


Yes, perhaps for CTFE, instead of embedding an interpreter.


 The compiler should also accept plugins for extensibility.


Absolutely, that would be nice.


 I have not
 looked at the code yet, but I suspect what we have under the hood will
 make me want to cry.


Don't look, personally I think the code look horrible.


 If there's information inside the source, then the compiler could use
 that information during a build. A very simple example of this, would be
 the imports. So instead of manually dumping a deps file, and working
 some build script magic, the compiler could have that information
 available internally, thereby saving the programmer from hacking away at
 an external build script to get it. My guess that's the least of the
 advantages, there's probably a lot more that could be done.


The compiler do have all the knowledge about which source files a build 
depends on, that's why we can get the output using the -deps flag. It 
just don't compile the source files unless you explicitly tell it to.


-- 
/Jacob Carlborg



 Dec 01 2012



prev sibling  parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


11/30/2012 12:05 PM, Jacob Carlborg пишет:

 On 2012-11-29 23:06, Rob T wrote:


 For the moment, let's talk about ddoc, or unit testing in D. That's the
 difference, it's not an external tool set, it's instead a a part of the
 standard language feature set. BTW, IMO ddoc was implemented poorly,
 using comments, which I fully agree with you would be a vary bad way to
 go about implementing the feature. In that case, I would rather use Ruby.


 The built-in support for unit testing is too simplistic. I think one
 needs an external tool anyway that makes use of the built-in support
 unit tests.

 I just want to be able to do something like:

 $ test a.d b.d

 And it will run all unit tests in the modules "a" and "b". In D I need
 to manually creating a test module which imports all modules I want to
 test.


AFAIK you don't need to import module to run its tests. So
    rdmd --main -unittest a.d b.d
should work.

Then we should also be able to make rdmd more extendable. There is e.g. 
quite interesting --eval switch but I feel it could be something more 
customizable w/o a lot of extra work.


This will give the most basic functionality. This is a few things
 of that's missing:

 * Run a single test
 * Names or context for the tests
 * Nice report of which tests failed
 * Continue running other tests if a given test failed


-- 
Dmitry Olshansky



 Nov 30 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-30 19:36, Dmitry Olshansky wrote:


 AFAIK you don't need to import module to run its tests. So
     rdmd --main -unittest a.d b.d
 should work.


RDMD is the external tool that I was talking about. Which is fixing some 
of the problems I was talking about.


 Then we should also be able to make rdmd more extendable. There is e.g.
 quite interesting --eval switch but I feel it could be something more
 customizable w/o a lot of extra work.


RDMD should be built as a library as well.

-- 
/Jacob Carlborg



 Dec 01 2012



  parent reply "Rob T" <rob ucora.com>  writes:


On Saturday, 1 December 2012 at 13:18:04 UTC, Jacob Carlborg 
wrote:

 On 2012-11-30 19:36, Dmitry Olshansky wrote:


 AFAIK you don't need to import module to run its tests. So
    rdmd --main -unittest a.d b.d
 should work.


 RDMD is the external tool that I was talking about. Which is 
 fixing some of the problems I was talking about.


 Then we should also be able to make rdmd more extendable. 
 There is e.g.
 quite interesting --eval switch but I feel it could be 
 something more
 customizable w/o a lot of extra work.


 RDMD should be built as a library as well.


I have to agree, rdmd should be a library.

It's entirely possible that the very best way around the build 
issue (and likely many other issues as well), is through an 
extensible library format for the compiler, transforming it in to 
an embeddable tool that even itself can use.

As you know, D interacts very poorly with the concepts of 
extensible libraries, for example, druntime is not even position 
independent, so it seems the advantages of library use was not in 
the mind set when D was first created. Imagine where this can be 
taken!

We really need a generally agreed on official road map for all 
the devs to follow. What I've seen so far focuses far too much on 
the language feature set alone, but the tools are a significant 
component of any language, so that part should not be taken so 
lightly. Time to change that mindset, somehow.

--rt



 Dec 01 2012



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2012-12-01 22:32, Rob T wrote:


 I have to agree, rdmd should be a library.

 It's entirely possible that the very best way around the build issue
 (and likely many other issues as well), is through an extensible library
 format for the compiler, transforming it in to an embeddable tool that
 even itself can use.

 As you know, D interacts very poorly with the concepts of extensible
 libraries, for example, druntime is not even position independent, so it
 seems the advantages of library use was not in the mind set when D was
 first created. Imagine where this can be taken!


Yeah, but you can get pretty far with static libraries. Instead of the 
build tool running the compiler to determine the dependencies a library 
could provide that functionality. Preferably the compiler should be 
built around the same library.


 We really need a generally agreed on official road map for all the devs
 to follow. What I've seen so far focuses far too much on the language
 feature set alone, but the tools are a significant component of any
 language, so that part should not be taken so lightly. Time to change
 that mindset, somehow.


I absolutely agree.

-- 
/Jacob Carlborg



 Dec 02 2012



prev sibling  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 12/1/12, Rob T <rob ucora.com> wrote:

 On Saturday, 1 December 2012 at 13:18:04 UTC, Jacob Carlborg
 wrote:

 RDMD should be built as a library as well.


 I have to agree, rdmd should be a library.


RDMD is 700 lines, it practically is a library with the main function
as its driver.



 Dec 02 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-12-02 17:49, Andrej Mitrovic wrote:


 RDMD is 700 lines, it practically is a library with the main function
 as its driver.


If a piece of code is a library or not has nothing to do with how many 
lines of code there is. The main function is almost 200 lines of code, 
way to much logic for a main function. Most functions and variables are 
private. I haven't look any more thoroughly than that.

-- 
/Jacob Carlborg



 Dec 02 2012



prev sibling  parent reply "Tavi Cacina" <octavian.cacina outlook.com>  writes:


On Thursday, 29 November 2012 at 20:47:49 UTC, Jacob Carlborg 
wrote:

 What's the difference compared to any other build tool. Where 
 you have to learn some kind of special syntax. This is a 
 special syntax as well, just happens to be a real language as 
 well.


In D could be quite elegant. Here a simplified sample how I think 
it could look like:

-----------------------
// Builder Library
module dlang.builder;

struct Target
{
     string output;
     string[] source;
     string[] libs;
}

alias Target Executable;

alias Target StaticLib;

struct Environment
{
     bool tests = false;
     bool verbose = false;
     string[] importDirs;
}

mixin template Builder()
{
     int main(string[] args)
     {
         // enumerate and build the targets...
     }
}

-----------------------
// build.d in project folder


import dlang.builder;

// version(X) to differentiate
Environment env = {
     tests: true,
     verbose: true,
     importDirs: ["../deimos"]
}

Executable myapp = {
     output: "myapp.exe",
     source: ["app/a.d", "app/b.d"],
     libs: ["libutil"]
}

StaticLib libutil = {
     source: ["util/*.d"]
}

mixin Builder;

------------------------
invocation would be basically rdmd build.d

./build.d --variant=release --toolset=dmd_2_060





 Nov 30 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-30 09:19, Tavi Cacina wrote:


 // version(X) to differentiate
 Environment env = {
      tests: true,
      verbose: true,
      importDirs: ["../deimos"]
 }


That's quite a clever syntax, but you forgot the trailing semicolon and 
isn't that syntax intended to be deprecated? It's also quite limiting, 
it would be nice to be able to execute arbitrary code for a given target.

-- 
/Jacob Carlborg



 Nov 30 2012



prev sibling  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


That's my point. :-) This is basically about making the concept of a "build
system for D" useless, due to D code being inherently capable of building
itself.


On Thu, Nov 29, 2012 at 5:55 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/29/12 2:36 AM, Jacob Carlborg wrote:


 On 2012-11-28 22:24, 1100110 wrote:

  Of course. I just can't remember the last time I needed something more

 complex than a shell script. It would be *really* nice if the syntax
 were nice and simple. Makefiles kick my  $$. Implicit rules, and all
 that.


 I'm just trying to stop you guys from investing in a new build system
 that cannot be used for the whole community.

 In most cases I also just need a shell script containing some
 compile/link flags. But what I don't like is that I need to duplicate
 the shell script, one version for Posix and one version for Windows.
 That's why I'm advocating for using build scripts written in a full blow
 language that already exists and works cross platform.


 Why not use D for that full-blown language? I know you insist on using
 Ruby, and I fail to grasp why we'd have D users learn Ruby in addition to
 D, when D is presumably already installed (since this is all about building
 D programs!) and D is as convenient for build scripting as Ruby.

 Andrei




-- 
Bye,
Gor Gyolchanyan.



 Nov 29 2012



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/29/12 9:04 AM, Gor Gyolchanyan wrote:

 That's my point. :-) This is basically about making the concept of a
 "build system for D" useless, due to D code being inherently capable of
 building itself.


Getting the joke but not the point (if present).

Andrei



 Nov 29 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 15:04, Gor Gyolchanyan wrote:

 That's my point. :-) This is basically about making the concept of a
 "build system for D" useless, due to D code being inherently capable of
 building itself.


You will always need to be able to specify various link/compile flags.

-- 
/Jacob Carlborg



 Nov 29 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


Sure, but that will be part of the code, so there will still be no build
system, because the compiler will be able read the build info from the
source.


On Thu, Nov 29, 2012 at 7:20 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-29 15:04, Gor Gyolchanyan wrote:


 That's my point. :-) This is basically about making the concept of a
 "build system for D" useless, due to D code being inherently capable of
 building itself.


 You will always need to be able to specify various link/compile flags.

 --
 /Jacob Carlborg




-- 
Bye,
Gor Gyolchanyan.



 Nov 29 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 16:27, Gor Gyolchanyan wrote:

 Sure, but that will be part of the code, so there will still be no build
 system, because the compiler will be able read the build info from the
 source.


For the 10th time, how will it handle import paths?

-- 
/Jacob Carlborg



 Nov 29 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/29/12 3:48 PM, Jacob Carlborg wrote:

 On 2012-11-29 16:27, Gor Gyolchanyan wrote:

 Sure, but that will be part of the code, so there will still be no build
 system, because the compiler will be able read the build info from the
 source.


 For the 10th time, how will it handle import paths?


Actually I figured it out - rdmd can simply read its own file argument 
and look at the shebang line. Then there's no more issue of space 
coalescing, line length limitations etc.

Andrei



 Nov 29 2012



 next sibling parent  eskimo <jfanatiker gmx.at>  writes:


 Actually I figured it out - rdmd can simply read its own file argument 
 and look at the shebang line. Then there's no more issue of space 
 coalescing, line length limitations etc.


Smart! :-)



 Nov 29 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-29 22:46, Andrei Alexandrescu wrote:


 Actually I figured it out - rdmd can simply read its own file argument
 and look at the shebang line. Then there's no more issue of space
 coalescing, line length limitations etc.


I don't know if you intended to answer to my post but having a separate 
build system is no problem. What Gor suggested was having the build 
system in the compiler, that will cause problems.

-- 
/Jacob Carlborg



 Nov 30 2012



prev sibling next sibling parent reply Robert <jfanatiker gmx.at>  writes:


         
                 On 2012-11-27 08:13, Gor Gyolchanyan wrote:
                         I'd recommend RDMD. It can compile (and run)
                         the given module and it's
                         entire import tree. No build scripts are
                         necessary.
                         Very convenient with pragma(lib, "...")


Btw. if you you use rdmd via sha-bang, there is no way of passing any

http://en.wikipedia.org/wiki/Shebang_%28Unix%29

Is there any way of adding compiler flags like -I paths or something in
the source file for rdmd? Much like pragma(lib, "")? This would be
really useful for "scripts" that need more than just the standard
library.

Thanks!

Best regards,

Robert



 Nov 27 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/27/12 5:44 AM, Robert wrote:

                  On 2012-11-27 08:13, Gor Gyolchanyan wrote:
                          I'd recommend RDMD. It can compile (and run)
                          the given module and it's
                          entire import tree. No build scripts are
                          necessary.
                          Very convenient with pragma(lib, "...")


 Btw. if you you use rdmd via sha-bang, there is no way of passing any

 http://en.wikipedia.org/wiki/Shebang_%28Unix%29


Thats why I included the --shebang flag in rdmd.

Andrei



 Nov 27 2012



  parent  Robert <jfanatiker gmx.at>  writes:


On Tue, 2012-11-27 at 10:51 -0500, Andrei Alexandrescu wrote:

 Thats why I included the --shebang flag in rdmd.
 
 


Thanks a lot! That is very very nice. I wasn't aware of this because I
relied on the very outdated man page, instead on rdmd -h. Wow rdmd is
far more powerful now :-)



 Nov 27 2012



prev sibling  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


I don't think RDMD reads any more, then the shabang and import statements.
Although (as I wrote in a previous post in this thread) I think having a
build tool that relies exclusively on the source files would be very
convenient.


On Tue, Nov 27, 2012 at 2:44 PM, Robert <jfanatiker gmx.at> wrote:


                 On 2012-11-27 08:13, Gor Gyolchanyan wrote:
                         I'd recommend RDMD. It can compile (and run)
                         the given module and it's
                         entire import tree. No build scripts are
                         necessary.
                         Very convenient with pragma(lib, "...")


 Btw. if you you use rdmd via sha-bang, there is no way of passing any

 http://en.wikipedia.org/wiki/Shebang_%28Unix%29

 Is there any way of adding compiler flags like -I paths or something in
 the source file for rdmd? Much like pragma(lib, "")? This would be
 really useful for "scripts" that need more than just the standard
 library.

 Thanks!

 Best regards,

 Robert



-- 
Bye,
Gor Gyolchanyan.



 Nov 27 2012