On 2012-11-28 16:51, Gor Gyolchanyan wrote:
> I think that would be a huge mistake. Why would anyone want to invent a
> full blown language and a big pain in the butt just to build a project
> if the project can build itself by looking at the source code?

Where on earth did I say anyone should invent a new language. I said use a separate file for the build script and use an already existing language like Ruby, Python, D or whatever.

On the other hand you and Andrei is starting to invent a new language. And you're putting them in comments. Talk about killing syntax highlighting.

-- 
/Jacob Carlborg

On 2012-11-28 17:23, Andrei Alexandrescu wrote:

> I disagree.

How would you handle the following with your comments:

* Platform specific flags
* Adding/ignoring certain files
* Invoking separate build systems to handle foreign languages
* Different flags for debug and release builds

That's just mentioning a few cases.

Also, in which source file would you put these special comments?

-- 
/Jacob Carlborg

On 11/27/2012 02:37 PM, Jesse Phillips wrote:
> On Tuesday, 27 November 2012 at 16:04:47 UTC, Andrei Alexandrescu wrote:
>
>> #!/usr/bin/rdmd
>> /**rdmdoptions
>> -L-lmylib
>> */
>> ...
>
> #!/usr/bin/rdmd
> @("compiler options", "-L-lmylib") module main;
> ...
>
> Maybe... sorry I don't know if this would work with current UDA.

pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");

On 2012-11-28 20:23, 1100110 wrote:

> pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");

How would the compiler handle flags which add new import paths? Should it first scan all source files after this special pragma(build). Then rescan the source files again to see if any new pragma(build) was found. Then, yet again, it need to rescan the files for the regular compile phase.

-- 
/Jacob Carlborg

On 2012-11-28 17:23, Andrei Alexandrescu wrote:

> I disagree.

Have you looked at the makefile for any of the D projects, how would you do that with your comments?

-- 
/Jacob Carlborg

awesome idea! and that can be put into static if-s and such!!


On Wed, Nov 28, 2012 at 11:23 PM, 1100110 <0b1100110@gmail.com> wrote:

> On 11/27/2012 02:37 PM, Jesse Phillips wrote:
>
>> On Tuesday, 27 November 2012 at 16:04:47 UTC, Andrei Alexandrescu wrote:
>>
>>  #!/usr/bin/rdmd
>>> /**rdmdoptions
>>> -L-lmylib
>>> */
>>> ...
>>>
>>
>> #!/usr/bin/rdmd
>> @("compiler options", "-L-lmylib") module main;
>> ...
>>
>> Maybe... sorry I don't know if this would work with current UDA.
>>
>
> pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");
>



-- 
Bye,
Gor Gyolchanyan.

On 11/28/12 2:20 PM, Jacob Carlborg wrote:
> On 2012-11-28 17:23, Andrei Alexandrescu wrote:
>
>> I disagree.
>
> How would you handle the following with your comments:
>
> * Platform specific flags * Adding/ignoring certain files * Invoking
> separate build systems to handle foreign languages * Different flags
> for debug and release builds
>
> That's just mentioning a few cases.
>
> Also, in which source file would you put these special comments?
>

The tool would have inherent limitations. What I disagree with is this
umbrella statement:

> What's needed
> is a proper build tool. That includes build scripts that can be
> written in a full blow language.

I recall you have written such a tool (Orbit), so it is natural to have a vested interest in promoting it and argue for its usefulness. Such arguments don't eliminate the need for simpler tools that obviate Orbit's use for a subset of cases.


Andrei

On 2012-11-28 20:39, Andrei Alexandrescu wrote:

> I recall you have written such a tool (Orbit), so it is natural to have
> a vested interest in promoting it and argue for its usefulness. Such
> arguments don't eliminate the need for simpler tools that obviate
> Orbit's use for a subset of cases.

1. Orbit is a package manager, not a build tool (although I'm developing that as well). A package manager deals with a packages, a build tool deals with files

2. I would not create a tool that cannot be used in the most simple uses cases. I'm thinking of scale. From the most simple use cases to the more advance use cases.

The build tool I'm developing will work like this. In it's most simple usage it can be used as:

$ build main.d

Which will do basically what RDMD does, but without running the executable. You can also pass arbitrary compile and link flags:

$ build main.d -release -L-lcurl

So far still just basically what RDMD does. The interesting thing is when you need to do more advanced build setups or avoiding repeating compile flags. Then you can start using a build script. The most simple build script will look something like this:

target :main

If there's a file named "main.d" it will build an executable, just like RDMD does. If there's a folder named "main" it will build a library of all files in that folder, recursively. Not something that RDMD can currently handle.

Adding some flags to the build script:

target :main do
  flags :build << "-release"
  flags :link << "-lcurl"
end

Then adding some special settings for a platform:

target :main do
  flags.build << "-release"
  flags.link << "-lcurl"

  if platform.windows
    flags.link << "some flag"
  end
end

Then adding a task for creating a release of the software:

task :release do
  # some code
end

-- 
/Jacob Carlborg

On 2012-11-28 20:39, Andrei Alexandrescu wrote:

> I recall you have written such a tool (Orbit), so it is natural to have
> a vested interest in promoting it and argue for its usefulness. Such
> arguments don't eliminate the need for simpler tools that obviate
> Orbit's use for a subset of cases.

BTW, I'm not arguing for this just because I'm building a tool. I'm arguing because the existing tools are not good enough, or does not do enough of what I want. RDMD is good enough for what it does, but it's not enough for what I need. I use it every day when compiling single or just a few source files.

I was a happy DSSS user back in the days of D1 and still are for the few projects I have left written in D1. I have no problem in using someones other tool if it does what I want. I'm just saying that if we want to have a standard/de facto build tool in the D community it needs be able to handle all kinds of projects, not just simple scripts. It do need to be able to handle those simple projects making it simple enough to use to be useful.

-- 
/Jacob Carlborg

On 11/28/2012 01:32 PM, Jacob Carlborg wrote:
> On 2012-11-28 20:23, 1100110 wrote:
>
>> pragma(build, "rdmd -Jviews -Isrc/debug --version=debug");
>
> How would the compiler handle flags which add new import paths? Should
> it first scan all source files after this special pragma(build). Then
> rescan the source files again to see if any new pragma(build) was found.
> Then, yet again, it need to rescan the files for the regular compile phase.
>

Oops, should have left off rdmd...  It was meant to be an alternate place for command-line flags.

Good question.  You could require it to be in the file passed to the compiler, which I like.  Or you could simply look for pragma(build) at the same time you look for imports.  look *once* per file.

I don't know how the compiler handles the arguments passed internally.
You know what? Just say it's in the file passed to rdmd.  If you need something more complex that a simple place to put the args, you need something bigger than what this can give.


rdmd main.d

cat main.d
module main

import std.stdio;
import std.string;
static import(file.jpg);//I forget the syntax...
pragma(build, "-jviews -src -O -release -inline");
pragma(lib, "ssl");
pragma(lib, "dl");
pragma(lib, "event_pthreads");

void main(){} blah blah blah...
EOF

If that doesn't cover 99% of your use-case, you obviously need something way bigger.

Tell people to compile using rdmd main.d.  If args are passed on the cmdline, then don't even bother looking for pragma(build).