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
next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--bcaec54fb9c6b479c404cf7365ac
Content-Type: text/plain; charset=UTF-8

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. --bcaec54fb9c6b479c404cf7365ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AFAIK, dsss is very old and designed for D1.<div class=3D"gmail_extra"><br>= <br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 4:53 AM, Daren Scot = Wilson <span dir=3D"ltr">&lt;<a href=3D"mailto:darenw darenscotwilson.com" = target=3D"_blank">darenw darenscotwilson.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">I&#39;m trying to compile DSSS from the curr= ent svn trunk. =C2=A0My info is from <a href=3D"http://www.dsource.org/proj= ects/dsss" target=3D"_blank">http://www.dsource.org/<u></u>projects/dsss</a=
 =C2=A0 The build gets stuck, spewing many errors. =C2=A0 Note that I&#39;=

be back later with those kinds of questions.) =C2=A0 I&#39;m using 64-bit = Linux (Ubuntu) using dmd<br> DMD64 D Compiler v2.056<br> <br> <br> The command to build<br> make -f Makefile.dmd.posix<br> <br> <br> The part of the build output around where the errors start is this:<br> <br> g++ -g =C2=A0nchoosedc.o nwhereami.o -o choosedc<br> ./choosedc<br> Ignore any error from GDC or DMD in the following lines.<br> /usr/local/src/DSSS/src-co/<u></u>trunk/rebuild/./testtango.d(3)<u></u>: Er= ror: function testtango.A.toUtf8 does not override any function<br> make[1]: Leaving directory `/usr/local/src/DSSS/src-co/<u></u>trunk/rebuild= &#39;<br> cp -f rebuild/defaults/dmd-posix rebuild/rebuild.conf/default<br> ./rebuild/rebuild -full -Irebuild sss/main.d -ofdsss<br> hcf/path.d(88): octal literals 0100 are deprecated, use std.conv.octal!100 = instead<br> rebuild/util/booltype.d(364): Error: function util.booltype.Bool.toString o= f type char[]() overrides but is not covariant with object.Object.toString = of type string()<br> hcf/path.d(88): octal literals 0100 are deprecated, use std.conv.octal!100 = instead<br> rebuild/util/linetoken.d(50): Error: cannot implicitly convert expression (= &quot;,&quot;) of type string to char[]<br> rebuild/util/linetoken.d(50): Error: cannot implicitly convert expression (= &quot;//&quot;) of type string to char[]<br> rebuild/util/linetoken.d(50): Error: cannot implicitly convert expression (= &quot;\\&quot;) of type string to char[]<br> <br> <br> After all the &quot;cannot implicitly convert&quot; errors there are severa= l like this:<br> <br> hcf/path.d(88): octal literals 0100 are deprecated, use std.conv.octal!100 = instead<br> <br> <br> svn info says:<br> <br> Path: .<br> URL: <a href=3D"http://svn.dsource.org/projects/dsss/trunk" target=3D"_blan= k">http://svn.dsource.org/<u></u>projects/dsss/trunk</a><br> Repository Root: <a href=3D"http://svn.dsource.org/projects/dsss" target=3D= "_blank">http://svn.dsource.org/<u></u>projects/dsss</a><br> Repository UUID: 2894d018-631f-0410-8ed0-<u></u>857076f880b1<br> Revision: 945<br> Node Kind: directory<br> Schedule: normal<br> Last Changed Author: Gregor<br> Last Changed Rev: 945<br> Last Changed Date: 2009-04-17 10:26:11 -0700 (Fri, 17 Apr 2009)<br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --bcaec54fb9c6b479c404cf7365ac--
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 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
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 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 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 next 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 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 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: #!/usr/bin/rdmd /**rdmdoptions -L-lmylib */ ... What would be some useful options to add, aside from those already supported? Andrei
Nov 27 2012
next sibling parent 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
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:

 #!/usr/bin/rdmd
 /**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:

 #!/usr/bin/rdmd
 /**rdmdoptions
 -L-lmylib
 */
 ...

There's gotta be a better syntax than that!

I think so too. Ideas? Andrei
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
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? #!/usr/bin/rdmd -L-lmylib

