building works only via build.sh

[medovina]

SwiftGtk looks great! I've only just started to try it out, but so far it looks very useful and impressive!

The documentation at https://github.com/rhx/SwiftGtk implies that I can just add the SwiftGtk dependency to an existing project, then build as usual. But I've found that I can't do that and successfully build via swift build. On Ubuntu 17.04 that leads to this error:

Compile Swift Module 'GLib' (6 sources)
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "glib_bridging.h"
         ^
/home/adam/ythol/.build/checkouts/CGLib.git--785524013056038983/glib_bridging.h:196:10: error: 'glib-unix.h' file not found

So I think you should either (a) make it possible to build via swift build, or (b) update the doc to indicate that I need to copy various files from the SwiftHelloGTK project (build.sh, config.sh and so on) into my project.

[rhx]

Good point! I have updated the README to talk about build scripts (and the Resources directory).

Hopefully, in future, once the package manager learns about pkg-config, this won't be necessary any more!

[medovina]

Great - the documentation is much clearer now. Thanks for the quick reply. Yes, it would be great if at some point a native swift build could work, but your build scripts should work OK in the meantime.

[medovina]

Actually there is still a significant issue. If I modify my program's source code and run build.sh, it regenerates all the wrappers and then recompiles all GTK-related Swift modules, which takes a long time. So each edit/compile iteration is super slow.

From a quick glance at build.sh it seems I could call 'swift build' myself as long as I pass the right $CFLAGS and $LINKFLAGS to it. That would skip the wrapper generation, but it would still apparently recompile all the GTK Swift modules on each iteration, which is still super slow. Is there any known workaround?

[rhx]

That's strange -- which version of Swift are you using?

If you look at the build.sh, it should contain the following two lines (if you copied it from the SwiftHelloGtk example project):

gtk=`echo .build/checkouts/SwiftGtk.*/Sources/Gtk-3.0.swift`
[ -e $gtk ] || ./generate-wrapper.sh

This ensures that the wrappers are only generated if they don't exist. This should work for Swift 3.1 or higher. Also, if you are only changing your own source code (and not any of the generated files), the compiler should be clever enough only to re-compile your files, not the Gtk wrapper or other dependencies.

[medovina]

Thanks for the reply. I'm running Swift 3.1.1 on Ubuntu 17.04.

I had copied your SwiftHelloCairoGtk project as a starting point for my own. Looking at this again, it seems that build.sh is different in SwiftHelloGtk and SwiftHelloCairoGtk. SwiftHelloGtk has

gtk=`echo .build/checkouts/SwiftGtk.*/Sources/Gtk-3.0.swift`

But SwiftHelloCairoGtk has

gtk=`echo Packages/Gtk-3*/Sources/Gtk-3.0.swift`

In SwiftHelloGtk, running build.sh a second time does nothing, which is great. In SwiftHelloCairoGtk, it generates all the wrappers again, which is the behavior I was seeing.

So is build.sh in SwiftHelloCairoGtk outdated or wrong? If so, maybe you could update it - thanks!

[medovina]

Also: in the documentation you wrote "unfortunately the Swift Package manager does not (yet) know how to run external programs such as pkg-config". But I think it does! The documentation at

https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageDescriptionV3.md

indicates that you can specify a pkgConfig parameter in Package.swift in a system module package. Could you take advantage of this to simplify the build system?

[rhx]

Yes, that's the plan. But, as far as I could see, at this stage, this is only available on the "master" (trunk) that is earmarked for Swift 4 (I couldn't get it to work for released versions of Swift up to 3.1.1).

[medovina]

I believe the pkgConfig parameter does work in Swift 3.1.1 - at least I've used it successfully in my own small projects. If you have a small example that seems to be failing, I'd be happy to take a look.

[rhx]

Just tried using the pkgConfig parameter, but this is what I get:

error: nonWhitelistedFlags("Non whitelisted flags found: ["-Wl,-framework", "-Wl,CoreFoundation"] in pc file glib-2.0")

I get this on macOS with the following Package.swift for the CGLib package:

import PackageDescription 

let package = Package(name: "CGLib",
    pkgConfig: "glib-2.0",
    providers: [
        .Brew("glib"),
        .Apt("libglib2.0-dev")
    ]
)

[rhx]

BTW, I have clarified in the README now that gir2swift is the issue (not necessarily pkg-config, but see my previous message about that). The build.sh is updated now as well!

[medovina]

I just tried building your CGLib example on Ubuntu 17.04 and it worked OK - I didn't see the nonWhitelistedFlags error, and I was able to call a glib function from a test program. I used the same package.swift as you. module.modulemap looks like this:

module CGLib [system] {
    header "/usr/include/glib-2.0/glib.h"

    export *
}

Unfortunately I had to include an absolute path fo the glib.h header as you can see above. pkg-config knows about the include path for that header (pkg-config --cflags glib-2.0 reports it), but apparently swift-build isn't smart enough to use that.

[quickthyme]

If you look at the build.sh, it should contain the following two lines (if you copied it from the SwiftHelloGtk example project):

gtk=echo .build/checkouts/SwiftGtk.*/Sources/Gtk-3.0.swift
[ -e $gtk ] || ./generate-wrapper.sh

I experienced this same issue, and it's because of the SwiftGtk.* in the gtk assignment. The way the dependencies are being resolved, this always fails. Change it to this:

gtk=`echo .build/checkouts/SwiftGtk/Sources/Gtk-3.0.swift`

Now whenever I hit build, it takes a reasonable amount of time. 😄

[rhx]

Yes, the path has changed with the latest version of the Swift Package Manager. I have updated the scripts in SwiftHelloGtk accordingly.

[lschmierer]

I just want to add the following for reference:
https://forums.swift.org/t/package-manager-extensible-build-tools/10900

When this gets implemented some time, it might help getting rid of the the build scripts.

By the way, have you thought about just storing the gir2swift generated files in the repo? As pkgConfig seems to work, this would accelerate build-time for library users and not require the custom build scripts. I need to further investigate though.

[rhx]

Yes, extensible build tools would probably help. We'd have to see how they would work with generated sources, but hopefully there is a way to integrate them.

The problem with storing the gir2swift generated files is that they depend on the exact versions of glib/gtk/etc. you have installed and the exact Operating System version (including updates) you are using. So this would require a huge number of combinations of generated sources, and it would be almost impossible to pick the right one (e.g. think about the large number of apt package updates that happen even on LTS versions of Ubuntu).

[rhx]

The main branch now uses Swift-5.6 plugins for building.