Just a quick question, why does the map file have a long name like so:

file_test-d-40DA973DB4C6AD075993AB5CD9866DDE.map ?

"Andrej Mitrovic" <none@none.none> wrote in message news:i6jc5g$1p2a$1@digitalmars.com...
> Just a quick question, why does the map file have a long name like so:
>
> file_test-d-40DA973DB4C6AD075993AB5CD9866DDE.map ?

Because you're using rdmd and not using -of.

rdmd comes up with an executable filename by hashing the source file's content (I'm not 100% sure why, something about filename-uniqueness or caching and change-tracking, I'd imagine). And dmd always uses the executable filename as the name of the map file (which makes sense when you consider executables made from multiple modules).

If you use -of, or if you just use dmd directly, then that hash value doesn't get added.

Yeah but using -of creates an executable in the directory I provide. RDMD is supossed to be used with hiding the executable in a temp dir, afaik.

So it's hashing at play, ok. Just wanted to know why.

Personally I'd like RDMD to hide the map and deps files as well, I don't know why it only hides the executable and leaves the rest of the trash behind. (okay it's not trash, but for quick compile-test cycles I don't need the map and dependancy files).

On Sun, Sep 12, 2010 at 10:29 PM, Nick Sabalausky <a@a.a> wrote:
> "Andrej Mitrovic" <none@none.none> wrote in message news:i6jc5g$1p2a$1@digitalmars.com...
>> Just a quick question, why does the map file have a long name like so:
>>
>> file_test-d-40DA973DB4C6AD075993AB5CD9866DDE.map ?
>
> Because you're using rdmd and not using -of.
>
> rdmd comes up with an executable filename by hashing the source file's content (I'm not 100% sure why, something about filename-uniqueness or caching and change-tracking, I'd imagine). And dmd always uses the executable filename as the name of the map file (which makes sense when you consider executables made from multiple modules).
>
> If you use -of, or if you just use dmd directly, then that hash value doesn't get added.
>
>
>

Hello Andrej,

> Yeah but using -of creates an executable in the directory I provide.
> RDMD is supossed to be used with hiding the executable in a temp dir,
> afaik.
> 
> So it's hashing at play, ok. Just wanted to know why.
> 
> Personally I'd like RDMD to hide the map and deps files as well, I
> don't know why it only hides the executable and leaves the rest of the
> trash behind. (okay it's not trash, but for quick compile-test cycles
> I don't need the map and dependancy files).
> 

Hinding the exe isn't the point, having files act like scripts is. Putting the exes in some other common place allows better caching.

> On Sun, Sep 12, 2010 at 10:29 PM, Nick Sabalausky <a@a.a> wrote:
> 
>> "Andrej Mitrovic" <none@none.none> wrote in message
>> news:i6jc5g$1p2a$1@digitalmars.com...
>> 
>>> Just a quick question, why does the map file have a long name like
>>> so:
>>> 
>>> file_test-d-40DA973DB4C6AD075993AB5CD9866DDE.map ?
>>> 
>> Because you're using rdmd and not using -of.
>> 
>> rdmd comes up with an executable filename by hashing the source
>> file's content (I'm not 100% sure why, something about
>> filename-uniqueness or caching and change-tracking, I'd imagine). And
>> dmd always uses the executable filename as the name of the map file
>> (which makes sense when you consider executables made from multiple
>> modules).
>> 
>> If you use -of, or if you just use dmd directly, then that hash value
>> doesn't get added.
>> 
-- 
... <IXOYE><

"BCS" <none@anon.com> wrote in message news:a6268ff1c0308cd20c34c198d44@news.digitalmars.com...
> Hello Andrej,
>
>> Yeah but using -of creates an executable in the directory I provide. RDMD is supossed to be used with hiding the executable in a temp dir, afaik.
>>
>> So it's hashing at play, ok. Just wanted to know why.
>>
>> Personally I'd like RDMD to hide the map and deps files as well, I don't know why it only hides the executable and leaves the rest of the trash behind. (okay it's not trash, but for quick compile-test cycles I don't need the map and dependancy files).
>>
>
> Hinding the exe isn't the point, having files act like scripts is. Putting the exes in some other common place allows better caching.
>

I also like to use RDMD as an alternate to rebuild/xfbuild (especially since xfbuild's been giving me trouble since I moved to D2).

xfbuild has racing problems, according to its creator. He recommended me to force xfbuild to use only one thread. I had issues where it's output would quite literally come out in an alien language. When there are problems I have to re-run xfbuild several times until it finally builds properly.

I wonder if this issue is caused by D1's shared-by-default state.

On Mon, Sep 13, 2010 at 8:42 AM, Nick Sabalausky <a@a.a> wrote:
> "BCS" <none@anon.com> wrote in message news:a6268ff1c0308cd20c34c198d44@news.digitalmars.com...
>> Hello Andrej,
>>
>>> Yeah but using -of creates an executable in the directory I provide. RDMD is supossed to be used with hiding the executable in a temp dir, afaik.
>>>
>>> So it's hashing at play, ok. Just wanted to know why.
>>>
>>> Personally I'd like RDMD to hide the map and deps files as well, I don't know why it only hides the executable and leaves the rest of the trash behind. (okay it's not trash, but for quick compile-test cycles I don't need the map and dependancy files).
>>>
>>
>> Hinding the exe isn't the point, having files act like scripts is. Putting the exes in some other common place allows better caching.
>>
>
> I also like to use RDMD as an alternate to rebuild/xfbuild (especially since xfbuild's been giving me trouble since I moved to D2).
>
>
>

> On Mon, Sep 13, 2010 at 8:42 AM, Nick Sabalausky <a@a.a> wrote:
>>
>> I also like to use RDMD as an alternate to rebuild/xfbuild (especially
>> since
>> xfbuild's been giving me trouble since I moved to D2).
>>
>>

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.200.1284394076.858.digitalmars-d-learn@puremagic.com...
> xfbuild has racing problems, according to its creator. He recommended me to force xfbuild to use only one thread. I had issues where it's output would quite literally come out in an alien language. When there are problems I have to re-run xfbuild several times until it finally builds properly.
>
> I wonder if this issue is caused by D1's shared-by-default state.
>

That's not the issue I'm having. xfbuild only uses one thread on my machine by default and I still had problems:

http://d.puremagic.com/issues/show_bug.cgi?id=4687

Always seemed to work fine on D1/Tango though.