Yeah and so would pragma(lib). But only for that specific case. =P shebang only takes one (1) argument.
Nov 28 2012
prev sibling next 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:

 #!/usr/bin/rdmd
 /**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 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:

 #!/usr/bin/rdmd
 /**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 # some code 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) : # Build script in Ruby 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) :

 # Build script in Ruby

 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:

 # Build script in Ruby

 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 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 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 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
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 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 next 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 next 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 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 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 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 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 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
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 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 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:

 #!/usr/bin/rdmd
 /**rdmdoptions
 -L-lmylib
 */
 ...

#!/usr/bin/rdmd ("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
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 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 compiler flags in the #! line (because only a single arg is supported: http://en.wikipedia.org/wiki/Shebang_%28Unix%29

Thats why I included the --shebang flag in rdmd. Andrei
Nov 27 2012
prev sibling next sibling parent "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
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--90e6ba308eba47c25f04cf74ca35
Content-Type: text/plain; charset=UTF-8

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. --90e6ba308eba47c25f04cf74ca35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I&#39;d recommend RDMD. It can compile (and run) the given module and it&#3= 9;s entire import tree. No build scripts are necessary.<div>Very convenient= with pragma(lib, &quot;...&quot;)</div><div class=3D"gmail_extra"><br><br> <div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 9:55 AM, Daren Scot Wils= on <span dir=3D"ltr">&lt;<a href=3D"mailto:darenw darenscotwilson.com" targ= et=3D"_blank">darenw darenscotwilson.com</a>&gt;</span> wrote:<br><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"> <div class=3D"im">On Tuesday, 27 November 2012 at 05:34:14 UTC, Gor Gyolcha= nyan wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> AFAIK, dsss is very old and designed for D1.<br> <br> <br> On Tue, Nov 27, 2012 at 4:53 AM, Daren Scot Wilson &lt;<br> <a href=3D"mailto:darenw darenscotwilson.com" target=3D"_blank">darenw dare= nscotwilson.com</a>&gt; wrote:<br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> I&#39;m trying to compile DSSS from the current svn trunk. =C2=A0My info is= from<br> </div><a href=3D"http://www.dsource.org/**projects/dsss" target=3D"_blank">= http://www.dsource.org/**<u></u>projects/dsss</a>&lt;<a href=3D"http://www.= dsource.org/projects/dsss" target=3D"_blank">http://www.<u></u>dsource.org/= projects/dsss</a>&gt;<div class=3D"im"> <br> =C2=A0The build gets stuck, spewing many errors. =C2=A0 Note that I&#39;m t= rying to<br> build DSSS itself, not use DSSS to build something else.<br> </div></blockquote></blockquote> <br> <br> Ah. =C2=A0So then, what is the currently fashionable build system in the D = world?<br> <br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --90e6ba308eba47c25f04cf74ca35--
Nov 26 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--485b390f7a168a791704cf75382d
Content-Type: text/plain; charset=UTF-8

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. --485b390f7a168a791704cf75382d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 variabl= es.<div class=3D"gmail_extra"> <br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 11:38 AM, Jacob = Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_bl= ank">doob me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-11-27 08:13, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;d recommend RDMD. It can compile (and run) the given module and it&#3= 9;s<br> entire import tree. No build scripts are necessary.<br> Very convenient with pragma(lib, &quot;...&quot;)<br> </blockquote> <br></div> RDMD is quite good for compiling executables. It won&#39;t work for compili= ng libraries. Quite often a build script is needed to avoid repeating the s= ame compiler/linker flags over and over again.<span class=3D"HOEnZb"><font = color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --485b390f7a168a791704cf75382d--
Nov 26 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d04016ab74bf5d204cf7542b9
Content-Type: text/plain; charset=UTF-8

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. --f46d04016ab74bf5d204cf7542b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just like DDOC adds=C2=A0auxiliary=C2=A0information to create documentation= , build comments would add=C2=A0auxiliary=C2=A0information to create build = scripts (which a tool could just use right away without generating garbage = in the form of build script files).<div class=3D"gmail_extra"> <br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 11:44 AM, Gor Gy= olchanyan <span dir=3D"ltr">&lt;<a href=3D"mailto:gor.f.gyolchanyan gmail.c= om" target=3D"_blank">gor.f.gyolchanyan gmail.com</a>&gt;</span> wrote:<br>= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 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 variabl= es.<div class=3D"gmail_extra"> <div><div class=3D"h5"> <br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 11:38 AM, Jacob = Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_bl= ank">doob me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On 2012-11-27 08:13, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;d recommend RDMD. It can compile (and run) the given module and it&#3= 9;s<br> entire import tree. No build scripts are necessary.<br> Very convenient with pragma(lib, &quot;...&quot;)<br> </blockquote> <br></div> RDMD is quite good for compiling executables. It won&#39;t work for compili= ng libraries. Quite often a build script is needed to avoid repeating the s= ame compiler/linker flags over and over again.<span><font color=3D"#888888"=
<br>

