There's many tutorials for learning OpenGL with C++, and at least one for
learning OpenGL with Objective-C, but I couldn't find more than a few small
blog posts about OpenGL with Swift. So I fixed that for you.
The first few tutorials are done. It will to take a very long time to
finish the rest. But it's ready for feedback and I'm going to need some
encouragement to continue.
In addition, the SwiftGL libraries have been split apart. While they were
always meant to work together, none of them depended on each other.
Specifically, this addresses software that uses Apple libraries but also
wants to use enhanced syntax of the SwiftGL Loader.
Unfortunately when I try to build the `Hello Window` tutorial Linux
tells me the linker couldn't find -lglfw3 although I installed it
properly.
Well, since I'm on Linux I modified the Package.swift and removed the
Dependency Adding stuff since I only need the CGLFW3Linux.git
I have no clue where this linking is done so I'm unable to optimize the
`3` out of the linking. My distribution does only support GLFW3 and has
no support for GLFW2, so maybe they simply renamed it?
If you could point me to the right direction I'd like to dig deeper into
your tutorials.
I test that Ubuntu 14 can build the project. Beyond that I plan to depend
on feedback like yours to smooth out Linux.
Check out the modulemap for the Linux GLFW. What you need to fix is likely
in there. Honestly, I built it with trial and error.
If you get it working, please let me know what Linux you are using and send
me the code. (github ticket, email, carrier pigeon, whatever).
I looked for something with less friction than GLFW but came up empty. It's
possible to make a pure Swift replacement, but I don't have the resources
to make that happen any time soon.
-david
···
On Tue, Feb 23, 2016 at 1:00 PM, Marco Feltmann <coding@marcofeltmann.de> wrote:
Hey David,
I really appreciate this idea!
Unfortunately when I try to build the `Hello Window` tutorial Linux
tells me the linker couldn't find -lglfw3 although I installed it
properly.
Well, since I'm on Linux I modified the Package.swift and removed the
Dependency Adding stuff since I only need the CGLFW3Linux.git
I have no clue where this linking is done so I'm unable to optimize the
`3` out of the linking. My distribution does only support GLFW3 and has
no support for GLFW2, so maybe they simply renamed it?
If you could point me to the right direction I'd like to dig deeper into
your tutorials.
In my case, I've solved it by making a swift build and then editing the recently downloaded file (Packages/CGLFW3Linux-1.0.0/module.modulemap). Changing out the link statement from glfw3 to glfw.
TBH, I think there should be a way to specify fallbacks for a link declaration to tackle these awkward moments where lack of standarization across distros comes to bite at compile time (or even, across release versions). Like, try X and if it doesn't exist try Y and so on (grabbing whatever matchs first)
Otherwise, it's gonna be rough using stuff from the swift ecosystem and editing modulemaps and writing instruction for users to do that.
Hugs.
···
On 02/23/2016 06:00 PM, Marco Feltmann via swift-users wrote:
Hey David,
I really appreciate this idea!
Unfortunately when I try to build the `Hello Window` tutorial Linux
tells me the linker couldn't find -lglfw3 although I installed it
properly.
Well, since I'm on Linux I modified the Package.swift and removed the
Dependency Adding stuff since I only need the CGLFW3Linux.git
I have no clue where this linking is done so I'm unable to optimize the
`3` out of the linking. My distribution does only support GLFW3 and has
no support for GLFW2, so maybe they simply renamed it?
If you could point me to the right direction I'd like to dig deeper into
your tutorials.
In my case, I've solved it by making a swift build and then editing the
recently downloaded file (Packages/CGLFW3Linux-1.0.0/module.modulemap).
Changing out the link statement from glfw3 to glfw.
Like, try X and if it doesn't exist try Y and so on (grabbing
whatever matchs first)
I have no clue how to realize that kind of logic.
There is a `link` command in the modulemap, but a `link if exists`
doesn't sound like it is implemented now.
Otherwise, it's gonna be rough using stuff from the swift ecosystem and
editing modulemaps and writing instruction for users to do that.
As long as you point the Swift users to the direction where they can
tweak this behaviour this feels fine for me.
But when providing OSS this really is a no-go.
At least on Linux this whole ./configure; make; make install; stuff was
created to wrestle down these distribution-depending things.
···
On Tue, Feb 23, 2016 at 09:03:42PM -0300, Luz Violeta via swift-users wrote:
TBH, I think there should be a way to specify fallbacks for a link declaration to tackle these awkward moments where lack of standarization across distros comes to bite at compile time (or even, across release versions). Like, try X and if it doesn't exist try Y and so on (grabbing whatever matchs first)
Like, try X and if it doesn't exist try Y and so on (grabbing
whatever matchs first)
I have no clue how to realize that kind of logic.
There is a `link` command in the modulemap, but a `link if exists`
doesn't sound like it is implemented now.
It's not implemented yet, but it should. Actually, more than "link if exists" i was thinking of a "link this, preferably ... if it's not there, here's a list of alternative names of this library and link whatever is available first off that list"
Otherwise, it's gonna be rough using stuff from the swift ecosystem and
editing modulemaps and writing instruction for users to do that.
As long as you point the Swift users to the direction where they can
tweak this behaviour this feels fine for me.
Well, demanding that to a developer consuming code or worst, to a final user ... for me, it feels like demanding arcanery or something alpha-looking.
But when providing OSS this really is a no-go.
At least on Linux this whole ./configure; make; make install; stuff was
created to wrestle down these distribution-depending things.
Well, I'll differ in considering autotools like a reference or standard when you implement a build system from scratch (which is the case of swift-build). At the end, it all boils down to repeating old and terrible designs, or making something cool (easy to set up, no forced fiddling to initially build and something pretty much distraction-less during development process ... I think a build system should aim for something like that, because we all benefit from something like that :D)
At my work, we're not married to any particular language and we have space to -judiciously- involve with new tech. Would love that to be the case with swift (I mainly write backend software with rust -which was a recent addition alongside the existing python codebase- and also code that does require it's share of C interop), but the whole build system story is the biggest deterrent at the moment (for now, swift is only used specifically for iOS development through xcode)
Renaming to drop the 3 should be filed as a bug in your distro. To
workaround this easier, I created a module with the 3 already removed. It's
documented in the tutorial too.
-david
···
On Wed, Feb 24, 2016 at 1:59 PM, Marco Feltmann via swift-users < swift-users@swift.org> wrote:
On Tue, Feb 23, 2016 at 09:03:42PM -0300, Luz Violeta via swift-users > wrote:
> In my case, I've solved it by making a swift build and then editing the
> recently downloaded file (Packages/CGLFW3Linux-1.0.0/module.modulemap).
> Changing out the link statement from glfw3 to glfw.
Perfect, thank you! :)
Changed, `swift build --clean; swift build`, works.
You should try to get your package manager issues in front of the right
people. It's possible they won't see it here with the subject line being
"OpenGL".
The snapshots released today fix the bug which was preventing SwiftGL from
working with Swift 3.0. I switched the tutorial over to 3.0. Since I'm no
longer documenting an old 2.2, it's now reasonable to use the tutorial as
an example when talking about some of the package manager changes you want.
-david
···
On Wed, Feb 24, 2016 at 9:55 PM, Luz Violeta via swift-users < swift-users@swift.org> wrote:
... the whole build system story is the biggest deterrent at the moment
(for now, swift is only used specifically for iOS development through xcode)
I don't think so.
IMHO it is the correct way to _not_ label the current version of a library. I'd prefer GLFW whichever version is the current one.
When there was a heavy API change from GLFW 2.x to GLFW 3.x the older
version still used should be labelled GLFW2 instead of labelling the new
one GLFW3.
Otherwise noone will ever likely be updating their sources to the
current library version.
···
On Thu, Feb 25, 2016 at 11:35:26AM -0800, David Turnbull wrote:
On Wed, Feb 24, 2016 at 1:59 PM, Marco Feltmann via swift-users < > swift-users@swift.org> wrote:
Renaming to drop the 3 should be filed as a bug in your distro.