Custom.yaml

Shoes 3.2.22 introduced a new way to set the paths and local options for building Shoes targets. These yaml files are used for all the mainstream builds and many of the ones that aren't mainstream. If you are used to modifying a configure script to build software than you'll recognized what's happening here. Only minlin, minbsd and minosx can work without a custom.yaml and sometimes they could use one too.

You can still modify the env.rb if you want but that turns out to be problem if two developers are pushing env.rb changes to github - he keeps his dependencies in C:\Sandbox and I keep mine in E:\shoesdepss\mingw. Or I have two dependencies locations (I do) and he has two different Ruby's. Any change made to env.rb has to be undone by the other party. Wasteful and annoying. So we invented *-custom.yaml which are little files that aren't sent or synchronized with github. It's your local settings that get plugged into env.rb.

Here's the mxe-custom.yaml - that is the cross compile on Linux (or OSX) to produce Shoes/Windows. It uses dependencies and compilers built by the MXE tools. See MXE Dependencies

Deps: /home/ccoupe/Projects/shoesdeps/mxe/usr/i686-w64-mingw32.shared
Ruby: /home/ccoupe/Projects/shoesdeps/mxe/usr/i686-w64-mingw32.shared
Gemloc: /home/ccoupe/Projects/gems/rb23
InclGems:
  - chipmunk*
  - sqlite3*
  - nokogiri*
  - mini_portile2*
  - byebug*
  - rb-readline*
  - win32-shortcut*
  - ffi*
  # picky needs:
  - activesupport*
  - concurrent-ruby*
  - i18n*
  - multi_json*
  - picky*
  - rack_fast_escape*
  - thread_safe*
  - tzinfo*
  - url_escape*
  - yajl-ruby*
  # typhoeus
  - ethon*
  - typhoeus*
  # because
  #- bloopsaphone-0.4
MS-Theme: true 
Debug: true
Deprecations: true 
Installer: nsis
#InstallerLoc: /home/ccoupe/Projects/nsis/nsis3/bin/makensis
InstallerLoc: /home/ccoupe/Projects/shoesdeps/mxe/usr/i686-w64-mingw32.shared/bin/makensis

Deps: should be the full path name to where you unziped ShoesDeps.zip (where the bin, etc, include, lib, and share folders are). Of if you build the deps and ruby your self, then point to theme here.

Ruby: should be the full path name to the Ruby toplevel folder (has bin, include, lib inside) that you want copied in the build. This may not be the location of the Ruby that it running the rake (the build) They can be two different Rubies. Often they must be different.

Gemloc: Points to the directory that holds the premcompiled gems to include in Shoes. Normally you would gets these gems by downloading them because it's trouble some to build them your self on Windows. But if you have to build them you can do it if you have a machine running the target OS, with the build tools installed and a way to copy things between the target machine and the build machine. See missing Note the gems directory pointed to looks like #{gemloc}/built/#{target} where target is mxe,yosemite,rpi or 12 other targets.

InclGems: is a Yaml list of partial gem names to copy from Gemloc: Use * sparingly.

Debug: Is 'true' or 'false'. If your *-custom.yaml doesn't have a Debug entry then it's going to assume 'false'. False strips off the debugging symbols in the target.

Deprecations: when true turns off warning messages about using old API's. After that we get to settings that only apply to certain targets.

Windows

MS-Theme: is 'true' or 'false' (default is false). This setting only works for Windows targets. If set to false (default) the resulting Shoes will have the Look and Feel of earlier Shoes 3.2. If set to true it uses the new with 3.2.22 theme engine. True is a good choice.

Installer: nsis The only other choice is 'qtifw`

InstallerLoc: This is the absolute path to where nsis.exe is on your system. In the example above, it's a special nsis that runs on Linux but creates and exe. Be careful with paths that have spaces - it takes skill to get (Program Files (x86) escaped properly as a yaml string. Perhaps: InstallerLoc: \"C:Program Files (x86)\\NSIS\\Unicode\\makensis.exe\"

`InstallerLoc: C:/Qt/QtIFW2.0.5/bin/binarycreator' is another example. Notice the difference? Skillz indeed!

darwin14 example

here is a snip darwin14-custom.yaml, a cross compiled (on Linux, for Shoes OSX)

Deps: /home/ccoupe/Projects/shoesdeps/10.10-3
Ruby: /home/ccoupe/Projects/shoesdeps/darwin14/ruby237
Gemloc: /home/ccoupe/Projects/gems/rb23
...snip...
Debug: true
CFLAGS: -DNEW_RADIO
Deprecations: true
ToolPrefix: /home/ccoupe/Projects/osxcross/target/bin/x86_64-apple-darwin14- 
CC: clang
RANLIB: ranlib
STRIP: strip
OTOOL: otool
INTOOL: install_name_tool

darwin14 is the ABI name for OSX Yosemite or OSX 10.10. It needs different things than a windows build. Note that Deps and Ruby point to two different places. But gems are the same place /home/ccoupe/Projects/gems/rb23/built/darwin14 after expansion. This target needs to know where all the build tools are and their names.

lin64 example

Now guess what this one does on linux.

Ruby: /usr/local
Deps: 
Gemloc: /home/ccoupe/Projects/gems/rb23
Extloc: /home/ccoupe/Projects/gems/rb23
InclGems: 
  - chipmunk-6.1.3.4
  - sqlite3-1.3.13
  - mini_portile2-2.2.0
  - nokogiri-1.8.0
  - rb-readline-0.5.4
  - byebug-9.0.6
  - ffi-1.9.18
    # picky needs:
  - activesupport-5.1.2
  - concurrent-ruby-1.0.5
  - i18n-0.8.6
  - multi_json-1.12.1
  - picky-4.31.3
  - rack_fast_escape-2009.06.24
  - thread_safe-0.3.6
  - tzinfo-1.2.3
  - url_escape-2009.06.24
  - yajl-ruby-1.3.0
  # typhoeus
  - ethon-0.10.1
  - typhoeus-1.1.2
Debug: false
Deprecations: false

Hmmm, Ruby is at /usr/local/bin/ruby and deps are Where ? You'd have to look at the code in make/linux/lin64/env.rb to know for sure. ('' becomes /usr/lib, /usr/lib/x86_64-linux-gnu and /lib/x86_64-linux-gnu) aka the building systems libraries are copied to Shoes/Linux-x86_64. I thought that was warned against ?!! Not really. Ruby was warned about and in this case we do use a different ruby (/usr/local) The host OS here also happens to be Mint and it's not super super super bleeding edge so the libraries actually be copied probably don't conflict with others on the users system.