<br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div></div=
</div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br>Bye,<br>Gor Gy=

</font></span></div> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --f46d04016ab74bf5d204cf7542b9--
Nov 26 2012
prev sibling next sibling parent 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 compiler flags in the #! line (because only a single arg is supported: 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
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--e0cb4efe2f4e7619c504cf77d100
Content-Type: text/plain; charset=UTF-8

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 compiler flags in the #! line (because only a single arg is supported: 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. --e0cb4efe2f4e7619c504cf77d100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don&#39;t think RDMD reads any more, then the shabang and import statemen= ts. 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 conv= enient.<div class=3D"gmail_extra"> <br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 2:44 PM, Robert = <span dir=3D"ltr">&lt;<a href=3D"mailto:jfanatiker gmx.at" target=3D"_blank= ">jfanatiker gmx.at</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=

&gt;<br> &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2012-11-27 = 08:13, Gor Gyolchanyan wrote:<br> &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 I&#39;d recommend RDMD. It can compile (and run)<br> &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 the given module and it&#39;s<br> &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 entire import tree. No build scripts are<br> &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 necessary.<br> &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Very convenient with pragma(lib, &quot;...&quot;)<br> <br> </div>Btw. if you you use rdmd via sha-bang, there is no way of passing any= <br> compiler flags in the #! line (because only a single arg is supported:<br> <a href=3D"http://en.wikipedia.org/wiki/Shebang_%28Unix%29" target=3D"_blan= k">http://en.wikipedia.org/wiki/Shebang_%28Unix%29</a><br> <br> Is there any way of adding compiler flags like -I paths or something in<br> the source file for rdmd? Much like pragma(lib, &quot;&quot;)? This would b= e<br> really useful for &quot;scripts&quot; that need more than just the standard= <br> library.<br> <br> Thanks!<br> <br> Best regards,<br> <br> Robert<br> <br> <br> <br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --e0cb4efe2f4e7619c504cf77d100--
Nov 27 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0407166d1b2d3e04cf79496d
Content-Type: text/plain; charset=UTF-8

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. --f46d0407166d1b2d3e04cf79496d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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&#39;s DDOC and not external tool.<div class=3D"gmail_= extra"> <br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 4:24 PM, Jacob C= arlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_bla= nk">doob me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-11-27 08:47, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Just like DDOC adds auxiliary information to create documentation, build<br=

a tool could just use right away without generating garbage in the form<br> of build script files).<br> </blockquote> <br></div> These special comments would just be the build script. I see no advantage o= f 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.<br> <br> 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 assur= e you, there&#39;s no point in trying to invent a new &quot;language&quot; = for these kind of things.<span class=3D"HOEnZb"><font color=3D"#888888"><br=

<br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d0407166d1b2d3e04cf79496d--
Nov 27 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--14dae9d717bc8f309104cf797df3
Content-Type: text/plain; charset=UTF-8

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. --14dae9d717bc8f309104cf797df3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There&#39;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 th= at the source code is where the necessary building conditions are defined, = even if as a separate file. You can&#39;t write anything more, then a 100 L= OC 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&#39;t see any reason why building process should be separ= ated from the=C2=A0source code.<div class=3D"gmail_extra"> <br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 4:42 PM, Jacob C= arlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_bla= nk">doob me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-11-27 13:35, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The benefit is standardization. There will no longer be an annoying mess<br=


