rhx
commented
3 years ago This is great work, thanks. Some comments:
- Replacing
grepwithjqinconfig.shto retrieve the module doesn't make it any more lightweight and adds an additional dependency. While it's nice to get SPM to tell us the information needed, SwiftGtk has full control of the structure of itsPackage.swiftso the grep command should not be too much of an issue. - Simplifying the scripts and making them more beginner-friendly is a great idea. From what I can see, though, it does not appear that SPM will be able to handle everything, so some form of scripting will probably need to remain.
- An alternative (that is somewhat orthogonal to the above) would be to look at
cmake, which now has some support for Swift and is more flexible when it comes to running code generators such asgir2swift.
mikolasstuchlik
The aim of this post is to pitch some ideas that may ease the usage and maintenance of the project. The document is not a call for an immediate action, but rather pitches for future developments. I would be more than happy to implement any or all of following features.
This project heavily relies on auto-generated code. The lack of support for external build tools on the side of the Swift Package Manager (SPM) makes it impossible to avoid using bash scripts completely.
At the same time, there are options available to shorten or omit some parts of the bash scripts.
Building the project using
swift buildPartially related to https://github.com/rhx/SwiftGtk/issues/5, unfortunately no further developments were observed in the matter of external build tools support in the SPM.
The SPM allows user to list packages which should be imported and linked. This is done using
pkgConfig: String?property of thePackageDescriptionor.systemLibrarytarget. This feature is used incorrectly by the project and therefore does not work and additional linker and import flags are needed in order to compile the project.Problem: Packages in this project regularly uses the
pkgConfigargument to specify list of packages which shall be imported. This is however not the intended use of the arguments. As stated in source code, the SPM will search for the<name>.pcfile. To my knowledge, there is no way of specifying more than 1 pkgConfig package dependency for a givensystemLibrarytarget.Possible solution For example, in case of SwiftGLib, the solution was fairly simple. The
gio-unix-2.0package contains all of the same linker flags and search paths as theglib-2.0package. Removing the latter will result in successful build usingswift buildcommand (in case that the wrapper files were already generated;Non whitelisted flags foundwarning will be raised for-pthread). In case of less fortunate composition on packages, the solution may be to split thesystemLibrarytarget.Implementation of this proposal will end the need for
build.shscript.Paths, name and dependencies retrieving from the Swift Package
Various features mentioned below are built upon this feature.
The SPM provides tools for reading the contents of the Swift Package. Those tools provide information such as name of the package, path to the package, recursive list of dependencies (containing also the name and the path to the dependency) etc. The downside is, that those information are provided as a json. Other output formats lack the information needed.
In order to access the information from a bash script, we would need to ask user to install
jq- command line json utility.In turn, we would no longer need to parse the Package.swift in order to obtain
Modvariable.Adding the
gir2swiftas a dependencySince the presence of
gir2swiftis required in order to build any project using theSwiftGtk, thegir2swiftcould be mentioned as a dependency in thePackage.swift. Including tools as dependencies is not an unheard of practice. For example unrelated projects I have worked on did so with BartyCrouch (localization tool for iOS projects). Using previously mentioned feature, we are able to retrieve exact path for gir2swift package in the file-system.Implementing this feature will make us able to remove some of the scripts. For example
generate-wrapper.shwould be present only in thegir2swiftrepository and all the other repositories would contain only thegir-to-swift.shscript, which would be responsible for executinggir2swiftand post processing.Decomposition of bash script files and documentation
In my opinion the most important bash script in the repositories is
gir-to-swift.shwhich does the important job of executinggir2swiftwith appropriate arguments and post processing files. Those tasks are very important and tailored for the specifics and need of a given part of the project.Some parts of the script are common for all of the repositories, for example the search for gir files. This feature could be removed from the individual bash scripts in the repositories and only present in the
gir2swiftrepository as a bash function.Following paragraph builds on premise, that
gir2swiftgir prerequisites of a package compose of prerequisites and girs of it's dependencies.Since we would have the ability to know what packages are present during wrapper generation time and the exact tree of dependencies,
gir-to-swiftbash script would be able to retrieve (compute) prerequisites from other dependencies. Therefore the feature of executinggir2swiftwould no longer be needed inside ofgir-to-swiftscript and could be implemented in the previously mentioned commongenerate-wrapperbash script.In case this feature would be implemented, the only part of bash scripts that would require per-repository maintenance and documentation would be the post processing with
awkandsedfiles.Summary
This document pitches some ideas that would in my humble opinion result in drastic simplification of build process. In case that all of the features would be implemented, the number of scripts per repository would be reduced to two:
gir-to-swiftremnant for post processing andgenerate-documentation. Other scripts that support code generation would be part of the code generation packagegir2swift.