[MacPorts] #43439: Cannot install sshfs for x86_64 because osxfuse only supports i386

[MacPorts]

#43439: Cannot install sshfs for x86_64 because osxfuse only supports i386
-----------------------------+--------------------------------
  Reporter:  leeawalsh@…     |      Owner:  macports-tickets@…
      Type:  defect          |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.2.1
Resolution:                  |   Keywords:
      Port:  osxfuse, sshfs  |
-----------------------------+--------------------------------
Changes (by ryandesign@…):

 * cc: dports@… (added)


Comment:

 Replying to [comment:5 mp@…]:
 > Well, I meant {{{-universal}}}, because OSXfuse doesn't build with
 {{{+universal}}} (yet), however it does correctly adapt to whatever the
 kernel is, so that's why ports that depend on it have to adapt as well,
 which they do when
 > {{{
 > configure.build_arch ${os.arch}
 > }}}
 > is added and they're built with {{{-universal}}}. Any port that depends
 on OSXfuse has to be built with what matches the kernel, at least until
 OSXfuse is made to also build with {{{+universal}}}.

 "`configure.build_arch ${os.arch}`" is never correct, because it is a
 mismatch of concepts. `build_arch` controls the build architecture, valid
 values for which are i386, x86_64, ppc, and ppc64, while
 [https://guide.macports.org/chunked/reference.variables.html os.arch
 indicates only whether the computer is Intel-based or PowerPC-based]. On
 all Intel Macs (32-bit and 64-bit), `os.arch` is "i386", while on all
 PowerPC Macs (32-bit and 64-bit), `os.arch` is "powerpc". So setting
 "`configure.build_arch ${os.arch}`" will make the build succeed on Intel
 Macs with a 32-bit kernel, fail on Intel Macs with a 64-bit kernel, and
 cause `configure.build_arch` to be set to an invalid value on PowerPC
 Macs. (Not that osxfuse or any port depending on it can be installed on
 PowerPC Macs, but it's important not to set variables to invalid values
 regardless of the system; you don't want an error to occur just because a
 PowerPC user runs "port info osxfuse" or "sudo port clean all" for
 example.)

 In any case setting `configure.build_arch` directly is usually not the
 best solution; usually you should set `supported_archs` instead. The block
 that would actually need to be added to all ports that depend on osxfuse,
 and all ports that depend on those ports, and so on, is the same block
 that is already in osxfuse:

 {{{
 set kernel_arch [exec uname -m]
 switch ${kernel_arch} {
     i386 -
     x86_64 {
         supported_archs ${kernel_arch}
     }
     default {
         supported_archs i386 x86_64
     }
 }
 }}}

 It is unfortunate that the osxfuse port currently encompasses two very
 different pieces of software: a kernel extension, whose architecture needs
 to match the kernel, and also userland frameworks and libraries that other
 programs need to link with. It would be ideal if osxfuse could split these
 two different types of software into two different ports, so that's the
 kernel modules could be built for their required architecture, while the
 libraries and frameworks could be built for the same architecture as other
 userland software, thus eliminating the need to add the above block to any
 port that directly or indirectly uses osxfuse.

 > The old solution (fuse4x) could be built with {{{+universal}}}, so then
 all its dependents could be built with either {{{+universal}}} or
 {{{-universal}}}.
 >
 > Hopefully some Portfile wizard can also get OSXfuse to build with
 {{{+universal}}} eventually.

 That is the best solution of all, if someone can come up with it.

 > Actually, it's a bit strange with Snow Leopard, because it seems that
 only the kernel is 32-bit, and everything else can be either 32- or
 64-bit. Someone, somewhere might know why...

 This is not strange; this is perfectly normal. Whether the kernel is
 32-bit or 64-bit has no bearing on whether you can run 64-bit userland
 programs, and whether the kernel is 32-bit or 64-bit varies by Mac model
 and OS X version. That's just how Apple decided to do it.

-- 
Ticket URL: <https://trac.macports.org/ticket/43439#comment:6>
MacPorts <http://www.macports.org/>
Ports system for OS X