</blockquote> <br></div> I don&#39;t think it&#39;s right to add a build tool to the compiler. There= can be a standard built tool even if it&#39;s not in the compiler.<span cl= ass=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --14dae9d717bc8f309104cf797df3--
Nov 27 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--047d7b603c1ea5fbcf04cf7c02f6
Content-Type: text/plain; charset=UTF-8

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. --047d7b603c1ea5fbcf04cf7c02f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Why do you think so? The build script is inseparable from the project sourc= e files. What makes the build script necessary to be separate?<div class=3D= "gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Nov 27, 2012 at 7:= 42 PM, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" = target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 2012-11-27 13:50, Gor G= yolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> There&#39;s a good reason why all libraries come with their build scripts,<= br> rather then rely on the client to build them as necessary. The reason is<br=

defined, even if as a separate file. You can&#39;t write anything more, the= n<br> a 100 LOC source file without having to make a build script. The source<br> files in a project heavily depend on the build script to produce the<br> correct result. This is why I don&#39;t see any reason why building process= <br> should be separated from the source code.<br> </blockquote> <br></div> I don&#39;t understand what you&#39;re saying. Of course the build scripts = need to be shipped with the library. I just don&#39;t think you should put = the build script inline with the source code. I think it should be a separa= te file.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --047d7b603c1ea5fbcf04cf7c02f6--
Nov 27 2012
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 #!/usr/bin/rdmd
 /**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
prev sibling next sibling parent "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
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--047d7b6220720f0e4404cf7e907a
Content-Type: text/plain; charset=UTF-8

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. --047d7b6220720f0e4404cf7e907a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I didn&#39;t see a single example of build script usage where it wasn&#39;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&#39;s why I think it&#39;s a good idea to combine them.<div> <br></div><div>As for the question &quot;where to put those comments?&quot;= :</div><div>There was an enhancement issue in bugzilla about allowing modul= es to be named &quot;package&quot; in which case they are imported by their= package name alone. The build comments in those modules would be propagate= d to the entire package and the subpackages would be able to override.</div=

7, 2012 at 9:40 PM, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"ma= ilto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail er= dani.org</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 1= 1/27/12 12:37 PM, jerro wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Providing arbitrary compiler flags would already be a huge gain. So one<br> can pass libs, -I include paths, ...<br> </blockquote> <br> You can already pass -I and -L and they are passed on to DMD (along with<br=

</blockquote> <br></div></div> The advantage would be that you get to wire the options inside the script i= nstead of requiring them in the invocation thereof.<br> <br> Again, --shebang does help there but my experience with it has been terribl= e: 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.<span class=3D"= HOEnZb"><font color=3D"#888888"><br> <br> <br> Andrei<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --047d7b6220720f0e4404cf7e907a--
Nov 27 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Tuesday, 27 November 2012 at 16:04:47 UTC, Andrei Alexandrescu 
wrote:

 #!/usr/bin/rdmd
 /**rdmdoptions
 -L-lmylib
 */
 ...

#!/usr/bin/rdmd ("compiler options", "-L-lmylib") module main; ... Maybe... sorry I don't know if this would work with current UDA.
Nov 27 2012
prev sibling next sibling 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 next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0430855408fd3a04cf90086e
Content-Type: text/plain; charset=UTF-8

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:

 #!/usr/bin/rdmd
 /**rdmdoptions
 -L-lmylib
 */
 ...

There's gotta be a better syntax than that!

I think so too. Ideas? Andrei

-- Bye, Gor Gyolchanyan. --f46d0430855408fd3a04cf90086e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about:<div><br></div><div>//! -L-lmylib</div><div class=3D"gmail_extra"=
<br><br><div class=3D"gmail_quote">On Wed, Nov 28, 2012 at 6:29 PM, Andrei=

dani.org" target=3D"_blank">SeeWebsiteForEmail erdani.org</a>&gt;</span> wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 1= 1/28/12 8:00 AM, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 11/28/2012 3:04 AM, Andrei Alexandrescu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Even with --shebang there are odd limitations of the shebang line length<br=

