On Tuesday, 29 January 2019 at 23:09:57 UTC, Christian Köstlin wrote:
> I was surprised how simple it is nowadays even in osx.

Okay, there's definitely something odd going on with my set up. I followed your directions to the letter and OPTLINK barfed. Here is the output from my first try to compile:

d:\example\gtkdtest>dub run
Fetching gtk-d 3.8.5 (getting selected version)...
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86.
gtk-d:gtkd 3.8.5: building configuration "library"...
gtk-d:gstreamer 3.8.5: building configuration "library"...
gtk-d:peas 3.8.5: building configuration "library"...
gtk-d:sv 3.8.5: building configuration "library"...
gtk-d:vte 3.8.5: building configuration "library"...
gtkdtest ~master: building configuration "application"...
Linking...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\Users\ron\AppData\Local\dub\packages\gtk-d-3.8.5\gtk-d\.dub\build\library-debug-windows-x86-dmd_2082-CDBC653BD18B82F232E46588811160FC\gtkd-3.lib
 Warning 178: .LIB pagesize exceeds 512
Running .\gtkdtest.exe
Edit source/app.d to start your project.

And after double-checking, I did it again with this result:

d:\gtkdtest>dub run --force
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86.
gtk-d:gtkd 3.8.5: building configuration "library"...
gtk-d:gstreamer 3.8.5: building configuration "library"...
gtk-d:peas 3.8.5: building configuration "library"...
gtk-d:sv 3.8.5: building configuration "library"...
gtk-d:vte 3.8.5: building configuration "library"...
gtkdtest ~master: building configuration "application"...
Linking...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\Users\ron\AppData\Local\dub\packages\gtk-d-3.8.5\gtk-d\.dub\build\library-debug-windows-x86-dmd_2082-CDBC653BD18B82F232E46588811160FC\gtkd-3.lib
 Warning 178: .LIB pagesize exceeds 512
Error: linker exited with status 1
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.

Those were from the standard command shell. I tried it with Git Bash as well and got the same results.

And that's why I haven't been using dub. I got things to work with dmd and like they say, if it ain't broke... :)

You said you're on OSX, right? Is it possible that dub just isn't as cooperative on Windows 10? Of course, if you can see something in this output that hints at a fix, please let me know.

On Wednesday, 30 January 2019 at 09:48:14 UTC, Ron Tarrant wrote:
> On Saturday, 26 January 2019 at 16:53:18 UTC, Antonio Corbi wrote:
>> [1] https://sites.google.com/site/gtkdtutorial/
>> [2] http://britseyeview.com/software/articles/gsgtkd.html
>> [3] https://gitlab.com/csoriano/GtkDApp
>
> Took a look this morning. I'd come across the Brit's Eye View articles, but not the others. As I'm about to write something on menus, these will definitely come in handy.
>
> Thanks, Antonio.

You are welcome, :)

Antonio

On 2019-01-30 11:35, Ron Tarrant wrote:

> You said you're on OSX, right? Is it possible that dub just isn't as cooperative on Windows 10? Of course, if you can see something in this output that hints at a fix, please let me know.

It's Optlink being stupid as always. If you want to figure out what's wrong you can invoke Dub with the "--verbose" flag to have it print the commands it's running, i.e. how it's invoking the compiler and the linker. You can do the same thing when invoking the compiler manually by adding "-v" to see how it links the application and compare that with Dub.

Or, you can try compiling as COFF instead of OMF which will not use Optlink. Add the flag "--arch=x86mscoff" when invoking Dub.

-- 
/Jacob Carlborg

On 2019-01-30 03:00, Neia Neutuladh wrote:

> Might I recommend instead:
> 
>      dependency "gtk-d" version="3.8.5"
> 
> This depends on gtk-d 3.8.5 and only that version. If there is a breaking
> change in 3.8.6 despite semantic versioning, your code keeps working.
> 
> In libraries, I prefer using ~> to give more freedom to people depending
> on my code. But in applications, that isn't a concern. May as well only
> allow the code to be built with the versions of your dependencies that
> you've actually tested.

That's what the dub.selections.json file is for. It will lock down the version of all dependencies, direct and indirect dependencies.

For applications the dub.selections.json should be under version control, while for libraries it should be ignored.

