[MacPorts] #29917: Fuse4X: add port

[MacPorts]

#29917: Fuse4X: add port
--------------------------------------+-------------------------------------
 Reporter:  anatol.pomozov@…          |       Owner:  dports@…                           
     Type:  submission                |      Status:  assigned                           
 Priority:  Normal                    |   Milestone:                                     
Component:  ports                     |     Version:                                     
 Keywords:                            |        Port:  fuse4x fuse4x-kext fuse4x-framework
--------------------------------------+-------------------------------------

Comment(by anatol.pomozov@…):

 Replying to [comment:44 dports@…]:
 > Here are my current thoughts:
 >
 >  * we are not going to replace macfuse with fuse4x, at least not right
 away. Both should be available as options; we might also have a port for
 OSXFUSE. At some later point, if it doesn't look like there are any
 problems, we can consider changing the default or marking macfuse as
 `replaced_by`.

 OSXFUSE was started by Benjamin after I told him that I work on fuse4x and
 asked him join the project. He rejected my proposal and started osxfuse. I
 hate when political reason overweights the technical one.

 >  * we do not need to support having more than one FUSE implementation
 installed, so it's OK if the ports conflict with each other on fuse.h. In
 fact, it may be better that way because there won't be any question about
 which one a given filesystem is using. Renaming the header files sounds
 like it could cause a significant compatibility issue for filesystems.
 >  * the fuse4x ports shouldn't conflict with an installation of MacFUSE
 installed outside of MacPorts. It doesn't look like they will, which is
 great since an improvement over the macfuse port.

 It is true
 > I don't think they will conflict with a standalone Fuse4X installation.
 They will conflict - standalone and macport fuse4x will conflict in
 filesystem type and device files (/dev/fuse4xNN).

 >  * existing filesystem ports should be able to build against either
 macfuse or fuse4x. This will take some changes but (I think) not major
 ones. I've already put together a patch for sshfs.

 It is better to replace sshfs by this one https://github.com/fuse4x/sshfs
 It is also updated to 2.3.0

 >  * I'd wanted upgrading from macfuse to fuse4x to not require rebuilding
 filesystems, but I think that's unrealistic. There are substantive
 differences between the two, like the fact that MacFUSE has semaphore
 emulation and Fuse4X doesn't (FWIW, I agree with you that it shouldn't!).
 So it's OK if switching requires a rebuild.

 It be better to check filesystems that they do not use semaphores from
 fuse. It can be done by "nm BINARY_FILE | fuse_sem_". And if one uses it -
 just add semaphores to the filesystem's compat/ like here
 https://github.com/fuse4x/sshfs/blob/master/compat/darwin_semaphore.c

 > All of this argues that we're basically in good shape with the portfiles
 as they are now. I need to test a couple more filesystems, and it would be
 good to have a release with the Leopard/Lion compatibility fixes I sent
 you. I also haven't tested anything that uses the Obj-C framework yet.
 Other than that, I should be able to commit it soon.

 I have a computer with Lion and I'll run my test suite early next week.

-- 
Ticket URL: <https://trac.macports.org/ticket/29917#comment:45>
MacPorts <http://www.macports.org/>
Ports system for Mac OS