On Fri, 12 Aug 2011 14:24:46 -0400, Jacob Carlborg <d...@me.com> wrote:
On 2011-08-12 15:49, Steven Schveighoffer wrote:
Note that the pragmas are specific to that file only. So you don't have
an import file which defines pragmas. This is to prevent conflicts
between two files that declare the same package override.
Now I'm not quite sure I understand. Are you saying that every file
needs to have these pragma imports ?
Let's say file a.d pragmas that module foo means http://foo.com/projectx,
and module b.d from another project pragmas that module foo means
http://bar.com/projecty. If I import both a and b, what happens?
It only makes sense for a pragma to affect the current file.
This is similar to how version=x statements only affect the current file.
In addition to that as soon as you need to pass flags to the compiler
you will most likely to put that in a file of some kind. In that case
you can just as easily put them in a build script and use a build tool.
a batch files/shell script should suffice, no need for a "special" tool.
Yeah, but you would need to duplicate the shell script, one for Posix
and one for Windows. As far as I know there is no scripting like file
that both Windows and Posix can read out of the box.
But I don't have to have the user install yet other build tool. There
already are script interpreters on both windows and posix systems.
Especially for one-liners.
One problem I think DSSS has, is, as far as I know, it can't handle
top level packages with same name. Or at least not in any good way. If
you go with the Java package naming scheme and name your top level
package after your domain, example:
module com.foo.bar;
module com.foo.foobar;
And another project does the same:
module com.abc.defg;
Then these two projects will both end up in the "com" folder. Not very
good in my opinion. In my solution every package has a name
independent of the packages it contains an all packages are placed in
a folder named after the package, including the version number.
These all seem like implementation details. I don't care how the tool
caches the files.
Well yes, but that is how DSSS works and that's what I'm explaining.
OK.
Or instructions on the web site "use 'dmd -O -inline -release
-version=SpecificVersion project.d' to compile"
Or build.sh (build.bat) Note that dcollections has no makefile,
everything is built from shell scripts. I almost never have to edit the
build file, because the line's like:
You would need to shell script files, one for Windows and one for Posix,
see above.
Yes.
That's what a build tool can handle. I think you should read this:
http://dsource.org/projects/dsss/wiki/DSSSByExample and hopefully you'll
understand why a built tool is a good thing.
I'll take a look when I get a moment.
-Steve
