I just hit something that might be a compiler bug, or might be a
documentation bug. (Of course, it can't be me! :P )
I have two modules:
config.d
===
version (clientA) {}
version ( clientB ) {
version = withFeatureX;
}
version (clientC) {
version = withFeatureX;
}
===
application.d
===
If this behavior is by design, I suggest changing this sentence:
http://www.digitalmars.com/d/2.0/version.html
"Version identifiers defined in one module have no influence over
other imported modules."
To
"Version identifiers defined in one module have no influence over
other modules."
Strikin
Sorry for three messages in a row, but I just realized what I'm asking
for would break incremental compiles, since the version thing wouldn't
be propagated there. So I guess it is by design. I think the
documentation should be a bit more explicit about it.
That kinda sucks though. I can't have tha
On Friday, August 20, 2010 16:49:38 Adam Ruppe wrote:
> I just hit something that might be a compiler bug, or might be a
> documentation bug. (Of course, it can't be me! :P )
>
> I have two modules:
>
> config.d
> ===
> version (clientA) {}
>
> version ( clientB ) {
> version = withFeatureX;
On Friday, August 20, 2010 17:03:11 Adam Ruppe wrote:
> Sorry for three messages in a row, but I just realized what I'm asking
> for would break incremental compiles, since the version thing wouldn't
> be propagated there. So I guess it is by design. I think the
> documentation should be a bit more
Last message in a row, I promise.
I just determined a work around for this - use a global variable. (the
config.d file defines several global variables already, but it is
stuff like companyName, domainName, etc.).
A global enum actually:
version(clientA)
enum bool withFeatureX = true;
=
mixin(import("file.d"));
You need to pass -IPATH to DMD to use with imports like that, as in:
dmd -IC:\blabla\
Thats a capital "i" there.
> IIRC, you can do something with mixin and import to load in an external file
> as
> code, but since I've never used it and don't expect to any time soon (
There are no global variables in D, afaik. But I haven't studied this
closely yet.
On Sat, Aug 21, 2010 at 2:21 AM, Adam Ruppe wrote:
> Last message in a row, I promise.
>
> I just determined a work around for this - use a global variable.
On 8/20/10, Andrej Mitrovic wrote:
> There are no global variables in D, afaik. But I haven't studied this
> closely yet.
The opposite: there are multiple kinds. You have enums in the global
scope, which are available to everyone, but don't take any storage
(that's what I used here), you have re
I dunno, TDPL says:
"D does not have a global scope or a global namespace. In particular,
there is no way to define a truly global object, function, or class
name. This is because the only way to define such an entity is to put
it in a module, and any module has a name. In turn, the name of the
mo
On Friday, August 20, 2010 18:05:16 Andrej Mitrovic wrote:
> There are no global variables in D, afaik. But I haven't studied this
> closely yet.
>
> On Sat, Aug 21, 2010 at 2:21 AM, Adam Ruppe wrote:
> > Last message in a row, I promise.
> >
> > I just determined a work around for this - use a
On 8/20/10, Andrej Mitrovic wrote:
> I dunno, TDPL says:
> *snip*
That's true, though I think it is getting into nitpicking the
definition of global variable still, the module system resolves
conflicts in a way that C globals can't hope to do, which is
fantastic. All the benefits with none of
As long as there is no ambiguity, right?
Some of this stuff is on the next page but I haven't read it yet. I
like how D handles modules, it seems much better than C and
#includes. I only wish DMD could automatically do a build by passing
dmd main.d , and letting it worry about all the imports, et
On Friday, August 20, 2010 18:41:45 Andrej Mitrovic wrote:
> As long as there is no ambiguity, right?
>
> Some of this stuff is on the next page but I haven't read it yet. I
> like how D handles modules, it seems much better than C and
> #includes. I only wish DMD could automatically do a build b
Adam Ruppe wrote:
I just hit something that might be a compiler bug, or might be a
documentation bug. (Of course, it can't be me! :P )
As has been said, it's by design. However, it does destroy much of the
usefulness of VersionSpecification.
As such, there ought to be an explicit means of
Oops, that was supposed to be dmd -JC:\blabla\
-I is for the path used in import declarations, -J is for import expressions.
On Sat, Aug 21, 2010 at 2:23 AM, Andrej Mitrovic
wrote:
> mixin(import("file.d"));
>
> You need to pass -IPATH to DMD to use with imports like that, as in:
> dmd -IC:\blab
Adam Ruppe wrote:
Should it? Note that it does work correctly if I put the version= line
in the actual file, but that means I can't have the nice centralized
config module anymore.
The compiler is exhibiting correct behavior.
The idea is, versions exist only in the module's scope. You cannot s
On Sun, Aug 22, 2010 at 10:23:33PM -0700, Walter Bright wrote:
> The compiler is exhibiting correct behavior.
I think there should be an extra note in there: version specifications only
apply to the module in which they appear.
> can be tested by the importer with static if. These declarations ca
The following outputs "Unicode!". If I reverse the comment for [1] and
[2] however, the output is "ASCII".
file a:
module A;
version = Unicode; [1]
version(Unicode)
{
alias ChoiceA Choice;
}
else
{
alias ChoiceB Choice;
}
string ChoiceA() { re
On 2011-06-28 19:22, clone!(all) wrote:
> The following outputs "Unicode!". If I reverse the comment for [1] and
> [2] however, the output is "ASCII".
>
> file a:
>
> module A;
>
> version = Unicode; [1]
>
> version(Unicode)
> {
> alias ChoiceA Choice;
> }
On 6/29/2011 11:28 AM, Jonathan M Davis wrote:
On 2011-06-28 19:22, clone!(all) wrote:
The following outputs "Unicode!". If I reverse the comment for [1] and
[2] however, the output is "ASCII".
file a:
module A;
version = Unicode; [1]
version(Unicode)
{
21 matches
Mail list logo
