Re: Bootstrap D template
On Friday, 2 February 2018 at 01:16:50 UTC, Seb wrote: `DEFAULT_GOAL` allows to set an explicit target and keep a everything nicely ordered. Thanks! (didn't even notice that line) Is something not working when you just type `make`? No Or are you just trying to understand how things work? Yes, sorry for the confusion. What are you planning to do? I was only trying to understand the Makefile.
Re: Bootstrap D template
On Thursday, 1 February 2018 at 23:35:43 UTC, Tony wrote: On Thursday, 1 February 2018 at 22:01:52 UTC, Mike Wey wrote: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html#Prerequisite-Types Thanks! Couldn't seem to get a search to work. I was hoping the "|" would explain the behavior that I don't understand, but I don't think it does. The instructions say to just type "make". My understanding is that without a specified target, the topmost target in the Makefile is used. In this case it is "bin", which has no dependencies, and one action - mkdir. I would think that the Makefile would stop after making that directory as no other actions are given and no dependencies were specified. But it doesn't. `DEFAULT_GOAL` allows to set an explicit target and keep a everything nicely ordered. Is something not working when you just type `make`? Or are you just trying to understand how things work? In the latter case: you don't need to use make, to build your files, I just use it for small projects because it's super easy. Anyhow there are other ways you could use this without needing to dive into make: - as a wrapper - call your actions from a new Makefile target and simply depend on the compiler (that's how I use dub in such projects) - execute `make` as part of your build script. It will fetch the compiler if non-existent and be a no-op otherwise. What are you planning to do?
Re: Bootstrap D template
On Thursday, 1 February 2018 at 22:01:52 UTC, Mike Wey wrote: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html#Prerequisite-Types Thanks! Couldn't seem to get a search to work. I was hoping the "|" would explain the behavior that I don't understand, but I don't think it does. The instructions say to just type "make". My understanding is that without a specified target, the topmost target in the Makefile is used. In this case it is "bin", which has no dependencies, and one action - mkdir. I would think that the Makefile would stop after making that directory as no other actions are given and no dependencies were specified. But it doesn't.
Re: Bootstrap D template
On 01-02-18 22:53, Tony wrote: On Monday, 29 January 2018 at 11:04:19 UTC, Seb wrote: https://github.com/wilzbach/d-bootstrap Happy bootstrapping! What does "|" do in a makefile? The target depends on `bin` but don't rebuild the target if `bin` is newer than the target. https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html#Prerequisite-Types -- Mike Wey
Re: Bootstrap D template
On Monday, 29 January 2018 at 11:04:19 UTC, Seb wrote: https://github.com/wilzbach/d-bootstrap Happy bootstrapping! What does "|" do in a makefile?
Re: Release D 2.078.1
On 23/01/2018 14:08, thedeemon wrote: On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak wrote: Glad to announce D 2.078.1. The Windows 7z archive version now has much simpler sc.ini, in fact too simple. With Visual C++ 2015 x64 Native Build Tools now trying to run dmd -m64 hi.d I get LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: linker exited with status 1104 So I needed to edit sc.ini and add back LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64" to the [Environment64] section. Then it went just as 2.078.0 - still missing legacy_stdio_definitions.lib that I need to add manually in the command line. Should be fixed by https://github.com/dlang/dmd/pull/7828 Let's hope it makes it into 2.078.2 this time (I didn't expect another point-release).
Re: Release D 2.078.1
On 01/02/2018 17:16, Atila Neves wrote: Should I file a bug for dmd or the installer? It's a dmd issue. https://issues.dlang.org/show_bug.cgi?id=18352 Thanks. https://github.com/dlang/dmd/pull/7827
Re: Beta 2.078.2
On Thursday, 1 February 2018 at 17:32:09 UTC, Andrew Benton wrote: On Thursday, 1 February 2018 at 16:01:18 UTC, Martin Nowak wrote: First beta for the 2.078.2 patch release. Contains a major regression fix for hashtable array comparison and comes with more reliable retries and fallback mirror usage for dub (https://github.com/dlang/dub/pull/1339). http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.078.2.html Please report any bugs at https://issues.dlang.org - -Martin Changelog page returns a 404 It got lost in the merge queue - https://github.com/dlang/dlang.org/pull/2158 I just merged it. It should be up in a few minutes.
Re: Beta 2.078.2
On Thursday, 1 February 2018 at 16:01:18 UTC, Martin Nowak wrote: First beta for the 2.078.2 patch release. Contains a major regression fix for hashtable array comparison and comes with more reliable retries and fallback mirror usage for dub (https://github.com/dlang/dub/pull/1339). http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.078.2.html Please report any bugs at https://issues.dlang.org - -Martin Changelog page returns a 404
Re: Release D 2.078.1
On Wednesday, 31 January 2018 at 19:09:03 UTC, Rainer Schuetze
wrote:
On 31/01/2018 16:58, Atila Neves wrote:
On Thursday, 25 January 2018 at 20:11:54 UTC, Rainer Schuetze
wrote:
On 25.01.2018 14:54, Atila Neves wrote:
On Tuesday, 23 January 2018 at 15:16:02 UTC, Andre Pany
wrote:
On Tuesday, 23 January 2018 at 13:08:35 UTC, thedeemon
wrote:
On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak
wrote:
Glad to announce D 2.078.1.
The Windows 7z archive version now has much simpler
sc.ini, in fact too simple.
With Visual C++ 2015 x64 Native Build Tools now trying to
run
dmd -m64 hi.d
I get
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104
So I needed to edit sc.ini and add back
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
to the [Environment64] section.
Then it went just as 2.078.0 - still missing
legacy_stdio_definitions.lib that I need to add manually
in the command line.
Did you call vcvarsall in the current dos box/PowerShell?
It is a tool included with all visual studio variants.
Kind regards
Andre
I just ran into this today. With the dmd 2.077.1 Windows
installer things just work, and it's never necessary to call
vcvarsall.bat to build D code for 64-bit.
Since dmd 2.078.0, with Visual Studio 2015, nothing works
anymore, and sc.ini doesn't seem to reference Visual Studio
at all like it used to.
Atila
Visual Studio is supposed to be detected by dmd now, either
from the environment or from the registry.
What errors do you get? Try running with -v to show the
linker command line.
$ dub init
$ dub build --arch=x86_64
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe
for x86_64.
example ~master: building configuration "application"...
Linking...
LINK : fatal error LNK1104: cannot open file 'shell32.lib'
-v shows that it's linking like so:
C:\D\dmd2\windows\bin\dmd.exe
-of.dub\build\application-debug-windows-x86_64-dmd_2078-70A25404824ECE07D24A9F4D03E746CD\example.exe .dub\build\application-debug-windows-x86_64-dmd_2078-70A25404824ECE07D24A9F4D03E746CD\example.obj -m64 -g
Unfortunately, that is not dmds output of the linker command
line, but dubs invocation of dmd. Just try "dmd -v -m64 test.d".
Sorry, I misunderstood what you meant. It's:
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\link.exe /NOLOGO app /OPT:NOICF
/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows
Kits\10\Lib\10.0.10240.0\ucrt\x64" legacy_stdio_definitions.lib
There are 3 shell32.lib files on my system, located at:
C:\Program Files (x86)\Windows
Kits\8.1\Lib\winv6.3\um\{arm,x64,x86}
Notice that it's similar to the path being used above. Given that
cl.exe doesn't have a problem running on my system I went and
looked at vcvarsall.bat expecting there to be checks for either
8.1 or 10. I was right, there's logic to figure it out.
It'd probably be easier to `executeShell("vcvarsall.bat")` than
trying to replicate the logic in dmd itself. It's bound to get it
wrong (as it has) and we don't have Microsoft's resources to test
backwards compatibility.
Does Arjan's suggestion help, i.e. are you working as a
restricted user? Did you install VS for the current user only
(not sure if that's actually possible)?
I've installed dmd 2.077.1 and dmd 2.078.1 now several times,
each time erasing the other. It's a regression.
Should I file a bug for dmd or the installer?
It's a dmd issue.
https://issues.dlang.org/show_bug.cgi?id=18352
Re: Release D 2.078.1
On Wednesday, 31 January 2018 at 16:35:59 UTC, Arjan wrote: On Wednesday, 31 January 2018 at 15:58:02 UTC, Atila Neves wrote: [...] By any chance, is this on a corperate machine? I've hit the same issue seems to do with enforced windows group-policy which disables registry access for certain type of applications at my place. No, regular Windows 10 with VS 2015. Even if it were, dmd 2.077.1 works fine, 2.078.0 and 2.078.1 do not. Atila
Beta 2.078.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 First beta for the 2.078.2 patch release. Contains a major regression fix for hashtable array comparison and comes with more reliable retries and fallback mirror usage for dub (https://github.com/dlang/dub/pull/1339). http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.078.2.html Please report any bugs at https://issues.dlang.org - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlpzOc0ACgkQsnOBFhK7 GTmGYw/6An60r/FOjUiK9btvaeAQxUxFYgnyv/dFzcrdZ5m6jYtfBhbrL0LfROHr G+pq2dpvwcSUAyUByj5XCVZ/D9/Rv8bwT+zZYueE09xpkRNNQRmlOZ3lUvzKy6bG xC16V89Q6FgOL3VI77u4ic3fQgNsGJE2PJ1NEbxiZTZxoyYPNDcEgaA4ijSk1VgT SrPjcr9dk57SRiXCb6wlC42LJ2cIEXUMKsvJ1vvHkK8ahVL+UpOvV1LGSPZMQvJF aPJM3V0NhJDOtmnOd+OvCv/TQdm4yhUttHKjTGyo5IZbHq5m8rU6gRKCyL30A3XB 3MXJyHTQJcYm74pPlHocIOr53CC8UjHsmGBBuKlD3c5AtpUzvKyci7ovFXsqFPcO iKmrYukWvNqv6Som1QPkWiQH/xPhKUTt7ulVi7CkHM7Uc9X970+zDwmoUcbRFwHL V6+DlTsNpfp6y6/WxAw2v7omMmdd7XYCwtvPTiFNhnEylEd8khj0LoHpR+pi7LzC jILSlCgDLnCdGhxTPyqHWoyIqohV9R6c7f+hJe4golsG87qC3GMIs5xqW8KHOxiv exSWlOKXSyS06XZJQ7mQGnQL4rLdIDA3g9Jh/WlxxmT5j7YFLR3i5j6G9heMv6GK Of1SCRY5vhdpFAsXNnuNxjQLRsEah1pxWV0xRrxply8BCV/e5ww= =VfAz -END PGP SIGNATURE-
Re: [howto] Serve ddox documentation on github.io deployed by Travis CI
(3) Docs from proposed site can be easily wrapped into DevDocs/Zeal/Dash docs for comfort offline usage.
Re: [howto] Serve ddox documentation on github.io deployed by Travis CI
On Saturday, 13 January 2018 at 11:42:42 UTC, Bastiaan Veelo wrote: On Saturday, 13 January 2018 at 10:02:18 UTC, Jacob Carlborg wrote: On 2018-01-13 05:59, Martin Nowak wrote: On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote: Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering? This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete. What do you mean with "taking care of it"? Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well. Yes that is what I meant, sorry for being vague. It’s been suggested before I think. It would be a lot more work than what you are suggesting and one does not have to exclude the other: a bot could clone the project repositories and generate documentation for each, without project owners needing to manage tokens. I like this idea because: 1) it is more secure than allow to access Travis CI to my public repos 2) this can encourage writing documentation in those projects that not thinked about documentation
