www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D packages, include directories, and rdmd

reply Andrew Pennebaker <andrew.pennebaker gmail.com> writes:
--bcaec520f1cfb52a8f04b04eda4c
Content-Type: text/plain; charset=ISO-8859-1

I've got a single-file D module,
dashcheck.d<https://github.com/mcandre/dashcheck>,
that I'd like to install as a local package. In other words, I'd like to be
able to "import dashcheck;" from any directory.

I put dashcheck.d in ~/.d/, and I put export DFLAGS=-I~/.d in ~/.profile,
but when I try to run example.d from another directory, I get:

$ ./example.d
./example.d(3): Error: module dashcheck is in file 'dashcheck.d' which
cannot be read
import path[0] = /usr/local/Cellar/dmd/2.051/src/phobos
import path[1] = /usr/local/Cellar/dmd/2.051/src/druntime/importCheers,

It appears that rdmd ignores $DFLAGS.

Also, when I change the shebang in example.d to #!/usr/bin/env rdmd $DFLAGS,
I get:

$ ./example.d
sh: -I~/.d.d.deps: No such file or directory

So I'm not using import directives correctly. How do I generate
dashcheck.d.deps?

Andrew Pennebaker
www.yellosoft.us

--bcaec520f1cfb52a8f04b04eda4c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;ve got a single-file D module, <a href=3D"https://github.com/mcandre/=
dashcheck">dashcheck.d</a>, that I&#39;d like to install as a local package=
. In other words, I&#39;d like to be able to &quot;import dashcheck;&quot; =
from any directory.<br>

<br>I put dashcheck.d in <span style=3D"font-family: courier new,monospace;=
">~/.d/</span>, and I put <span style=3D"font-family: courier new,monospace=
;">export DFLAGS=3D-I~/.d</span> in <span style=3D"font-family: courier new=
,monospace;">~/.profile</span>, but when I try to run example.d from anothe=
r directory, I get:<br>

<br><span style=3D"font-family: courier new,monospace;">$ ./example.d </spa=
n><br style=3D"font-family: courier new,monospace;"><span style=3D"font-fam=
ily: courier new,monospace;">./example.d(3): Error: module dashcheck is in =
file &#39;dashcheck.d&#39; which cannot be read</span><br style=3D"font-fam=
ily: courier new,monospace;">

<span style=3D"font-family: courier new,monospace;">import path[0] =3D /usr=
/local/Cellar/dmd/2.051/src/phobos</span><br style=3D"font-family: courier =
new,monospace;"><span style=3D"font-family: courier new,monospace;">import =
path[1] =3D /usr/local/Cellar/dmd/2.051/src/druntime/importCheers,</span><d=
iv>

<br>It appears that rdmd ignores <span style=3D"font-family: courier new,mo=
nospace;">$DFLAGS</span>.<br><br>Also, when I change the shebang in example=
.d to <span style=3D"font-family: courier new,monospace;">#!/usr/bin/env rd=
md $DFLAGS</span>, I get:<br>

<br><span style=3D"font-family: courier new,monospace;">$ ./example.d </spa=
n><br style=3D"font-family: courier new,monospace;"><span style=3D"font-fam=
ily: courier new,monospace;">sh: -I~/.d.d.deps: No such file or directory</=
span><br>

<br>So I&#39;m not using import directives correctly. How do I generate das=
hcheck.d.deps?<br><br></div><div>Andrew Pennebaker</div><div><a href=3D"htt=
p://www.yellosoft.us" target=3D"_blank">www.yellosoft.us</a></div>

--bcaec520f1cfb52a8f04b04eda4c--
Oct 27 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote in message 
news:mailman.543.1319752640.24802.digitalmars-d puremagic.com...
 I've got a single-file D module,
 dashcheck.d<https://github.com/mcandre/dashcheck>,
 that I'd like to install as a local package. In other words, I'd like to 
 be
 able to "import dashcheck;" from any directory.

 I put dashcheck.d in ~/.d/, and I put export DFLAGS=-I~/.d in ~/.profile,
 but when I try to run example.d from another directory, I get:

 $ ./example.d
 ./example.d(3): Error: module dashcheck is in file 'dashcheck.d' which
 cannot be read
 import path[0] = /usr/local/Cellar/dmd/2.051/src/phobos
 import path[1] = /usr/local/Cellar/dmd/2.051/src/druntime/importCheers,

 It appears that rdmd ignores $DFLAGS.

