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.

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

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

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.

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

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.

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

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

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

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