stylized comment below the shebang line. That comment can be read and<br> parsed by rdmd appropriately. For example:<br> <br> #!/usr/bin/rdmd<br> /**rdmdoptions<br> -L-lmylib<br> */<br> ...<br> </blockquote> <br> There&#39;s gotta be a better syntax than that!<br> </blockquote> <br></div></div> I think so too. Ideas?<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> Andrei<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d0430855408fd3a04cf90086e--
Nov 28 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0407166d4d518804cf902461
Content-Type: text/plain; charset=UTF-8

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:

 #!/usr/bin/rdmd
 /**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. --f46d0407166d4d518804cf902461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that would be a huge mistake. Why would anyone want to invent a ful= l 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?<div class=3D"gmail_= extra"> <br><br><div class=3D"gmail_quote">On Wed, Nov 28, 2012 at 7:48 PM, Jacob C= arlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_bla= nk">doob me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-11-27 17:04, Andrei Alexandrescu wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Even with --shebang there are odd limitations of the shebang line length<br=

stylized comment below the shebang line. That comment can be read and<br> parsed by rdmd appropriately. For example:<br> <br> #!/usr/bin/rdmd<br> /**rdmdoptions<br> -L-lmylib<br> */<br> ...<br> <br> What would be some useful options to add, aside from those already<br> supported?<br> </blockquote> <br></div> I don&#39;t know why anyone would bother implementing this. What&#39;s need= ed is a proper build tool. That includes build scripts that can be written = in a full blow language.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d0407166d4d518804cf902461--
Nov 28 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--e0cb4efe2f4e68f52504cf90e5eb
Content-Type: text/plain; charset=UTF-8

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. --e0cb4efe2f4e68f52504cf90e5eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But not as bad as the &quot;rdmdoptions&quot;.<div><br></div><div>//! line1= </div><div>//! line2</div><div>//! line3</div><div><br></div><div>Doesn&#39= ;t look THAT terrible.</div><div class=3D"gmail_extra"><br><br><div class= =3D"gmail_quote"> On Wed, Nov 28, 2012 at 8:22 PM, Andrei Alexandrescu <span dir=3D"ltr">&lt;= <a href=3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsi= teForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> On 11/28/12 10:43 AM, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> How about:<br> <br> //! -L-lmylib<br> </blockquote> <br> Sux for multiple lines.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> Andrei<br> <br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --e0cb4efe2f4e68f52504cf90e5eb--
Nov 28 2012
prev sibling next sibling parent "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
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d04308554e33bc804cf912079
Content-Type: text/plain; charset=UTF-8

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. --f46d04308554e33bc804cf912079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precisely!<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On = Wed, Nov 28, 2012 at 8:59 PM, jerro <span dir=3D"ltr">&lt;<a href=3D"mailto= :a a.com" target=3D"_blank">a a.com</a>&gt;</span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> <div class=3D"im">On Wednesday, 28 November 2012 at 15:51:50 UTC, Gor Gyolc= hanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I think that would be a huge mistake. Why would anyone want to invent a<br> full blown language and a big pain in the butt just to build a project if<b= r> the project can build itself by looking at the source code?<br> </blockquote> <br></div> The build system could be a library written in D, then you wouldn&#39;t nee= d to invent a new language.<br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --f46d04308554e33bc804cf912079--
Nov 28 2012
prev sibling next sibling parent "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
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--485b390f7a1658294704cf9143d2
Content-Type: text/plain; charset=UTF-8

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?

to invent a new language.


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. --485b390f7a1658294704cf9143d2 Content-Type: text/html; charset=UTF-8 Still better, then a completely separate thing.<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 28, 2012 at 9:09 PM, jerro <span dir="ltr">&lt;<a href="mailto:a a.com" target="_blank">a a.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, 28 November 2012 at 17:02:25 UTC, Gor Gyolchanyan wrote:<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> Precisely!<br> <br> <br> On Wed, Nov 28, 2012 at 8:59 PM, jerro &lt;<a href="mailto:a a.com" target="_blank">a a.com</a>&gt; wrote:<br> <br> </div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wednesday, 28 November 2012 at 15:51:50 UTC, Gor Gyolchanyan wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I think that would be a huge mistake. Why would anyone want to invent a<br> full blown language and a big pain in the butt just to build a project if<br> the project can build itself by looking at the source code?<br> <br> </blockquote> <br> The build system could be a library written in D, then you wouldn&#39;t need<br> to invent a new language.<br> </blockquote></div></div></blockquote> <br> I mean&#39;t writing a D build library and using it to write build scripts separate from the source files that are being build. That&#39;s quite different from embedding build instructions into comments inside the source files.<br> </blockquote></div><br><br clear="all"><div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br> </div> --485b390f7a1658294704cf9143d2--
Nov 28 2012
prev sibling next 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 next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0401240b7c337904cf933f16
Content-Type: text/plain; charset=UTF-8

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:

  #!/usr/bin/rdmd
 /**rdmdoptions
 -L-lmylib
 */
 ...

