The problem is that rdmd will create temporary files within the same
directory as the .d file it compiles. On a *nix system, where vibe.d
might be installed in a read-only directory, this would cause rdmd to
fail. rdmd is also the reason why it currencly always compiles the
application - rdmd (or rather dmd -deps=...) does not detect function
local imports and string imports as dependencies. So the alternative to
spend some seconds vs. missing changes was considered the preferable
one. (The bug is partially mentioned in
http://d.puremagic.com/issues/show_bug.cgi?id=767#c3)Workaround is to run "vibe build" and then only the generated
./app(.exe).Because of these issues and also to improve compatibility with gdc and
ldc, I'm thinking about implementing a build script that does not rely
on rdmd.Really? rdmd creates files in /tmp on my Arch machine...
I'll look into it.I have a version that outputs the applicationName upon vibe build.
Needs cleaning, then I'll pull.$VIBEPATH <- why is that there?
Looking at the source for rdmd, I see:
private @property string myOwnTmpDir()
{
version (Posix)
{
import core.sys.posix.unistd;
auto tmpRoot = format("/tmp/.rdmd-%d", getuid());
}
...
}
which is used literally everywhere that the tmpfile is mentioned.
/tmp/.rdmd-userid is literally hardcoded into rdmd.
I've been tracing rdmd for a few minutes, and it appears that the version
on github
does write anything to the current directory unless you specifically ask
it to(deps, etc).
I can submit a pull request for rdmd to check the current directory and
default to myOwnTmpDir if it is readonly.
Or we could always fork rdmd. It should be using the boost license and
it'd be an excellent starting point.
The executable and the object are both written to myOwnTmpDir afaict.
I do not know if it is still true, but since rdmd claims that it 'may get
folded into dmd',
It might be a good idea to support it 'officially' as long as it does what
is needed...
But that is your call to make.
rdmd also supports the --compiler=[anything] and gdc builds and installs
gdmd by default.
my version of ldc also includes a ldmd2 wrapper by default, although I do
not know if it is built with ldc like gdc.
It looks like everything includes a "map dmd opts to our opts" mode, so
that's a very good thing for us at least.