View mode: basic / threaded / horizontal-split · Log in · Help
November 27, 2012
Re: Errors compiling DSSS
The benefit is standardization. There will no longer be an annoying mess of
tons of different build systems with tons of different rules. This is the
same reason why there's DDOC and not external tool.


On Tue, Nov 27, 2012 at 4:24 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-27 08:47, Gor Gyolchanyan wrote:
>
>> Just like DDOC adds auxiliary information to create documentation, build
>> comments would add auxiliary information to create build scripts (which
>> a tool could just use right away without generating garbage in the form
>> of build script files).
>>
>
> These special comments would just be the build script. I see no advantage
> of having any form of special comments for a build tool. The only advantage
> could be if you only have a single source file, then you can safe a file by
> combining the source file and build file.
>
> Besides from this, it would be just like any other build script. If you
> put the build configuration in a separate build script you can much easier
> use whatever full blown language you want, Ruby, Python or even D. I can
> assure you, there's no point in trying to invent a new "language" for these
> kind of things.
>
> --
> /Jacob Carlborg
>



-- 
Bye,
Gor Gyolchanyan.
November 27, 2012
Re: Errors compiling DSSS
On 2012-11-27 13:35, Gor Gyolchanyan wrote:
> The benefit is standardization. There will no longer be an annoying mess
> of tons of different build systems with tons of different rules. This is
> the same reason why there's DDOC and not external tool.

I don't think it's right to add a build tool to the compiler. There can 
be a standard built tool even if it's not in the compiler.

-- 
/Jacob Carlborg
November 27, 2012
Re: Errors compiling DSSS
On 2012-11-27 13:42, Jacob Carlborg wrote:

> I don't think it's right to add a build tool to the compiler. There can
> be a standard built tool even if it's not in the compiler.

I mean, DSSS was basically the standard build tool back in the D1 days. 
Unfortunately it's not maintained any more. One problem with DSSS was 
that it used its own copy of the DMD front end. This was before the 
compiler got the "-deps" swithc, which is what RDMD uses.

It doesn't help that the compiler is poorly designed/structured with no 
regard to support third party tools using the compiler as a library.

-- 
/Jacob Carlborg
November 27, 2012
Re: Errors compiling DSSS
There's a good reason why all libraries come with their build scripts,
rather then rely on the client to build them as necessary. The reason is
that the source code is where the necessary building conditions are
defined, even if as a separate file. You can't write anything more, then a
100 LOC source file without having to make a build script. The source files
in a project heavily depend on the build script to produce the correct
result. This is why I don't see any reason why building process should be
separated from the source code.


On Tue, Nov 27, 2012 at 4:42 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-27 13:35, Gor Gyolchanyan wrote:
>
>> The benefit is standardization. There will no longer be an annoying mess
>> of tons of different build systems with tons of different rules. This is
>> the same reason why there's DDOC and not external tool.
>>
>
> I don't think it's right to add a build tool to the compiler. There can be
> a standard built tool even if it's not in the compiler.
>
> --
> /Jacob Carlborg
>



-- 
Bye,
Gor Gyolchanyan.
November 27, 2012
Re: Errors compiling DSSS
On 2012-11-27 13:50, Gor Gyolchanyan wrote:
> There's a good reason why all libraries come with their build scripts,
> rather then rely on the client to build them as necessary. The reason is
> that the source code is where the necessary building conditions are
> defined, even if as a separate file. You can't write anything more, then
> a 100 LOC source file without having to make a build script. The source
> files in a project heavily depend on the build script to produce the
> correct result. This is why I don't see any reason why building process
> should be separated from the source code.

I don't understand what you're saying. Of course the build scripts need 
to be shipped with the library. I just don't think you should put the 
build script inline with the source code. I think it should be a 
separate file.

-- 
/Jacob Carlborg
November 27, 2012
Re: Errors compiling DSSS
Why do you think so? The build script is inseparable from the project
source files. What makes the build script necessary to be separate?


On Tue, Nov 27, 2012 at 7:42 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-27 13:50, Gor Gyolchanyan wrote:
>
>> There's a good reason why all libraries come with their build scripts,
>> rather then rely on the client to build them as necessary. The reason is
>> that the source code is where the necessary building conditions are
>> defined, even if as a separate file. You can't write anything more, then
>> a 100 LOC source file without having to make a build script. The source
>> files in a project heavily depend on the build script to produce the
>> correct result. This is why I don't see any reason why building process
>> should be separated from the source code.
>>
>
> I don't understand what you're saying. Of course the build scripts need to
> be shipped with the library. I just don't think you should put the build
> script inline with the source code. I think it should be a separate file.
>
> --
> /Jacob Carlborg
>



-- 
Bye,
Gor Gyolchanyan.
November 27, 2012
Re: Errors compiling DSSS
On 11/27/12 5:44 AM, Robert wrote:
>
>>
>>                  On 2012-11-27 08:13, Gor Gyolchanyan wrote:
>>                          I'd recommend RDMD. It can compile (and run)
>>                          the given module and it's
>>                          entire import tree. No build scripts are
>>                          necessary.
>>                          Very convenient with pragma(lib, "...")
>
> Btw. if you you use rdmd via sha-bang, there is no way of passing any
> compiler flags in the #! line (because only a single arg is supported:
> http://en.wikipedia.org/wiki/Shebang_%28Unix%29

Thats why I included the --shebang flag in rdmd.

Andrei
November 27, 2012
Re: Errors compiling DSSS
On 2012-11-27 16:50, Gor Gyolchanyan wrote:
> Why do you think so? The build script is inseparable from the project
> source files. What makes the build script necessary to be separate?

In which source file would you put the build script?

As I said before. I think it's easier to have the build script in a full 
blown language if it's a separate file.

I would also think that one could have various tasks in a build script. 
For example: running tests, generating documentation and so on.

-- 
/Jacob Carlborg
November 27, 2012
Re: Errors compiling DSSS
On 11/27/12 7:35 AM, Gor Gyolchanyan wrote:
> The benefit is standardization. There will no longer be an annoying mess
> of tons of different build systems with tons of different rules. This is
> the same reason why there's DDOC and not external tool.

Even with --shebang there are odd limitations of the shebang line length 
etc. I think it would make sense to add options in the form of a 
stylized comment below the shebang line. That comment can be read and 
parsed by rdmd appropriately. For example:

#!/usr/bin/rdmd
/**rdmdoptions
-L-lmylib
*/
...

What would be some useful options to add, aside from those already 
supported?


Andrei
November 27, 2012
Re: Errors compiling DSSS
On 11/27/12 10:42 AM, Jacob Carlborg wrote:
> On 2012-11-27 13:50, Gor Gyolchanyan wrote:
>> There's a good reason why all libraries come with their build scripts,
>> rather then rely on the client to build them as necessary. The reason is
>> that the source code is where the necessary building conditions are
>> defined, even if as a separate file. You can't write anything more, then
>> a 100 LOC source file without having to make a build script. The source
>> files in a project heavily depend on the build script to produce the
>> correct result. This is why I don't see any reason why building process
>> should be separated from the source code.
>
> I don't understand what you're saying. Of course the build scripts need
> to be shipped with the library. I just don't think you should put the
> build script inline with the source code. I think it should be a
> separate file.

I think it's best to offer the choice.

Andrei
1 2 3 4 5 6
Top | Discussion index | About this forum | D home