On Monday, 27 June 2016 at 06:43:26 UTC, Rory McGuire wrote:
FYI, I implemented this feature today (no Batch/PowerShell
output yet
though):
http://jasonwhite.github.io/button/docs/commands/convert
I think Bash should work on most Unix-like platforms.
And there is this[0] for windows,
On Mon, Jun 27, 2016 at 2:23 AM, Jason White via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Monday, 20 June 2016 at 08:21:29 UTC, Dicebot wrote:
>
>> On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote:
>>
>>> This actually sounds nice. Main problem that
On Monday, 20 June 2016 at 08:21:29 UTC, Dicebot wrote:
On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote:
This actually sounds nice. Main problem that comes to my mind
is that there is no cross-platform shell script. Even if it
is list of plain unconditional commands there are always
On Mon, Jun 20, 2016 at 10:21 AM, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote:
>
>> This actually sounds nice. Main problem that comes to my mind is that
>>> there is no cross-platform shell script.
On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote:
This actually sounds nice. Main problem that comes to my mind
is that there is no cross-platform shell script. Even if it is
list of plain unconditional commands there are always
differences like normalized path form. Of course, one
On Sunday, 19 June 2016 at 15:47:21 UTC, Dicebot wrote:
Let me propose another idea where maybe we can remove the
extra dependency for new codebase collaborators but still have
access to a full-blown build system: Add a sub-command to
Button that produces a shell script to run the build. For
On Saturday, 18 June 2016 at 08:05:18 UTC, Jason White wrote:
I realize you might be playing devil's advocate a bit and I
appreciate it.
Yeah, I personally quite like how Button looks and would totally
consider it, probably with some tweaks of own taste. But not for
most public projects for
On Saturday, 18 June 2016 at 23:52:00 UTC, H. S. Teoh wrote:
I did a quick investigation, which found something interesting.
If compiling straight to executable, the executable is
identical each time with the same md5sum. However, when
compiling to object files, the md5sum is sometimes the
On Sat, Jun 18, 2016 at 08:46:30PM +, Jason White via
Digitalmars-d-announce wrote:
> On Saturday, 18 June 2016 at 14:23:39 UTC, H. S. Teoh wrote:
> > > Moral of the story is, if you're writing a compiler, for the sake
> > > of build systems everywhere, make the output deterministic! For
> >
On Saturday, 18 June 2016 at 14:23:39 UTC, H. S. Teoh wrote:
Moral of the story is, if you're writing a compiler, for the
sake of build systems everywhere, make the output
deterministic! For consecutive invocations, without changing
any source code, I want the hashes of the binaries to be
On Sat, Jun 18, 2016 at 08:38:21AM +, Jason White via
Digitalmars-d-announce wrote:
> On Friday, 17 June 2016 at 20:36:53 UTC, H. S. Teoh wrote:
> > - Assuming that a revision control system is in place, and a
> > workspace is checked out on revision X with no further
> > modifications,
On Friday, 17 June 2016 at 20:36:53 UTC, H. S. Teoh wrote:
- Assuming that a revision control system is in place, and a
workspace is checked out on revision X with no further
modifications, then invoking the build tool should ALWAYS,
without any exceptions, produce exactly the same
On Friday, 17 June 2016 at 10:24:16 UTC, Dicebot wrote:
However, I question the utility of even doing this in the
first place. You miss out on the convenience of using the
existing command line interface. And for what? Just so
everything can be in D? Writing the same thing in Lua would be
On Friday, 17 June 2016 at 20:59:46 UTC, jmh530 wrote:
I found the beginning of the tutorial very clear. I really
liked that it can produce a png of the build graph. I also
liked the Lua build description for DMD. Much more legible than
the make file.
However, once I got to the "Going Meta:
On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
Note that this is still a ways off from being production-ready.
It needs some polishing. Feedback would be most appreciated
(file some issues!). I really want to make this one of the best
build systems out there.
I found the
On Fri, Jun 17, 2016 at 07:30:42PM +, Fool via Digitalmars-d-announce wrote:
> On Friday, 17 June 2016 at 08:23:50 UTC, Atila Neves wrote:
> > I agree, but CMake/ninja, tup, regga/ninja, reggae/binary are all
> > correct _and_ fast.
>
> 'Correct' referring to which standards? There is an
On Friday, 17 June 2016 at 08:23:50 UTC, Atila Neves wrote:
I agree, but CMake/ninja, tup, regga/ninja, reggae/binary are
all correct _and_ fast.
'Correct' referring to which standards? There is an interesting
series of blog posts by Mike Shal:
On 06/17/2016 06:20 PM, H. S. Teoh via Digitalmars-d-announce wrote:
>> If you happen to be unlucky enough to work on a project so large you
>> need to watch the file system, then use the tup backend I guess.
> [...]
>
> Yes, I'm pretty sure that describes a lot of software projects out there
>
On Fri, Jun 17, 2016 at 09:00:45AM +, Atila Neves via
Digitalmars-d-announce wrote:
> On Friday, 17 June 2016 at 06:18:28 UTC, H. S. Teoh wrote:
> > On Fri, Jun 17, 2016 at 05:41:30AM +, Jason White via
> > Digitalmars-d-announce wrote: [...]
> > > Where Make gets slow is when checking
However, I question the utility of even doing this in the first
place. You miss out on the convenience of using the existing
command line interface. And for what? Just so everything can be
in D? Writing the same thing in Lua would be much prettier. I
don't understand this dependency-phobia.
On Friday, 17 June 2016 at 04:54:37 UTC, Jason White wrote:
Why the build script can't have a command line interface?
It could, but now the build script is a more complicated and
for little gain.
It's only as complicated to implement required features and not
more complicated. If the
On Friday, 17 June 2016 at 06:18:28 UTC, H. S. Teoh wrote:
On Fri, Jun 17, 2016 at 05:41:30AM +, Jason White via
Digitalmars-d-announce wrote: [...]
Where Make gets slow is when checking for changes on a ton of
files. I haven't tested it, but I'm sure Button is faster than
Make in this
On Friday, 17 June 2016 at 05:41:30 UTC, Jason White wrote:
On Thursday, 16 June 2016 at 13:39:20 UTC, Atila Neves wrote:
It would be a worthwhile trade-off, if those were the only two
options available, but they're not. There are multiple build
systems out there that do correct builds whilst
On Friday, 17 June 2016 at 06:18:28 UTC, H. S. Teoh wrote:
For me, correctness is far more important than speed. Mostly
because at my day job, we have a Make-based build system and
because of Make's weaknesses, countless hours, sometimes even
days, have been wasted running `make clean; make`
On Fri, Jun 17, 2016 at 05:41:30AM +, Jason White via
Digitalmars-d-announce wrote:
[...]
> Where Make gets slow is when checking for changes on a ton of files. I
> haven't tested it, but I'm sure Button is faster than Make in this
> case because it checks for changed files using multiple
On Thursday, 16 June 2016 at 13:39:20 UTC, Atila Neves wrote:
It would be a worthwhile trade-off, if those were the only two
options available, but they're not. There are multiple build
systems out there that do correct builds whilst being faster
than make. Being faster is easy, because make
On Thursday, 16 June 2016 at 12:34:26 UTC, Kagamin wrote:
On Sunday, 12 June 2016 at 23:27:07 UTC, Jason White wrote:
However, I question the utility of even doing this in the
first place. You miss out on the convenience of using the
existing command line interface.
Why the build script
On Thursday, 16 June 2016 at 13:40:39 UTC, Atila Neves wrote:
The idea would be to build reggae with the system dmd first
(since having a D compiler is now a pre-requisite)
If a D compiler is required, it means a prebuilt executable is
not needed: rdmd should be enough to compile and run the
On Thursday, 16 June 2016 at 12:32:02 UTC, Kagamin wrote:
On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote:
Yeah, I have often thought that writing a self-contained D
program to build D would work well. The full power of the
language would be available, there'd be nothing new to learn,
On Thursday, 16 June 2016 at 04:26:24 UTC, Jason White wrote:
On Wednesday, 15 June 2016 at 12:00:52 UTC, Andrei Alexandrescu
wrote:
I'd say the gating factor is -j. If an build system doesn't
implement the equivalent of make -j, that's a showstopper.
Don't worry, there is a --threads option
On Thursday, 16 June 2016 at 12:32:02 UTC, Kagamin wrote:
On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote:
Yeah, I have often thought that writing a self-contained D
program to build D would work well. The full power of the
language would be available, there'd be nothing new to learn,
On Thursday, 16 June 2016 at 12:53:35 UTC, John Colvin wrote:
On Thursday, 16 June 2016 at 12:32:02 UTC, Kagamin wrote:
On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote:
Yeah, I have often thought that writing a self-contained D
program to build D would work well. The full power of the
On Sunday, 12 June 2016 at 23:27:07 UTC, Jason White wrote:
However, I question the utility of even doing this in the first
place. You miss out on the convenience of using the existing
command line interface.
Why the build script can't have a command line interface?
On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote:
Yeah, I have often thought that writing a self-contained D
program to build D would work well. The full power of the
language would be available, there'd be nothing new to learn,
and all you'd need is an existing D compiler (which we
On Wednesday, 15 June 2016 at 12:02:56 UTC, Andrei Alexandrescu
wrote:
In all likelihood. One issue with build systems is there's no
clear heir to make. There are so many, including a couple (!)
by our community, each with its pros and cons. Which one should
we choose?
You should choose
On Wednesday, 15 June 2016 at 12:00:52 UTC, Andrei Alexandrescu
wrote:
I'd say the gating factor is -j. If an build system doesn't
implement the equivalent of make -j, that's a showstopper.
Don't worry, there is a --threads option and it defaults to the
number of logical cores.
I just did
On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu
wrote:
On 06/15/2016 08:05 AM, John Colvin wrote:
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright
wrote:
On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
How about using reggae?
On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu
wrote:
On 06/15/2016 08:05 AM, John Colvin wrote:
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright
wrote:
On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
How about using reggae?
On 06/15/2016 08:05 AM, John Colvin wrote:
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote:
On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
How about using reggae?
https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
I haven't studied either.
If you do study that
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote:
On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
How about using reggae?
https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
I haven't studied either.
If you do study that reggae file, remember that it's a deliberate
On 6/15/16 1:42 AM, Jason White wrote:
On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:
On 6/12/2016 4:27 PM, Jason White wrote:
I don't understand this dependency-phobia.
It's the "first 5 minutes" thing. Every hiccup there costs us maybe
half the people who just want to try it
On 6/15/16 1:29 AM, Jason White wrote:
On Tuesday, 14 June 2016 at 14:57:52 UTC, Andrei Alexandrescu wrote:
On 6/12/16 8:27 PM, Walter Bright wrote:
On 5/30/2016 12:16 PM, Jason White wrote:
Here is an example build description for DMD:
On Wednesday, 15 June 2016 at 05:42:21 UTC, Jason White wrote:
On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:
On 6/12/2016 4:27 PM, Jason White wrote:
I don't understand this dependency-phobia.
It's the "first 5 minutes" thing. Every hiccup there costs us
maybe half the
On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
How about using reggae?
https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
I haven't studied either.
On Monday, 13 June 2016 at 00:27:47 UTC, Walter Bright wrote:
On 5/30/2016 12:16 PM, Jason White wrote:
Here is an example build description for DMD:
https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua
I'd say that's a lot easier to read than this crusty thing:
On Wednesday, 15 June 2016 at 05:04:28 UTC, Jason White wrote:
If you want to depend on the compiler version, then you can add
a dependency on the compiler executable. It might be a good
idea to have Button do this automatically for every command.
That is, finding the path to the command's
On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:
On 6/12/2016 4:27 PM, Jason White wrote:
I don't understand this dependency-phobia.
It's the "first 5 minutes" thing. Every hiccup there costs us
maybe half the people who just want to try it out.
I suppose you're right. It is
On Tuesday, 14 June 2016 at 14:57:52 UTC, Andrei Alexandrescu
wrote:
On 6/12/16 8:27 PM, Walter Bright wrote:
On 5/30/2016 12:16 PM, Jason White wrote:
Here is an example build description for DMD:
https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua
I'd say that's a lot easier
On Wed, Jun 15, 2016 at 05:04:28AM +, Jason White via
Digitalmars-d-announce wrote:
> On Tuesday, 14 June 2016 at 10:47:58 UTC, Fool wrote:
[...]
> > A possible use case is creating object files first and packing them
> > into a library as a second step. Then single object files are of not
>
On Tuesday, 14 June 2016 at 10:47:58 UTC, Fool wrote:
Switching the compiler version seems to be a valid use case.
You might have other means to detect this, though.
If you want to depend on the compiler version, then you can add a
dependency on the compiler executable. It might be a good
On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:
On 6/12/2016 4:27 PM, Jason White wrote:
I don't understand this dependency-phobia.
It's the "first 5 minutes" thing. Every hiccup there costs us
maybe half the people who just want to try it out.
...
The makefiles, especially
On 6/12/16 8:27 PM, Walter Bright wrote:
On 5/30/2016 12:16 PM, Jason White wrote:
Here is an example build description for DMD:
https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua
I'd say that's a lot easier to read than this crusty thing:
On 2016-06-14 14:04, drug wrote:
I don't agree if you don't mind. I have two almost identical
implementation of the same thing in D and C++. And if I rebuild them
totally - yes, dmd is faster than gcc:
dmd5 secs
ldmd2 6 secs
make 40 secs
make -j10 11 secs
But
14.06.2016 13:04, ketmar пишет:
On Tuesday, 14 June 2016 at 07:45:10 UTC, Jacob Carlborg wrote:
I couldn't agree more. With the D compiler being so fast it's
reasonable to just recompile everything at once instead of trying to
track what's changed.
i'm agree with that. i'm so used to do just
On Sunday, 12 June 2016 at 22:59:15 UTC, Jason White wrote:
- "system1: Dependency on system information" (Because tasks
with no dependencies are only run once. This could be changed
easily enough, but I don't see the point.)
Switching the compiler version seems to be a valid use case. You
On 2016-06-13 22:12, Walter Bright wrote:
It's the "first 5 minutes" thing. Every hiccup there costs us maybe half
the people who just want to try it out.
Even the makefiles have hiccups. I've had builds fail with the dmd
system because I had the wrong version of make installed. And it doesn't
On 6/12/2016 4:27 PM, Jason White wrote:
I don't understand this dependency-phobia.
It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the
people who just want to try it out.
Even the makefiles have hiccups. I've had builds fail with the dmd system
because I had the
On 5/30/2016 12:16 PM, Jason White wrote:
Here is an example build description for DMD:
https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua
I'd say that's a lot easier to read than this crusty thing:
https://github.com/dlang/dmd/blob/master/src/posix.mak
Yes, the syntax
On Sunday, 12 June 2016 at 20:03:06 UTC, Walter Bright wrote:
On 6/3/2016 1:26 AM, Dicebot wrote:
From that perspective, the best build system you could
possibly have would look
like this:
```
#!/usr/bin/rdmd
import std.build;
// define your build script as D code
```
Yeah, I have often
On Sunday, 12 June 2016 at 20:03:06 UTC, Walter Bright wrote:
On 6/3/2016 1:26 AM, Dicebot wrote:
From that perspective, the best build system you could
possibly have would look
like this:
```
#!/usr/bin/rdmd
import std.build;
// define your build script as D code
```
Yeah, I have often
On 6/3/2016 1:26 AM, Dicebot wrote:
From that perspective, the best build system you could possibly have would look
like this:
```
#!/usr/bin/rdmd
import std.build;
// define your build script as D code
```
Yeah, I have often thought that writing a self-contained D program to build D
would
On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
I am pleased to finally announce the build system I've been
slowly working on for over a year in my spare time:
Docs: http://jasonwhite.github.io/button/
Source: https://github.com/jasonwhite/button
Features:
- Correct
On Saturday, 11 June 2016 at 02:48:59 UTC, H. S. Teoh wrote:
Finally got around to looking at this (albeit just briefly). It
looks very nice! Perhaps I'll try using it for my next project.
If you do end up using it, I'd be happy to iron out any
irritations in Button that you encounter.
On Mon, May 30, 2016 at 07:16:50PM +, Jason White via
Digitalmars-d-announce wrote:
> I am pleased to finally announce the build system I've been slowly
> working on for over a year in my spare time:
>
> Docs: http://jasonwhite.github.io/button/
> Source:
On Wednesday, 1 June 2016 at 04:34:23 UTC, Jason White wrote:
Why is having dependencies so damaging for build systems? Does
it really matter with a package manager like Dub? If there is
another thread that answers these questions, please point me to
it.
Rephrasing one famous advice, "every
On 2016-06-01 08:48, Jason White wrote:
Actually, SQLite more of a run-time dependency because etc.c.sqlite3
comes with DMD.
$ ldd button
linux-vdso.so.1 (0x7ffcc474c000)
--> libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x7f2d13641000)
libpthread.so.0 =>
On Wednesday, 1 June 2016 at 06:41:17 UTC, Jacob Carlborg wrote:
So, Lua is a build dependency? Seems that Sqlite is a build
dependency as well.
Actually, SQLite more of a run-time dependency because
etc.c.sqlite3 comes with DMD.
$ ldd button
linux-vdso.so.1 (0x7ffcc474c000)
-->
On 2016-06-01 06:34, Jason White wrote:
Building it only requires dmd+phobos+dub.
Why is having dependencies so damaging for build systems? Does it really
matter with a package manager like Dub? If there is another thread that
answers these questions, please point me to it.
The two
On Tuesday, 31 May 2016 at 14:28:02 UTC, Dicebot wrote:
Can it be built from just plain dmd/phobos install available?
One of major concernc behind discussion that resulted in Atila
reggae effort is that propagating additional third-party
dependencies is very damaging for build systems. Right
On Tuesday, 31 May 2016 at 10:15:14 UTC, Atila Neves wrote:
On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
I am pleased to finally announce the build system I've been
slowly working on for over a year in my spare time:
snip
In fact, there is some experimental support for automatic
On Tuesday, 31 May 2016 at 03:40:32 UTC, rikki cattermole wrote:
Are you on Freenode (no nick to name right now)?
I would like to talk to you about a few ideas relating to lua
and D.
No, I'm not on IRC. I'll see if I can find the time to hop on
this weekend.
Can it be built from just plain dmd/phobos install available? One of
major concernc behind discussion that resulted in Atila reggae effort is
that propagating additional third-party dependencies is very damaging
for build systems. Right now Button seems to fail rather hard on this
front (i.e. Lua
On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
I am pleased to finally announce the build system I've been
slowly working on for over a year in my spare time:
snip
In fact, there is some experimental support for automatic
conversion of Makefiles to Button's build description
On 31/05/2016 7:16 AM, Jason White wrote:
I am pleased to finally announce the build system I've been slowly
working on for over a year in my spare time:
Docs: http://jasonwhite.github.io/button/
Source: https://github.com/jasonwhite/button
Features:
- Correct incremental builds.
-
On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
I am pleased to finally announce the build system I've been
slowly working on for over a year in my spare time:
[...]
[snip]
Button:
- https://github.com/jasonwhite/darg (A command-line parser)
- https://github.com/jasonwhite/io
On Monday, 30 May 2016 at 20:58:51 UTC, poliklosio wrote:
- Lua is the primary build description language.
Why not D?
Generating the JSON build description should entirely
deterministic. With Lua, this can be guaranteed. You can create a
sandbox where only certain operations are permitted.
On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
I am pleased to finally announce the build system I've been
slowly working on for over a year in my spare time:
Docs: http://jasonwhite.github.io/button/
Source: https://github.com/jasonwhite/button
Great news! Love to see
I am pleased to finally announce the build system I've been
slowly working on for over a year in my spare time:
Docs: http://jasonwhite.github.io/button/
Source: https://github.com/jasonwhite/button
Features:
- Correct incremental builds.
- Automatic dependency detection (for any
78 matches
Mail list logo
