Packing macOS executable into application

[Nelonn]

Modifications in the build packages the executable file into macOS application.

macOS applications are read-only, so I moved config to /Users/{user}/Application Support/SniffCraft/conf.json

[Nelonn]

In mine repository automatic_release fails cause I don't have tag latest

[adepierre]

In mine repository automatic_release fails cause I don't have tag latest

Yes you need to create the first latest tag manually so the automatic changelog can be created in the release

[Nelonn]

In mine repository automatic_release fails cause I don't have tag latest

Yes you need to create the first latest tag manually so the automatic changelog can be created in the release

In general, everything works fine

[adepierre]

XCODE_ATTRIBUTE_ENABLE_HARDENED_RUNTIME seems to be very XCode only. So I think the if condition should also check the generator is xcode, as it's also possible to compile on macos with other generators that don't support these features.

Also, I'm not sure what hardened runtime do exactly, but with a quick internet search, it makes me think it may break the DLL loading for the plugins feature.

[Nelonn]

XCODE_ATTRIBUTE_ENABLE_HARDENED_RUNTIME seems to be very XCode only. So I think the if condition should also check the generator is xcode, as it's also possible to compile on macos with other generators that don't support these features.

Also, I'm not sure what hardened runtime do exactly, but with a quick internet search, it makes me think it may break the DLL loading for the plugins feature.

This is an optional option, but I've seen many people use it. At the expense of XCode, other compilers will simply ignore these options

[adepierre]

Took some time to look at it in details and I don't think I want to merge it in the main repo. The facts that I don't know anything about macOS and I can't test anything myself make me think that I won't be able to maintain the feature reliably in the future.

[Nelonn]

Took some time to look at it in details and I don't think I want to merge it in the main repo. The facts that I don't know anything about macOS and I can't test anything myself make me think that I won't be able to maintain the feature reliably in the future.

mac OS application is essentially executable in a mini wrapper, if the question is about support, you can supply raw executable separately

[Nelonn]

I recommend that you make a cmake option to build into the app.

[adepierre]

Took some time to look at it in details and I don't think I want to merge it in the main repo. The facts that I don't know anything about macOS and I can't test anything myself make me think that I won't be able to maintain the feature reliably in the future.

mac OS application is essentially executable in a mini wrapper, if the question is about support, you can supply raw executable separately

Yeah that's sort of my point. I don't really understand what is the advantage of going to an app instead of the standalone executable file? From what I understand the only effects it has are

• forcing the conf file to be located somewhere else -which is not really a good thing-
• potentially breaking the plugin system
• making maintenance of the project harder, as everytime a new feature will be added, I'll have to wonder if that needs specific handling for the macos app thing

It seems to me the app package thing has only cons and not real pros in the context of this project which is already a single executable.

[Nelonn]

Took some time to look at it in details and I don't think I want to merge it in the main repo. The facts that I don't know anything about macOS and I can't test anything myself make me think that I won't be able to maintain the feature reliably in the future.

mac OS application is essentially executable in a mini wrapper, if the question is about support, you can supply raw executable separately

Yeah that's sort of my point. I don't really understand what is the advantage of going to an app instead of the standalone executable file? From what I understand the only effects it has are

• forcing the conf file to be located somewhere else -which is not really a good thing-
• potentially breaking the plugin system
• making maintenance of the project harder, as everytime a new feature will be added, I'll have to wonder if that needs specific handling for the macos app thing

It seems to me the app package thing has only cons and not real pros in the context of this project which is already a single executable.

In my mind, SniffCraft should be a complete application with the ability to "Load config", "Save config", workspaces, etc. Now I use this modifications and get great pleasure from my work.

[adepierre]

Yeah I think this is a divergence in vision for Sniffcraft. I personally see it as a tool that I use occasionally to develop my other projects. As such, it obviously needs to work properly, but also more importantly not take me more time to develop and maintain than I gain by using it.

So even if many small niche features would probably be useful for some people, I do not want to take the responsability of maintaining them in the future in the main repo.