search

finnvoor / PlaydateKit

Create games for Playdate using Swift.
https://finnvoor.github.io/PlaydateKit/documentation/playdatekit
Creative Commons Zero v1.0 Universal
199 stars 21 forks source link

issues with new project setup #3

Closed mgrider closed 8 months ago

mgrider commented 8 months ago

First off, thanks for making this, I think this goes a long way toward making this a viable path for Playdate games, and I'm super excited to get started with it!

This issue kind of goes hand-in-hand with #2, in that it's basically just about "How do I get started using this project?" I think that PR is part of a larger change that needs to get made to make the example project portable. Ideally a user should be able to copy the example out and rename some things, and have a new project... but that isn't really possible at present without a bunch of searching and replacing (and even after that there are some issues, I think). Alternatively, maybe there should be some detailed instructions on the "right" way to create a new project that works with this project as a dependency.

I said in Discord that I was going to open an issue about this topic, so this is it!

I was also planning to document everything I had to do to get a copy of BasicExample working, but I didn't document as well as I probably should have. Here are some of the issues I ran into:

  1. The make file specific to the swift package points up a directory at Examples/swift.mk.

    This is more or less what the PR addresses. My proposed solution is that we recommend everyone install PlaydateKit in a specific place on their machine. (Maybe along-side the PlaydateSDK, in ~/Developer?) This would allow Examples/swift.mk to hard-code that path value (ideally in a variable at the top, so a user can pretty easily change it if they want).

  2. For some reason, my copy of BasicExample had incorrect Schemes. I don't really know how this happened, but I needed to delete the extra schemes, and rename the BasicExample one (that was the only one that worked, since it ran build-and-run.sh), and built for release. The error I was getting at that point was: <unknown>:0: error: Whole module optimization (wmo) must be enabled with embedded Swift.

  3. It's worth noting that I had to replace even the names of the .o files in my new project's Makefile, because I'd previously run the basic example, and thus those files were cached. The Xcode console gave me some helpful warnings that the cached files did not match the working directory, but cleaning did not fix them.

  4. I still have an issue where my project seems to build and run correctly, but I have to manually open my .pdx file before it opens in the simulator. (The simulator does open, just not my project.) I can live with that, but it's annoying.

I'm not sure what the "fix" is for this issue. There are a lot of ideas, (a command-line utility was discussed), but it could just be that adequate documentation is the easiest path. On the other hand, I'm reluctant to start helping with documentation, since it's possible all of this will change, making any new project documentation obsolete.

finnvoor commented 8 months ago

Hi, thanks for all the feedback!

Documentation is definitely lacking and a high priority, the main reason I haven't added any yet is just because I haven't figured out which direction to go with build scripts/tools.

re 1, installing in ~/Developer is one option, I would to avoid having to install it anywhere if possible though. Adding PlaydateKit as a SwiftPM dependency causes Xcode/Swift CLI to checkout the package locally, so it should be possible to point to the local checkout somehow.

re 2, this is kind of annoying, Xcode seems to autogenerate an extra scheme for some reason. Will try to see if this can be avoided.

re 3, I also ran into this, good callout. Cleaning doesn't help because running the game isn't actually using Xcode caches, it's using make's in build/. Removing build/ should be the equivalent of a full clean.

re 4, if you were trying to use #2 then you probably ran into the issue I just mentioned here.

Overall definitely agree with all your points and will be trying to improve these issues!

mgrider commented 8 months ago

I haven't even tried adding this as a package dependency... but I agree that would be the ideal, for sure.

rauhul commented 8 months ago

I haven't even tried adding this as a package dependency... but I agree that would be the ideal, for sure.

This wont work due to the use of unsafe flags and will likely require SwiftPM improvements

finnvoor commented 8 months ago

I haven't even tried adding this as a package dependency... but I agree that would be the ideal, for sure.

This wont work due to the use of unsafe flags and will likely require SwiftPM improvements

I was under the impression that you can use unsafe build flags in dependencies if you pin to a commit/branch instead of semantic version, so that may work.

rauhul commented 8 months ago

I think you might be right

alicerunsonfedora commented 8 months ago

I haven't even tried adding this as a package dependency... but I agree that would be the ideal, for sure.

This wont work due to the use of unsafe flags and will likely require SwiftPM improvements

I was under the impression that you can use unsafe build flags in dependencies if you pin to a commit/branch instead of semantic version, so that may work.

Yes, this is the case. I often have to do this for SwiftGodot (or at least my fork).

finnvoor commented 8 months ago

closing this as all of this should be fixed/improved by #5 and #6, feel free to open another issue if you run into problems!