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 identical every single time. DMD doesn't do this and it saddens me greatly.
>
> DMD doesn't? What does it do that isn't deterministic?

I have no idea. As a simple test, I compiled one my source files to an object file, and ran md5sum on it. I did this again and the md5sum is different. Looking at a diff of the hexdump isn't very fruitful either (for me at least). For reference, I'm on Linux x86_64 with DMD v2.071.0.

On Sat, Jun 18, 2016 at 08:46:30PM +0000, 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 consecutive invocations, without changing any source code, I want the hashes of the binaries to be identical every single time. DMD doesn't do this and it saddens me greatly.
> > 
> > DMD doesn't? What does it do that isn't deterministic?
> 
> I have no idea. As a simple test, I compiled one my source files to an object file, and ran md5sum on it. I did this again and the md5sum is different. Looking at a diff of the hexdump isn't very fruitful either (for me at least). For reference, I'm on Linux x86_64 with DMD v2.071.0.

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 same, sometimes different.  Repeating this several time reveals that the md5sum changes every second, meaning that the difference is a timestamp in the object file.

Maybe we could file an enhancement request for this?


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg

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 same, sometimes different.  Repeating this several time reveals that the md5sum changes every second, meaning that the difference is a timestamp in the object file.
>
> Maybe we could file an enhancement request for this?

Done: https://issues.dlang.org/show_bug.cgi?id=16185

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 a reasons mentioned.

> 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 example, `button shell -o build.sh`. Then just run `./build.sh` to build everything. I vaguely recall either Tup or Ninja having something like this.

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 can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution.

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 example, `button shell -o build.sh`. Then just run `./build.sh` to build everything. I vaguely recall either Tup or Ninja having something like this.
>
> 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 can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution.

I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either.

This should actually be pretty easy to implement.

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 can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution.
>
> I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either.
>
> This should actually be pretty easy to implement.

Will plain sh script script also work for MacOS / BSD flavors? Committing just two scripts is fine but I wonder how it scales.

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. Even if it is list of plain unconditional commands there are always differences like normalized path form. Of course, one can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution.
>>>
>>
>> I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either.
>>
>> This should actually be pretty easy to implement.
>>
>
> Will plain sh script script also work for MacOS / BSD flavors? Committing just two scripts is fine but I wonder how it scales.
>

Bash script should work with all. I also read that Microsoft is making bash for windows[1].

[1] http://www.theverge.com/2016/3/30/11331014/microsoft-windows-linux-ubuntu-bash

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 differences like normalized path form. Of course, one can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution.
>>
>> I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either.
>>
>> This should actually be pretty easy to implement.
>
> Will plain sh script script also work for MacOS / BSD flavors? Committing just two scripts is fine but I wonder how it scales.

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.

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 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 can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution.
>>>>
>>>
>>> I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either.
>>>
>>> This should actually be pretty easy to implement.
>>>
>>
>> Will plain sh script script also work for MacOS / BSD flavors? Committing just two scripts is fine but I wonder how it scales.
>>
>
> 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, if you wanted to try bash on windows:


[0]: https://msdn.microsoft.com/en-us/commandline/wsl/about

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, if you wanted to try bash on windows:
>
>
> [0]: https://msdn.microsoft.com/en-us/commandline/wsl/about

Thanks, but I'll be sticking to bash on Linux. ;)

I'll add Batch (and maybe PowerShell) output when Button is supported on Windows. It should be very easy.