Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-14 21:15, Nick Sabalausky wrote:
> I assume you meant "mixin" instead of "writeln".

Doesn't matter. It's the import statement I'm referring to.

> What I meant is that, suppose wr have this:
>
>      // internal_to_drake.d:
>      void main()
>      {
>          mixin(import("main.d"));
>      }
>
>      // main.d:
>      import blah;
>      // rest of buildscript...
>
> Then that becomes:
>
>      void main()
>      {
>          import blah;
>          // rest of buildscript...
>      }
>
> And *that's* a brand-new feature. And I think there may be some other
> things, too, that might still be a little buggy if they're stuck inside a
> function like that.

Ah, now I see. I'm hoping the user never needs to write import 
statements in the build script. It's just these little things that I 
don't like about using D for the build scripts. Imports and no top level 
code.

>>> - I wasn't sure if a D file that isn't strictly a proper D file would be
>>> too
>>> weird, too confusing, too magical, or would confuse the fuck out of
>>> advanced
>>> IDE's.
>>
>> I have no idea how an IDE would behave with an incomplete file like that.
>> I pretty sure this only matters if the IDE does some semantic processing,
>> i.e. something more than just syntax highlighting. Textmate, which
>> basically only does syntax highlighting, has no problem with an incomplete
>> D file.
>>
>
> Right, but a lot of people use fancy IDE's like Eclipse and Visual Studio.

Exactly.

> Maybe you're thinking D1? I *think* the thread-local-by-default is D2-only
> (though I'm not certain).

I was thinking in Ruby, but I've already answered this in another post.

-- 
/Jacob Carlborg