Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: What is the 'correct' way to add Frameworks for gmake projects on macos #196

Open
JohannesMP opened this issue Aug 4, 2015 · 12 comments

Comments

@JohannesMP
Copy link
Contributor

Summary

I was wondering what the 'correct' way would be to include non-system *.framework files on macos in Premake5, with the ultimate goal of using gmake with clang or gnu compiler.

My assumptions about compiling with frameworks

Correct me if I'm wrong, but as far as I've been able to find out, when compiling a program with a non-system framework under clang or gcc/g++ you need to:

  1. specify what name of framework to use: -framework <FRAMEWORK NAME>
  2. specify location of framework(s) to use: -F <PATH TO FRAMEWORK>

So for example, if I'm compiling a program using SDL2, where SDL2.framework is located at /Library/Frameworks/ then I would add -framework SDL2 -F /Library/Frameworks to my compile string.

From some experimentation - see snippet: https://gist.github.com/JohannesMP/6ff3463482ebbdc82c2e - I've established that, at least on my machine, step 2. is required and not including it causes the compiler to not be able to find the header file in the framework when compiling the object files, and also results in an error when linking them.


Question regarding Premake5

When using Premake, I've seen some projects only do the following:

...
configuration "macosx"
    links {"OpenGL.framework","CoreFoundation.framework","SDL2.framework"}
...

But, at least when using gmake, this seems to create a make file that does not include step 2. above, and so I get the same error as I did in my snippet above (lines 15 and 27)

To be able to account for this I've so far done the following:

...
configuration "macosx"
    links {"OpenGL.framework","CoreFoundation.framework","SDL2.framework"}    
configuration {"macosx", "gmake"}
    buildoptions {"-F /Library/Frameworks"}
    linkoptions {"-F /Library/Frameworks"}
...

However that has the problem of not being portable - for example some users don't have their frameworks located in the global frameworks directory and instead have it in their user directory, ie ~/Library/Frameworks. Furthermore if I try to include both locations, there is a good chance that one of them may not yet exist on a user's machine (they're not created by default) and so they may get an error when running make:

ld: warning: directory not found for option '-F/Users/Jo/Library/Frameworks'

So instead of using buildoptions and linkoptions, is there a better, portable way to include frameworks in Premake5?

Alternatively, is there some global configuration that I am missing on my mac that would make it so that I don't need to include the -F /Path/To/Framework compile/link flag? It seems that it's not required for system frameworks, at least those located in /System/Library/Frameworks.

For reference, here are the premake5.lua file and the c file for a simple SDL2 'hello window' program that I've been using for testing: https://gist.github.com/JohannesMP/9a9b5263c127103f1861#file-premake5-lua-L24-L26 - The highlighted lines are what my question is about.

@JohannesMP JohannesMP changed the title What is the 'correct' way to add Frameworks for gmake projects on macos Question: What is the 'correct' way to add Frameworks for gmake projects on macos Aug 4, 2015
@starkos
Copy link
Member

starkos commented Aug 4, 2015

It probably should be enough to specify:

links { "/Library/Frameworks/SDL2.framework" }

Premake should be smart enough to split that path up on its own into the appropriate flags. But you are correct that it does not do that currently.

@tvandijck
Copy link
Contributor

Blizzard@6a66d12

I can make a pull request for that if you want.

@JohannesMP
Copy link
Contributor Author

So just to clarify, I'm not missing some global configuration that makes it so that /Library/Frameworks is searched by default? I tried adding it to my path but that didn't help.

In other words, is there something I'm missing that would make gcc sdl2_test.c -c -o sdl2_test.o -framework SDL2 compile correctly in the terminal without having to also include -F /Library/Frameworks?

@tritao
Copy link
Contributor

tritao commented Aug 4, 2015

Well the exact same problem occurs when handling regular libraries. We have libdirs and links. Maybe we need to add a frameworkdirs option to support this use case.

@JohannesMP
Copy link
Contributor Author

since links isn't explicitly for frameworks only, would it make sense to create an explicit frameworkdirs?

@tvandijck
Copy link
Contributor

If we introduce a "frameworkdirs", I don't really see why frameworks still need to be in links...

I rather either have links and libdirs correctly support frameworks...
or have:

  • frameworks
  • frameworkdirs

and

  • links
  • libdirs

and not allow .framework files in links.

@JohannesMP
Copy link
Contributor Author

As a side note, this stackoverflow question seems to be dealing with the same issue: http://stackoverflow.com/questions/29465141/linking-mac-frameworks-using-premake-and-gnu-make

I think, for the sake of backwards compatibility it would make sense to keep frameworks in links and either allowing the user to specify the framework path via includedirs or libdirs. I don't have the intuition/experience with Premake to know which one would make more sense, if at all; just going off gut feeling here.

@JohannesMP
Copy link
Contributor Author

Also, since non-system frameworks are typically located in one of two places (/Library/Frameworks and ~/Library/Frameworks), perhaps premake should add those via the -F flag by default, if they contain a framework that the user is looking for.

So effectively the pseudocode for premake's logic when creating a gmake project would be:

if user requests framework not found in default location (/System/Library/Frameworks)
    if '~/Library/Frameworks' exists and contains framework
        add '-F ~/Library/Frameworks' to build/link options
    else if '/Library/Frameworks' exists and contains framework
        add '-F /Library/Frameworks' to build/link options

That should resolve this problem in most standard cases where the user is not storing the framework in another location, at which point we could still use something like what is being discussed above, regarding frameworkdirs, libdirs, or otherwise.

@starkos
Copy link
Member

starkos commented Aug 4, 2015

Keep in mind that Premake is not always run on the same system that will build the project. I frequently output project files for Linux and Mac OS X while running on Windows, and vice versa.

@JohannesMP
Copy link
Contributor Author

Ah yes, that does make things more complicated than what I had assumed. I'm not really sure how to best have premake account for that, if at all.

If you are distributing a a cross-platform project and want to make sure that mac users that have a given framework (ex. SDL2) in various locations can all run 'make' on the makefiles that premake created with premake5 gmake (regardless of what platform it was originally created on), is it possible to have the make file itself handle that logic (checking the two default locations) or would you just have to require the users to have their frameworks in the location you specified in the original premake5.lua (like '/Library/Frameworks' in my case?)

@starkos
Copy link
Member

starkos commented Aug 8, 2015

I think in that case it would be better to ask your developers to run Premake locally to configure their projects?

But for the sake of improving the Makefiles, perhaps we should automatically add /Library/Frameworks and ~/Library/Frameworks when a framework file is specified in the project? And just put them at the end of the list so they can be overridden easily?

@JohannesMP
Copy link
Contributor Author

At the very least I do agree that your suggestion (tvandijck's suggestion) would be a great start.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants