View mode: basic / threaded / horizontal-split · Log in · Help
December 01, 2012
Re: Errors compiling DSSS
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
December 01, 2012
Re: Errors compiling DSSS
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
December 02, 2012
Re: Errors compiling DSSS
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
December 02, 2012
Re: Errors compiling DSSS
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
December 02, 2012
Re: Errors compiling DSSS
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.
December 03, 2012
Re: Errors compiling DSSS
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
Next ›   Last »
6 7 8 9 10
Top | Discussion index | About this forum | D home