-- 
/Jacob Carlborg

On 30-01-2019 21:07, Jacob Carlborg wrote:
> On 2019-01-30 11:35, Ron Tarrant wrote:
> 
>> You said you're on OSX, right? Is it possible that dub just isn't as cooperative on Windows 10? Of course, if you can see something in this output that hints at a fix, please let me know.
> 
> It's Optlink being stupid as always. If you want to figure out what's wrong you can invoke Dub with the "--verbose" flag to have it print the commands it's running, i.e. how it's invoking the compiler and the linker. You can do the same thing when invoking the compiler manually by adding "-v" to see how it links the application and compare that with Dub.
> 
> Or, you can try compiling as COFF instead of OMF which will not use Optlink. Add the flag "--arch=x86mscoff" when invoking Dub.
> 

This is whats going on: https://issues.dlang.org/show_bug.cgi?id=15418

To work around this you can either build things with "--arch=x86mscoff" or tell dub not to build the debug version with "--build=plain".

-- 
Mike Wey

On Friday, 25 January 2019 at 21:16:59 UTC, Ron Tarrant wrote:
> Hi y'all,
>
> As of January 11, 2019, http://gtkdcoding.com is up. It's a blog, it's a github page, it's simple examples of how to use GtkD for all that GUI stuff.
>
> My approach is to lay out a firm foundation for both imperative and object-oriented paradigms, then build from there, taking things one step at a time.
>
> This being Friday, the 4th post went up this morning. Please do let me know if you find it useful.
>
> And why did I wait until now to announce? Well, on day one, it seemed a bit silly to announce with only one post. After the second and third, well... I still didn't feel there was enough to warrant excitement. But four posts? Now that's something to speak up about, ain't it?
>
> Yup. That's what I thought, too.

Some simple screenshots would be nice to see -- but good job on this. Nice to see examples/how-to's. Hope you keep going into complex topics.

On Wednesday, 30 January 2019 at 21:53:27 UTC, sanjayss wrote:

> Some simple screenshots would be nice to see

I thought about it, but then realized that even though it would add visual appeal, readers might be more inclined to actually follow along at home if the only visual they get is the one they produce themselves. :)

> -- but good job on this. Nice to see examples/how-to's. Hope you keep going into complex topics.

Thanks for the kind words, sanjayss.

Yup, I'll be moving into complex subjects as things progress. I'm already working on a few behind the scenes, as it were. It seems I need lots of lead time to find a concept, outline it, write it, then rewrite it 1242 times so it's the best I can do. And like a good roast, it has to 'rest' for a while before I can see all the glaring faux pas and correct them... if you know what I mean. :)

Thanks for reading.

On Wednesday, 30 January 2019 at 21:21:24 UTC, Mike Wey wrote:

> This is whats going on: https://issues.dlang.org/show_bug.cgi?id=15418
>
> To work around this you can either build things with "--arch=x86mscoff" or tell dub not to build the debug version with "--build=plain".

Ah! Thanks, Mike. Does the lack of an answer to the last question there mean that this is an on-going issue?

On Wednesday, 30 January 2019 at 20:07:15 UTC, Jacob Carlborg wrote:

> It's Optlink being stupid as always. If you want to figure out what's wrong you can invoke Dub with the "--verbose" flag to have it print the commands it's running, i.e. how it's invoking the compiler and the linker. You can do the same thing when invoking the compiler manually by adding "-v" to see how it links the application and compare that with Dub.
>
> Or, you can try compiling as COFF instead of OMF which will not use Optlink. Add the flag "--arch=x86mscoff" when invoking Dub.

I think I'll wait, but thanks for letting me know.

On 31-01-2019 21:33, Ron Tarrant wrote:
> On Wednesday, 30 January 2019 at 21:21:24 UTC, Mike Wey wrote:
> 
>> This is whats going on: https://issues.dlang.org/show_bug.cgi?id=15418
>>
>> To work around this you can either build things with "--arch=x86mscoff" or tell dub not to build the debug version with "--build=plain".
> 
> Ah! Thanks, Mike. Does the lack of an answer to the last question there mean that this is an on-going issue?
> 

Yes, the issue is still open / on-going.

-- 
Mike Wey