On Saturday, 1 December 2012 at 13:18:04 UTC, Jacob Carlborg wrote:
> On 2012-11-30 19:36, Dmitry Olshansky wrote:
>
>> AFAIK you don't need to import module to run its tests. So
>>    rdmd --main -unittest a.d b.d
>> should work.
>
> RDMD is the external tool that I was talking about. Which is fixing some of the problems I was talking about.
>
>> Then we should also be able to make rdmd more extendable. There is e.g.
>> quite interesting --eval switch but I feel it could be something more
>> customizable w/o a lot of extra work.
>
> RDMD should be built as a library as well.

I have to agree, rdmd should be a library.

It's entirely possible that the very best way around the build issue (and likely many other issues as well), is through an extensible library format for the compiler, transforming it in to an embeddable tool that even itself can use.

As you know, D interacts very poorly with the concepts of extensible libraries, for example, druntime is not even position independent, so it seems the advantages of library use was not in the mind set when D was first created. Imagine where this can be taken!

We really need a generally agreed on official road map for all the devs to follow. What I've seen so far focuses far too much on the language feature set alone, but the tools are a significant component of any language, so that part should not be taken so lightly. Time to change that mindset, somehow.

--rt

On Saturday, 1 December 2012 at 13:19:45 UTC, Jacob Carlborg wrote:
> The -deps output contains the full path for all source files, or is the something I'm missing here?

When I use -deps, I do get full path for everything except for my own code, which only shows the path relative to where dmd is being run, so there's no easy way to determine what is a relative path  and what is a full path.

However, I just had a thought to try using -I./src (specify ./ for local project source folder) and in that case I can at least determine which paths are relative paths, so maybe I can use that to replace the ./ with a full path.

BTW, I somehow missed the -od option, and although I'm having some linker issues to sort out, it seems that it will do exactly what I want. It may be almost possible to completely do away with a script, at least for some builds, but is there a way to specify a final installation folder, or will a script be required for that?

Thanks for the input, I'm still learning something new about D every day.

--rt

On 2012-12-01 23:21, Rob T wrote:
> On Saturday, 1 December 2012 at 13:19:45 UTC, Jacob Carlborg wrote:
>> The -deps output contains the full path for all source files, or is
>> the something I'm missing here?
>
> When I use -deps, I do get full path for everything except for my own
> code, which only shows the path relative to where dmd is being run, so
> there's no easy way to determine what is a relative path  and what is a
> full path.

Aha, I didn't notice that. I don't understand why it would be hard to determine if a path is relative or not, just use std.path.isAbsolute.

> BTW, I somehow missed the -od option, and although I'm having some
> linker issues to sort out, it seems that it will do exactly what I want.
> It may be almost possible to completely do away with a script, at least
> for some builds, but is there a way to specify a final installation
> folder, or will a script be required for that?
>
> Thanks for the input, I'm still learning something new about D every day.

The only option the compiler is giving you is the -of flag. It will place the resulting binary in the path given with the -of flag.

-- 
/Jacob Carlborg

On 2012-12-01 22:32, Rob T wrote:

> I have to agree, rdmd should be a library.
>
> It's entirely possible that the very best way around the build issue
> (and likely many other issues as well), is through an extensible library
> format for the compiler, transforming it in to an embeddable tool that
> even itself can use.
>
> As you know, D interacts very poorly with the concepts of extensible
> libraries, for example, druntime is not even position independent, so it
> seems the advantages of library use was not in the mind set when D was
> first created. Imagine where this can be taken!

Yeah, but you can get pretty far with static libraries. Instead of the build tool running the compiler to determine the dependencies a library could provide that functionality. Preferably the compiler should be built around the same library.

> We really need a generally agreed on official road map for all the devs
> to follow. What I've seen so far focuses far too much on the language
> feature set alone, but the tools are a significant component of any
> language, so that part should not be taken so lightly. Time to change
> that mindset, somehow.

I absolutely agree.

-- 
/Jacob Carlborg

On 12/1/12, Rob T <rob@ucora.com> wrote:
> On Saturday, 1 December 2012 at 13:18:04 UTC, Jacob Carlborg wrote:
>> RDMD should be built as a library as well.
>
> I have to agree, rdmd should be a library.

RDMD is 700 lines, it practically is a library with the main function as its driver.

On 2012-12-02 17:49, Andrej Mitrovic wrote:

> RDMD is 700 lines, it practically is a library with the main function
> as its driver.

If a piece of code is a library or not has nothing to do with how many lines of code there is. The main function is almost 200 lines of code, way to much logic for a main function. Most functions and variables are private. I haven't look any more thoroughly than that.

-- 
/Jacob Carlborg