I guess DFLAGS isn't an env var (which actually surprises me, it probably should be, is there already an enhancement request in bugzilla for that? Is is there some deliberate reason for this?). DFLAGS is normally set in your dmd.conf file (sc.ini on Windows). Do a "which dmd" to see where your dmd binary is, and your dmd.conf will be in the same directory (at least if you used the .zip releases or DVM, I don't know where the distros will put dmd.conf). Another approach that many of us use is to just pass the -Ipath option to dmd or rdmd in your buildscript to tell dmd/rdmd where to look for look for imports (sort of the D counterpart to Java's classpaths).
 Also, when I change the shebang in example.d to #!/usr/bin/env rdmd 
 $DFLAGS,
 I get:

 $ ./example.d
 sh: -I~/.d.d.deps: No such file or directory

 So I'm not using import directives correctly. How do I generate
 dashcheck.d.deps?

Part of the problem here is the same as above, DFLAGS needs to be set in dmd.conf, not an env var. But also, when you use rdmd as a shebang, you should use the --shebang option (always as the first argument), ie: #!/usr/bin/env rdmd --shebang {whatever other options here} Apperently, shebangs tend to mess up the params that get sent to rdmd, and the --shebang makes it use an alternate approach made specifically for that situation.
Oct 27 2011
prev sibling next sibling parent reply Andrew Pennebaker <andrew.pennebaker gmail.com> writes:
--f46d041390f5c1ca9704b04f7e0c
Content-Type: text/plain; charset=ISO-8859-1

In addition, I can't even use a naked -I directive without all the
dmd.conf/DFLAGS stuff.

My module code is in ~/Desktop/src/dashcheck. But even with the -Ipath
directive, dmd still can't find it.

$ dmd example.d -I~/Desktop/src/dashcheck
Undefined symbols for architecture i386:
  "_D9dashcheck12__ModuleInfoZ", referenced from:
      _D7example12__ModuleInfoZ in example.o
  "_D9dashcheck9genStringFZAya", referenced from:
      anon in example.o
  "_D9dashcheck6genIntFZi", referenced from:
      anon in example.o
      _D7example7genEvenFZi in example.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
--- errorlevel 1

Cheers,

Andrew Pennebaker
www.yellosoft.us

On Thu, Oct 27, 2011 at 6:28 PM, Nick Sabalausky <a a.a> wrote:

 "Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote in message
 news:mailman.543.1319752640.24802.digitalmars-d puremagic.com...
 I've got a single-file D module,
 dashcheck.d<https://github.com/mcandre/dashcheck>,
 that I'd like to install as a local package. In other words, I'd like to
 be
 able to "import dashcheck;" from any directory.

 I put dashcheck.d in ~/.d/, and I put export DFLAGS=-I~/.d in ~/.profile,
 but when I try to run example.d from another directory, I get:

 $ ./example.d
 ./example.d(3): Error: module dashcheck is in file 'dashcheck.d' which
 cannot be read
 import path[0] = /usr/local/Cellar/dmd/2.051/src/phobos
 import path[1] = /usr/local/Cellar/dmd/2.051/src/druntime/importCheers,

 It appears that rdmd ignores $DFLAGS.

I guess DFLAGS isn't an env var (which actually surprises me, it probably should be, is there already an enhancement request in bugzilla for that? Is is there some deliberate reason for this?). DFLAGS is normally set in your dmd.conf file (sc.ini on Windows). Do a "which dmd" to see where your dmd binary is, and your dmd.conf will be in the same directory (at least if you used the .zip releases or DVM, I don't know where the distros will put dmd.conf). Another approach that many of us use is to just pass the -Ipath option to dmd or rdmd in your buildscript to tell dmd/rdmd where to look for look for imports (sort of the D counterpart to Java's classpaths).
 Also, when I change the shebang in example.d to #!/usr/bin/env rdmd
 $DFLAGS,
 I get:

 $ ./example.d
 sh: -I~/.d.d.deps: No such file or directory

 So I'm not using import directives correctly. How do I generate
 dashcheck.d.deps?

Part of the problem here is the same as above, DFLAGS needs to be set in dmd.conf, not an env var. But also, when you use rdmd as a shebang, you should use the --shebang option (always as the first argument), ie: #!/usr/bin/env rdmd --shebang {whatever other options here} Apperently, shebangs tend to mess up the params that get sent to rdmd, and the --shebang makes it use an alternate approach made specifically for that situation.

--f46d041390f5c1ca9704b04f7e0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In addition, I can&#39;t even use a naked -I directive without all the dmd.= conf/DFLAGS stuff.<br><br>My module code is in ~/Desktop/src/dashcheck. But= even with the -Ipath directive, dmd still can&#39;t find it.<br><br><span = style=3D"font-family: courier new,monospace;">$ dmd example.d -I~/Desktop/s= rc/dashcheck</span><br style=3D"font-family: courier new,monospace;"> <span style=3D"font-family: courier new,monospace;">Undefined symbols for a= rchitecture i386:</span><br style=3D"font-family: courier new,monospace;"><= span style=3D"font-family: courier new,monospace;">=A0 &quot;_D9dashcheck12= __ModuleInfoZ&quot;, referenced from:</span><br style=3D"font-family: couri= er new,monospace;"> <span style=3D"font-family: courier new,monospace;">=A0=A0=A0=A0=A0 _D7exam= ple12__ModuleInfoZ in example.o</span><br style=3D"font-family: courier new= ,monospace;"><span style=3D"font-family: courier new,monospace;">=A0 &quot;= _D9dashcheck9genStringFZAya&quot;, referenced from:</span><br style=3D"font= -family: courier new,monospace;"> <span style=3D"font-family: courier new,monospace;">=A0=A0=A0=A0=A0 anon in= example.o</span><br style=3D"font-family: courier new,monospace;"><span st= yle=3D"font-family: courier new,monospace;">=A0 &quot;_D9dashcheck6genIntFZ= i&quot;, referenced from:</span><br style=3D"font-family: courier new,monos= pace;"> <span style=3D"font-family: courier new,monospace;">=A0=A0=A0=A0=A0 anon in= example.o</span><br style=3D"font-family: courier new,monospace;"><span st= yle=3D"font-family: courier new,monospace;">=A0=A0=A0=A0=A0 _D7example7genE= venFZi in example.o</span><br style=3D"font-family: courier new,monospace;"=

<span style=3D"font-family: courier new,monospace;">ld: symbol(s) not found= for architecture i386</span><br style=3D"font-family: courier new,monospac= e;"><span style=3D"font-family: courier new,monospace;">collect2: ld return= ed 1 exit status</span><br style=3D"font-family: courier new,monospace;"> <span style=3D"font-family: courier new,monospace;">--- errorlevel 1</span>= <br clear=3D"all"><div><br></div>Cheers,<div><br></div><div>Andrew Pennebak= er</div><div><a href=3D"http://www.yellosoft.us" target=3D"_blank">www.yell= osoft.us</a></div> <br><div class=3D"gmail_quote">On Thu, Oct 27, 2011 at 6:28 PM, Nick Sabala= usky <span dir=3D"ltr">&lt;a a.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;"> &quot;Andrew Pennebaker&quot; &lt;<a href=3D"mailto:andrew.pennebaker gmail= .com">andrew.pennebaker gmail.com</a>&gt; wrote in message<br> news:mailman.543.1319752640.24802.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt; I&#39;ve got a single-file D module,<br> </div>&gt; dashcheck.d&lt;<a href=3D"https://github.com/mcandre/dashcheck" = target=3D"_blank">https://github.com/mcandre/dashcheck</a>&gt;,<br> <div class=3D"im">&gt; that I&#39;d like to install as a local package. In = other words, I&#39;d like to<br> &gt; be<br> &gt; able to &quot;import dashcheck;&quot; from any directory.<br> &gt;<br> &gt; I put dashcheck.d in ~/.d/, and I put export DFLAGS=3D-I~/.d in ~/.pro= file,<br> &gt; but when I try to run example.d from another directory, I get:<br> &gt;<br> &gt; $ ./example.d<br> &gt; ./example.d(3): Error: module dashcheck is in file &#39;dashcheck.d&#3= 9; which<br> &gt; cannot be read<br> &gt; import path[0] =3D /usr/local/Cellar/dmd/2.051/src/phobos<br> &gt; import path[1] =3D /usr/local/Cellar/dmd/2.051/src/druntime/importChee= rs,<br> &gt;<br> &gt; It appears that rdmd ignores $DFLAGS.<br> &gt;<br> <br> </div>I guess DFLAGS isn&#39;t an env var (which actually surprises me, it = probably<br> should be, is there already an enhancement request in bugzilla for that? Is= <br> is there some deliberate reason for this?).<br> <br> DFLAGS is normally set in your dmd.conf file (sc.ini on Windows). Do a<br> &quot;which dmd&quot; to see where your dmd binary is, and your dmd.conf wi= ll be in<br> the same directory (at least if you used the .zip releases or DVM, I don&#3= 9;t<br> know where the distros will put dmd.conf).<br> <br> Another approach that many of us use is to just pass the -Ipath option to<b= r> dmd or rdmd in your buildscript to tell dmd/rdmd where to look for look for= <br> imports (sort of the D counterpart to Java&#39;s classpaths).<br> <div class=3D"im"><br> &gt; Also, when I change the shebang in example.d to #!/usr/bin/env rdmd<br=

&gt; I get:<br> &gt;<br> &gt; $ ./example.d<br> &gt; sh: -I~/.d.d.deps: No such file or directory<br> &gt;<br> &gt; So I&#39;m not using import directives correctly. How do I generate<br=

&gt;<br> <br> </div>Part of the problem here is the same as above, DFLAGS needs to be set= in<br> dmd.conf, not an env var. But also, when you use rdmd as a shebang, you<br> should use the --shebang option (always as the first argument), ie:<br> <br> #!/usr/bin/env rdmd --shebang {whatever other options here}<br> <br> Apperently, shebangs tend to mess up the params that get sent to rdmd, and<= br> the --shebang makes it use an alternate approach made specifically for that= <br> situation.<br> <br> <br> <br> </blockquote></div><br> --f46d041390f5c1ca9704b04f7e0c--
Oct 27 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote in message 
news:mailman.545.1319755391.24802.digitalmars-d puremagic.com...
 In addition, I can't even use a naked -I directive without all the
 dmd.conf/DFLAGS stuff.

 My module code is in ~/Desktop/src/dashcheck. But even with the -Ipath
 directive, dmd still can't find it.

 $ dmd example.d -I~/Desktop/src/dashcheck
 Undefined symbols for architecture i386:
  "_D9dashcheck12__ModuleInfoZ", referenced from:
      _D7example12__ModuleInfoZ in example.o
  "_D9dashcheck9genStringFZAya", referenced from:
      anon in example.o
  "_D9dashcheck6genIntFZi", referenced from:
      anon in example.o
      _D7example7genEvenFZi in example.o
 ld: symbol(s) not found for architecture i386
 collect2: ld returned 1 exit status
 --- errorlevel 1

DMD found it as an import, you're just getting linker errors because you didn't tell DMD to actually compile dashcheck.d as well. For better or worse, DMD only compiles the files you give it, just like any old C/C++ compiler: dmd example.d ~/Desktop/src/dashcheckdashcheck.d -I~/Desktop/src/dashcheck RDMD, on the other hand, will actually go ahead and compile all the necessary .d files: rdmd --buildonly -I~/Desktop/src/dashcheck example.d (Note that RDMD requires the .d file to be the last parameter. Run rdmd with no args for more details.) There's one more thing though: I noticed from your OP that you're using DMD 2.051. The RDMD included in that is riddled with fairly major bugs that have all since been fixed. You're going to have a hard time getting that old RDMD to work right. So you should grab the rdmd binary from the latest release (2.056): http://ftp.digitalmars.com/dmd.2.056.zip You can just replace your existing rdmd binary with the one in there. It should still work with DMD 2.051. Of course, DMD 2.051 itself is getting a bit old too, so you may want to think about just simply upgrading to 2.056.
Oct 27 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Andrew Pennebaker Wrote:

 I've got a single-file D module,
 dashcheck.d<https://github.com/mcandre/dashcheck>,
 that I'd like to install as a local package. In other words, I'd like to be
 able to "import dashcheck;" from any directory.
 
 I put dashcheck.d in ~/.d/, and I put export DFLAGS=-I~/.d in ~/.profile,
 but when I try to run example.d from another directory, I get:

Just a theory but I suspect that DFLAGS in dmd.conf just override the environment you specify. You should be able to specify -I yourself but ~ may not be resolved. Also you must have a library and specify the library path -L-L or place it in a known location like /usr/local/lib
Oct 27 2011
prev sibling next sibling parent reply Andrew Pennebaker <andrew.pennebaker gmail.com> writes:
--bcaec5215d0d261ec704b0526366
Content-Type: text/plain; charset=ISO-8859-1

Nick, thanks for the info. I'm upgrading my Homebrew D installation now.
What's the point of -Ipath for dmd if you still have to specify the actual
files in the path?

I'm not sure if this is the right mailing list, but I'd really like to see
rdmd using the $DFLAGS environment variable like dmd does. For now, I'll use
your handy shebang tip.

Can future versions of rdmd turn on --shebang by default? I can't think of a
reason to give coders the ability to not support shebang options.

Jesse, aye, DFLAGS in dmd.conf appears to override the default rather than
append to the default. And that's just silly.

Cheers,

Andrew Pennebaker
www.yellosoft.us

On Thu, Oct 27, 2011 at 7:17 PM, Jesse Phillips
<jessekphillips+D gmail.com>wrote:

 Andrew Pennebaker Wrote:

 I've got a single-file D module,
 dashcheck.d<https://github.com/mcandre/dashcheck>,
 that I'd like to install as a local package. In other words, I'd like to

 able to "import dashcheck;" from any directory.

 I put dashcheck.d in ~/.d/, and I put export DFLAGS=-I~/.d in ~/.profile,
 but when I try to run example.d from another directory, I get:

Just a theory but I suspect that DFLAGS in dmd.conf just override the environment you specify. You should be able to specify -I yourself but ~ may not be resolved. Also you must have a library and specify the library path -L-L or place it in a known location like /usr/local/lib

--bcaec5215d0d261ec704b0526366 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nick, thanks for the info. I&#39;m upgrading my Homebrew D installation now= . What&#39;s the point of -Ipath for dmd if you still have to specify the a= ctual files in the path?<br><br>I&#39;m not sure if this is the right maili= ng list, but I&#39;d really like to see rdmd using the $DFLAGS environment = variable like dmd does. For now, I&#39;ll use your handy shebang tip.<br> <br>Can future versions of rdmd turn on --shebang by default? I can&#39;t t= hink of a reason to give coders the ability to not support shebang options.= <br><br>Jesse, aye, DFLAGS in dmd.conf appears to override the default rath= er than append to the default. And that&#39;s just silly.<br clear=3D"all"> <div><br></div>Cheers,<div><br></div><div>Andrew Pennebaker</div><div><a hr= ef=3D"http://www.yellosoft.us" target=3D"_blank">www.yellosoft.us</a></div>= <br><div class=3D"gmail_quote">On Thu, Oct 27, 2011 at 7:17 PM, Jesse Phill= ips <span dir=3D"ltr">&lt;<a href=3D"mailto:jessekphillips%2BD gmail.com">j= essekphillips+D 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"im">Andrew Pennebaker Wrote:<= br> <br> &gt; I&#39;ve got a single-file D module,<br> &gt; dashcheck.d&lt;<a href=3D"https://github.com/mcandre/dashcheck" target= =3D"_blank">https://github.com/mcandre/dashcheck</a>&gt;,<br> &gt; that I&#39;d like to install as a local package. In other words, I&#39= ;d like to be<br> &gt; able to &quot;import dashcheck;&quot; from any directory.<br> &gt;<br> &gt; I put dashcheck.d in ~/.d/, and I put export DFLAGS=3D-I~/.d in ~/.pro= file,<br> &gt; but when I try to run example.d from another directory, I get:<br> <br> </div>Just a theory but I suspect that DFLAGS in dmd.conf just override the= environment you specify. You should be able to specify -I yourself but ~ m= ay not be resolved.<br> <br> Also you must have a library and specify the library path -L-L or place it = in a known location like /usr/local/lib<br> </blockquote></div><br> --bcaec5215d0d261ec704b0526366--
Oct 27 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote in message 
news:mailman.550.1319767813.24802.digitalmars-d puremagic.com...
 Nick, thanks for the info. I'm upgrading my Homebrew D installation now.
 What's the point of -Ipath for dmd if you still have to specify the actual
 files in the path?

It has to do with D's C/C++ legacy, and the traditional C/C++ build model. In C/C++, you can compile difference sources separately, and *then* link them together - in fact, that's the old traditional way to do it: (I might not have these commands correct, I don't use gcc much) $ gcc -c -I~/ -I~/zlib a.c # compile to a.o, imports/headers can be found in ~/ and ~/zlib $ gcc -c ~/b.c # compile to b.o $ gcc -c ~/c.c # compile to c.o $ ld -of app a.o b.o c.o ~/zlib/zlib.lib # link together into app, along with pre-built zlib $ ./app # run app D retains that ability: $ dmd -c -I~/ -I~/zlib a.d # compile to a.o, imports/headers can be found in ~/ and ~/zlib $ dmd -c ~/b.d # compile to b.o $ dmd -c ~/c.d # compile to c.o $ dmd -ofapp a.o b.o c.o ~/zlib/zlib.lib # link together into app, along with pre-built zlib $ ./app # run app And as a shortcut, modern C/C++ and D compilers offer the ability to simplify that all into one command: $ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib # shortcut for the above statements But the old way is still possible becuause sometimes it can be useful (for instance, if a b and c are all in different languages, or if you want them each compiled with different settings, or to speed up long C/C++ compile times by compiling different parts on different machines). So that leads to this: Regardless of whether you do that in C/C++ or D: Suppose 'a' imports 'b', and inside 'a' you call a function from 'b'. If you've told it to *only* compile 'a' and not 'b' (because you intend to do it all separately) how does the compiler know that function you're using actually exists if you've only given it 'a'? Or if 'a' uses a class defined in 'b', how does the compiler know what members the class has if you only told it to compile 'a'? It has to find 'b', open it, and check. That's what -Ipath is for, so it knows where to find 'b' so it can find out what's in 'b', so that it can compile 'a' regardless of whether or not it's actually compiling 'b' as well. Of course, in most cases with D, all of that "one at a time" junk is just a pointless PITA, so fortunately we have RDMD to find all the .d files and just shove them all off to be compiled. So this: $ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib Becomes this: $ rdmd --build-only -ofapp -I~/zlib ~/zlib/zlib.lib a.d Note that ~/b.d and ~/c.d were omitted because RDMD will just find them itself, thanks to the -Ipath, and pass them all off to DMD to be compiled. Why can't DMD just do this itself, even just as an option? It could, and many people here wish it did. Maybe it even will someday. But right now it doesn't, so we have RDMD for that.
 I'm not sure if this is the right mailing list, but I'd really like to see
 rdmd using the $DFLAGS environment variable like dmd does.

Yea, that would be nice.
 For now, I'll use
 your handy shebang tip.

 Can future versions of rdmd turn on --shebang by default? I can't think of 
 a
 reason to give coders the ability to not support shebang options.

If it did that, then it won't work on the commandline anymore. :( IIRC, the problem is that with shebang scripts, all the args get passed in together as *one* large arg. But maybe there's a way to detect what's happening that isn't too unreliable...? Hell, other Unix apps don't seem to have this sort of problem, how the heck to they handle it?
 Jesse, aye, DFLAGS in dmd.conf appears to override the default rather than
 append to the default. And that's just silly.

Oct 27 2011
prev sibling parent Andrew Pennebaker <andrew.pennebaker gmail.com> writes:
--bcaec520e90373153804b05fdf8d
Content-Type: text/plain; charset=ISO-8859-1

Nick, thanks for the in-depth explanation of compilation with C and D.

Other shebanged languages *do* have the argument limitation problem. One way
to deal with it is to use multiline
shebangs<http://rosettacode.org/wiki/Multiline_shebang>.
They're especially helpful for doing scripted
main<http://rosettacode.org/wiki/Scripted_Main>,
running main() when the script is run, but not when the code is imported by
other code.

For example, since Clojure is in Java Land, it expects a class name rather
than a filename, so you have to do shell trickery just to get the basename.

Clojure

":";exec clj -m `basename $0 .clj` $0 ${1+"$ "}
":";exit


The CLISP implementation of Common Lisp drops the program name as an
argument, so you have to forcibly add it back. Unfortunately, each CL
implementation has its own program name, *and* command line semantics, so
you have to rewrite this one for the particular CL implementation on your
machine.

Common Lisp

#!/bin/sh
#|
exec clisp -q -q $0 $0 ${1+"$ "}

exit
|#


Chicken Scheme

#!/bin/sh
#|
exec csi -ss $0 ${1+"$ "}

exit
|#


Emacs Lisp

:;exec emacs -batch -l $0 -f main $*

Smalltalk

"exec" "gst" "-f" "$0" "$0" "$ "
"exit"


The trick is to find a way to comment the shebang lines so that sh sees them
but not your programming language. But the real trouble is discovering the
secret syntax for this; when you have to resort to multiline shebangs,
that's an indication that scripting/CLI/POSIX is an incredibly low priority,
so developers A) don't know such obscure syntax and B) don't understand why
anyone would want to script on the command line. Common Lispers tell you
"there's no reason to use bash when you've got the CL repl". Smalltalkers
say "just use the Squeak VM GUI." And Free Pascalers remark "Scripting? You
kids get off my lawn!"

Language-specific IDEs are neat, but I like using a language-agnostic
development environment: a text editor and a shell, and I like being able to
dot-slash my scripts: ./script if at all possible.

So three cheers for rdmd!

Cheers,

Andrew Pennebaker
www.yellosoft.us

On Thu, Oct 27, 2011 at 11:17 PM, Nick Sabalausky <a a.a> wrote:

 "Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote in message
 news:mailman.550.1319767813.24802.digitalmars-d puremagic.com...
 Nick, thanks for the info. I'm upgrading my Homebrew D installation now.
 What's the point of -Ipath for dmd if you still have to specify the

 files in the path?

It has to do with D's C/C++ legacy, and the traditional C/C++ build model. In C/C++, you can compile difference sources separately, and *then* link them together - in fact, that's the old traditional way to do it: (I might not have these commands correct, I don't use gcc much) $ gcc -c -I~/ -I~/zlib a.c # compile to a.o, imports/headers can be found in ~/ and ~/zlib $ gcc -c ~/b.c # compile to b.o $ gcc -c ~/c.c # compile to c.o $ ld -of app a.o b.o c.o ~/zlib/zlib.lib # link together into app, along with pre-built zlib $ ./app # run app D retains that ability: $ dmd -c -I~/ -I~/zlib a.d # compile to a.o, imports/headers can be found in ~/ and ~/zlib $ dmd -c ~/b.d # compile to b.o $ dmd -c ~/c.d # compile to c.o $ dmd -ofapp a.o b.o c.o ~/zlib/zlib.lib # link together into app, along with pre-built zlib $ ./app # run app And as a shortcut, modern C/C++ and D compilers offer the ability to simplify that all into one command: $ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib # shortcut for the above statements But the old way is still possible becuause sometimes it can be useful (for instance, if a b and c are all in different languages, or if you want them each compiled with different settings, or to speed up long C/C++ compile times by compiling different parts on different machines). So that leads to this: Regardless of whether you do that in C/C++ or D: Suppose 'a' imports 'b', and inside 'a' you call a function from 'b'. If you've told it to *only* compile 'a' and not 'b' (because you intend to do it all separately) how does the compiler know that function you're using actually exists if you've only given it 'a'? Or if 'a' uses a class defined in 'b', how does the compiler know what members the class has if you only told it to compile 'a'? It has to find 'b', open it, and check. That's what -Ipath is for, so it knows where to find 'b' so it can find out what's in 'b', so that it can compile 'a' regardless of whether or not it's actually compiling 'b' as well. Of course, in most cases with D, all of that "one at a time" junk is just a pointless PITA, so fortunately we have RDMD to find all the .d files and just shove them all off to be compiled. So this: $ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib Becomes this: $ rdmd --build-only -ofapp -I~/zlib ~/zlib/zlib.lib a.d Note that ~/b.d and ~/c.d were omitted because RDMD will just find them itself, thanks to the -Ipath, and pass them all off to DMD to be compiled. Why can't DMD just do this itself, even just as an option? It could, and many people here wish it did. Maybe it even will someday. But right now it doesn't, so we have RDMD for that.
 I'm not sure if this is the right mailing list, but I'd really like to

 rdmd using the $DFLAGS environment variable like dmd does.

Yea, that would be nice.
 For now, I'll use
 your handy shebang tip.

 Can future versions of rdmd turn on --shebang by default? I can't think

 a
 reason to give coders the ability to not support shebang options.

If it did that, then it won't work on the commandline anymore. :( IIRC, the problem is that with shebang scripts, all the args get passed in together as *one* large arg. But maybe there's a way to detect what's happening that isn't too unreliable...? Hell, other Unix apps don't seem to have this sort of problem, how the heck to they handle it?
 Jesse, aye, DFLAGS in dmd.conf appears to override the default rather

 append to the default. And that's just silly.


--bcaec520e90373153804b05fdf8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nick, thanks for the in-depth explanation of compilation with C and D.<br><= br>Other shebanged languages <i>do</i> have the argument limitation problem= . One way to deal with it is to use <a href=3D"http://rosettacode.org/wiki/= Multiline_shebang">multiline shebangs</a>. They&#39;re especially helpful f= or doing <a href=3D"http://rosettacode.org/wiki/Scripted_Main">scripted mai= n</a>, running main() when the script is run, but not when the code is impo= rted by other code.<br> <br>For example, since Clojure is in Java Land, it expects a class name rat= her than a filename, so you have to do shell trickery just to get the basen= ame.<br><br>Clojure<br> <br> <pre class=3D"clojure highlighted_source"><span class=3D"st0">&quot;:&quot;= </span><span class=3D"co1">;exec clj -m `basename $0 .clj` $0 ${1+&quot;$ &= quot;}</span><br><span class=3D"st0">&quot;:&quot;</span><span class=3D"co1= ">;exit</span></pre> <br>The CLISP implementation of Common Lisp drops the program name as an ar= gument, so you have to forcibly add it back. Unfortunately, each CL impleme= ntation has its own program name, <i>and</i> command line semantics, so you= have to rewrite this one for the particular CL implementation on your mach= ine.<br> <br>Common Lisp<br><br><pre class=3D"lisp highlighted_source">#<span class= =3D"sy0">!</span>/bin/sh<br>#<span class=3D"sy0">|</span><br>exec clisp -q = -q $0 $0 $<span class=3D"br0">{</span><span class=3D"nu0">1</span>+<span cl= ass=3D"st0">&quot;$ &quot;</span><span class=3D"br0">}</span><br> exit<br><span class=3D"sy0">|</span>#</pre><br>Chicken Scheme<br><br><pre c= lass=3D"scheme highlighted_source">#<span class=3D"sy0">!/</span>bin<span c= lass=3D"sy0">/</span>sh<br><span class=3D"coMULTI">#|<br>exec csi -ss $0 ${= 1+&quot;$ &quot;}<br> exit<br>|#</span></pre><br>Emacs Lisp<br><br><pre class=3D"lisp highlighted= _source"><span class=3D"sy0">:</span><span class=3D"co1">;exec emacs -batch= -l $0 -f main $*</span></pre>Smalltalk<br><br><pre class=3D"smalltalk high= lighted_source"> <span class=3D"coMULTI">&quot;exec&quot;</span> <span class=3D"coMULTI">&qu= ot;gst&quot;</span> <span class=3D"coMULTI">&quot;-f&quot;</span> <span cla= ss=3D"coMULTI">&quot;$0&quot;</span> <span class=3D"coMULTI">&quot;$0&quot;= </span> <span class=3D"coMULTI">&quot;$ &quot;</span><br> <span class=3D"coMULTI">&quot;exit&quot;</span></pre><br>The trick is to fi= nd a way to comment the shebang lines so that sh sees them but not your pro= gramming language. But the real trouble is discovering the secret syntax fo= r this; when you have to resort to multiline shebangs, that&#39;s an indica= tion that scripting/CLI/POSIX is an incredibly low priority, so developers = A) don&#39;t know such obscure syntax and B) don&#39;t understand why anyon= e would want to script on the command line. Common Lispers tell you &quot;t= here&#39;s no reason to use bash when you&#39;ve got the CL repl&quot;. Sma= lltalkers say &quot;just use the Squeak VM GUI.&quot; And Free Pascalers re= mark &quot;Scripting? You kids get off my lawn!&quot;<br> <br>Language-specific IDEs are neat, but I like using a language-agnostic d= evelopment environment: a text editor and a shell, and I like being able to= dot-slash my scripts: ./script if at all possible.<br><br>So three cheers = for rdmd!<br clear=3D"all"> <div><br></div>Cheers,<div><br></div><div>Andrew Pennebaker</div><div><a hr= ef=3D"http://www.yellosoft.us" target=3D"_blank">www.yellosoft.us</a></div>= <br><div class=3D"gmail_quote">On Thu, Oct 27, 2011 at 11:17 PM, Nick Sabal= ausky <span dir=3D"ltr">&lt;a a.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">&quot;Andrew Pennebaker&q= uot; &lt;<a href=3D"mailto:andrew.pennebaker gmail.com">andrew.pennebaker g= mail.com</a>&gt; wrote in message<br> </div>news:mailman.550.1319767813.24802.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt; Nick, thanks for the info. I&#39;m upgrading my Home= brew D installation now.<br> &gt; What&#39;s the point of -Ipath for dmd if you still have to specify th= e actual<br> &gt; files in the path?<br> &gt;<br> <br> </div>It has to do with D&#39;s C/C++ legacy, and the traditional C/C++ bui= ld model.<br> In C/C++, you can compile difference sources separately, and *then* link<br=

<br> (I might not have these commands correct, I don&#39;t use gcc much)<br> $ gcc -c -I~/ -I~/zlib a.c =A0# compile to a.o, imports/headers can be foun= d<br> in ~/ and ~/zlib<br> $ gcc -c ~/b.c =A0 # compile to b.o<br> $ gcc -c ~/c.c =A0 # compile to c.o<br> $ ld -of app a.o b.o c.o ~/zlib/zlib.lib =A0 # link together into app, alon= g<br> with pre-built zlib<br> $ ./app =A0 # run app<br> <br> D retains that ability:<br> $ dmd -c -I~/ -I~/zlib a.d =A0 # compile to a.o, imports/headers can be fou= nd<br> in ~/ and ~/zlib<br> $ dmd -c ~/b.d =A0 # compile to b.o<br> $ dmd -c ~/c.d =A0 # compile to c.o<br> $ dmd -ofapp a.o b.o c.o ~/zlib/zlib.lib =A0 # link together into app, alon= g<br> with pre-built zlib<br> $ ./app =A0 # run app<br> <br> And as a shortcut, modern C/C++ and D compilers offer the ability to<br> simplify that all into one command:<br> <br> $ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib =A0# shortcut for the= <br> above statements<br> <br> But the old way is still possible becuause sometimes it can be useful (for<= br> instance, if a b and c are all in different languages, or if you want them<= br> each compiled with different settings, or to speed up long C/C++ compile<br=

<br> So that leads to this:<br> <br> Regardless of whether you do that in C/C++ or D: Suppose &#39;a&#39; import= s &#39;b&#39;,<br> and inside &#39;a&#39; you call a function from &#39;b&#39;. If you&#39;ve = told it to *only*<br> compile &#39;a&#39; and not &#39;b&#39; (because you intend to do it all se= parately) how<br> does the compiler know that function you&#39;re using actually exists if yo= u&#39;ve<br> only given it &#39;a&#39;? Or if &#39;a&#39; uses a class defined in &#39;b= &#39;, how does the<br> compiler know what members the class has if you only told it to compile &#3= 9;a&#39;?<br> It has to find &#39;b&#39;, open it, and check. That&#39;s what -Ipath is f= or, so it<br> knows where to find &#39;b&#39; so it can find out what&#39;s in &#39;b&#39= ;, so that it can<br> compile &#39;a&#39; regardless of whether or not it&#39;s actually compilin= g &#39;b&#39; as<br> well.<br> <br> Of course, in most cases with D, all of that &quot;one at a time&quot; junk= is just a<br> pointless PITA, so fortunately we have RDMD to find all the .d files and<br=

<br> $ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib<br> <br> Becomes this:<br> <br> $ rdmd --build-only -ofapp -I~/zlib ~/zlib/zlib.lib a.d<br> <br> Note that ~/b.d and ~/c.d were omitted because RDMD will just find them<br> itself, thanks to the -Ipath, and pass them all off to DMD to be compiled.<= br> <br> Why can&#39;t DMD just do this itself, even just as an option? It could, an= d<br> many people here wish it did. Maybe it even will someday. But right now it<= br> doesn&#39;t, so we have RDMD for that.<br> <div class=3D"im"><br> <br> &gt; I&#39;m not sure if this is the right mailing list, but I&#39;d really= like to see<br> &gt; rdmd using the $DFLAGS environment variable like dmd does.<br> <br> </div>Yea, that would be nice.<br> <div class=3D"im"><br> &gt; For now, I&#39;ll use<br> &gt; your handy shebang tip.<br> &gt;<br> &gt; Can future versions of rdmd turn on --shebang by default? I can&#39;t = think of<br> &gt; a<br> &gt; reason to give coders the ability to not support shebang options.<br> &gt;<br> <br> </div>If it did that, then it won&#39;t work on the commandline anymore. :(= =A0IIRC, the<br> problem is that with shebang scripts, all the args get passed in together a= s<br> *one* large arg.<br> <br> But maybe there&#39;s a way to detect what&#39;s happening that isn&#39;t t= oo<br> unreliable...?<br> <br> Hell, other Unix apps don&#39;t seem to have this sort of problem, how the = heck<br> to they handle it?<br> <div><div></div><div class=3D"h5"><br> &gt; Jesse, aye, DFLAGS in dmd.conf appears to override the default rather = than<br> &gt; append to the default. And that&#39;s just silly.<br> &gt;<br> <br> <br> <br> </div></div></blockquote></div><br> --bcaec520e90373153804b05fdf8d--
Oct 28 2011