#!/usr/bin/rdmd ("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. --f46d0401240b7c337904cf933f16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable awesome idea! and that can be put into static if-s and such!!=C2=A0<div cla= ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Nov 28, 2012 = at 11:23 PM, 1100110 <span dir=3D"ltr">&lt;<a href=3D"mailto:0b1100110 gmai= l.com" target=3D"_blank">0b1100110 gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 1= 1/27/2012 02:37 PM, Jesse Phillips wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Tuesday, 27 November 2012 at 16:04:47 UTC, Andrei Alexandrescu wrote:<br=

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> #!/usr/bin/rdmd<br> /**rdmdoptions<br> -L-lmylib<br> */<br> ...<br> </blockquote> <br> #!/usr/bin/rdmd<br> (&quot;compiler options&quot;, &quot;-L-lmylib&quot;) module main;<br> ...<br> <br> Maybe... sorry I don&#39;t know if this would work with current UDA.<br> </blockquote> <br></div></div> pragma(build, &quot;rdmd -Jviews -Isrc/debug --version=3Ddebug&quot;);<br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --f46d0401240b7c337904cf933f16--
Nov 28 2012
prev sibling next sibling parent 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? #!/usr/bin/rdmd -L-lmylib -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 28 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0407166d61050604cfa2c486
Content-Type: text/plain; charset=UTF-8

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. --f46d0407166d61050604cfa2c486 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That&#39;s my point. :-)=C2=A0This is basically about making the concept of= a &quot;build system for D&quot; useless, due to D code being inherently c= apable of building itself.<div class=3D"gmail_extra"><br><br><div class=3D"= gmail_quote"> On Thu, Nov 29, 2012 at 5:55 PM, Andrei Alexandrescu <span dir=3D"ltr">&lt;= <a href=3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsi= teForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> <div class=3D"im">On 11/29/12 2:36 AM, Jacob Carlborg wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 2012-11-28 22:24, 1100110 wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Of course. I just can&#39;t remember the last time I needed something more<= br> complex than a shell script. It would be *really* nice if the syntax<br> were nice and simple. Makefiles kick my $$. Implicit rules, and all<br> that.<br> </blockquote> <br> I&#39;m just trying to stop you guys from investing in a new build system<b= r> that cannot be used for the whole community.<br> <br> In most cases I also just need a shell script containing some<br> compile/link flags. But what I don&#39;t like is that I need to duplicate<b= r> the shell script, one version for Posix and one version for Windows.<br> That&#39;s why I&#39;m advocating for using build scripts written in a full= blow<br> language that already exists and works cross platform.<br> </blockquote> <br></div> Why not use D for that full-blown language? I know you insist on using Ruby= , and I fail to grasp why we&#39;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.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> Andrei<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d0407166d61050604cfa2c486--
Nov 29 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--90e6ba308eba3c918404cfa3ec05
Content-Type: text/plain; charset=UTF-8

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. --90e6ba308eba3c918404cfa3ec05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure, but that will be part of the code, so there will still be no build sy= stem, because the compiler will be able read the build info from the source= .<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Nov = 29, 2012 at 7:20 PM, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailto= :doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 2012-11-29 15:04, Gor G= yolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> That&#39;s my point. :-) This is basically about making the concept of a<br=

ble of<br> building itself.<br> </blockquote> <br></div> You will always need to be able to specify various link/compile flags.<span= class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --90e6ba308eba3c918404cfa3ec05--
Nov 29 2012
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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 #!/usr/bin/env rdmd 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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling parent 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