Use frameworks in Premake generator

[sheepsteak]

Fixes #9367

Changelog: Fix: Use frameworks in Premake generator.
Docs: conan-io/docs#2210

This PR allows the system frameworks in a package like SDL2 to now be associated with Premake. There is still the issue with how to use frameworkdirs. It seems like Premake5 does support a framworkdirs property itself but it's only used for the Xcode generator. There is a PR (premake/premake-core#1661) to add this to the gmake generator, however.

Although after looking at the make generator I'm a bit confused about frameworkdirs. The conanbuildinfo.txt has framework_dirs but the make generator (and unit tests) seem to use framework_paths. Are they the same thing?

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[CLAassistant]

All committers have signed the CLA.

[lasote]

Thank you so much for helping with this!! Looks good!
Please, to accept the PR we need you to sign the CLA.

[SSE4]

sounds reasonable
this is unfortunate premake doesn't support framework dirs.
we may still populate conan_framework_dirs{dep} vars just in case (someone manually specify -F flags)

[SSE4]

Although after looking at the make generator I'm a bit confused about frameworkdirs. The conanbuildinfo.txt has framework_dirs but the make generator (and unit tests) seem to use framework_paths.

frameworkdirs is a value you populate within package_info method, e.g.:

self.cpp_info.frameworkdirs = ['Frameworks']

it's usually a relative paths to your the root directory of your package (theoretically, might be an absolute path as well, but I don't see good use-case for that at the moment)
framework_paths is the final value computed, which is a full, an absolute path to the directory in your local cache. this one is intended to be passed into the compiler/linker, and conan supplies that into generator (thus, files like conanbuildinfo.cmake contain such final paths).

that's more or less the same for other directories:

• includedirs -> include_paths
• libdirs -> lib_paths
• bindirs -> bin_paths
• resdirs -> res_paths

I think you see the logic, it's just a convention in our CppInfo model.

[uilianries]

@sheepsteak Thank you for your contribution. Please, don't forget to sign Conan's CLA as described here. Otherwise, this PR could not be merged.

[uilianries]

Agreed with @SSE4

The Premake's documentation shows the supported dirs here

Premake doesn't list a frameworkdir, but it also doesn't separate Mac frameworks, instead, it uses links and it's indicated to use absolute path. However, we can consider libdirs in this case.

The framework feature supported by Premake is related to .NET. I hope people don't get confused about it.

[memsharded]

If I understood this correctly, this will not work for packaged frameworks, only for system frameworks?

Because the frameworks_dir variable is simply not managed, not considered at all here.

[SSE4]

If I understood this correctly, this will not work for packaged frameworks, only for system frameworks?

Because the frameworks_dir variable is simply not managed, not considered at all here.

yes. we can do nothing for packaged frameworks, as it's not supported by the build system.

[memsharded]

yes. we can do nothing for packaged frameworks, as it's not supported by the build system.

Premake doesn't list a frameworkdir, but it also doesn't separate Mac frameworks, instead, it uses links and it's indicated to use absolute path. However, we can consider libdirs in this case.

@uilianries you saying that could in-package frameworks work if the generator provided full paths to the framework somehow?

[uilianries]

@memsharded if a framework is a single file, yes. But considering link example using Cocoa.Framework and based on old Conan behavior (before 1.22), only the framework name should work, since the DYLD_LIBRARY_PATH is configured correctly.

Well, actually DYLD_FRAMEWORK_PATH should be used, but again Premake doesn't have support for it, instead, it configures the regular DYLD_LIBRARY_PATH only.