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 ?
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.
Essentially, the import statements become your "build file". I think
dsss worked like this, but I don't remember completely.
Yes, this is similar how DSSS worked. The difference is that you
didn't need a pragma to link a package to an URL you just wrote the
import declarations as you do now.
IIRC, dsss still had a global config file that defined where to import
things from. The DIP defines that -I switches can also define internet
resources along with pragmas, so sticking those in the dmd.conf would
probably be the equivalent.
Ok, I see.
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.
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.
dmd -lib -O -release -inline dcollections/*.d dcollections/model/*.d
Any new files get included automatically. And it takes a second to
build, so who cares if you rebuild every file every time?
Interestingly, libraries would still need to specify all the files since
they may not import eachother :) I don't know if there's a "good"
solution that isn't too coarse for that.
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.
All of this discussion is good to determine the viability, and clarify
some misinterpretations of DIP11, but I think unless someone steps up
and tries to implement it, it's a moot conversation. I certainly don't
have the time or knowledge to implement it. So is there anyone who is
interested, or has tried (to re-ask the original question)?
-Steve
I guess that's right.
--
/Jacob Carlborg
