DIP11

[Steven Schveighoffer]

On Fri, 12 Aug 2011 14:24:46 -0400, Jacob Carlborg <doob at 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