subprojects to swift packages ?

Question

Created Jun ’20

Replies 2

Boosts 0

Views 1.4k

Participants 2

I have an app I'm returning to after a several years I'd like to freshen up, but am daunted by the changes since; 2018 WWDC - session 415: behind the scenes of Xcode Build process, points out the many changes just that year.

It's Objective-C only, features several sub-projects both private and GitHub, whose .xcodeproj file I'd had dragged in as the then practice, which my main project has as dependencys; all was good.

But have few but widespread problems:

* IB plugins

* framework headers not getting found

* sub-builds failing - deprecated or now not viable code

* what to do re: BWToolkit which appears stagnant?

The 2nd is odd as they build ok invividually.

So my question is to whether to continue the sub-project route, or try migration to modernize like envelop them as swift packages. This is not all viable as some have assets, but otherwise, what to do? I think the missing header issue is due to naming:i.e. `import "foo.h"` should now be `import <MyFramework/foo.h>`.

But I suspect some moving about is needed intra sub-project - as to path namings, so I was focusing on them first, then tackle the main app.

Some of my subs had already adopted swift packages so I'm leaning that way.

But some not; notably - core-plot and CocoaAsyncSocket I think these two might stay as subs if I can get their header inclusions to work and address my deprecations. And yes I'm aware of the assets restrictions for packages

Anyway, seeking some guidance thanks.

Boost

Answer 1

DrMickeyLauer OP

Sep ’20

Good question, I’m in the same situation. Pity that noone dares to share some wisdom here. It looks like much of the traffic has moved to forums.swift.org.

FWIW, I wonder especially whether it’s possible to (ab)use SPM for pure Objective-C packages. What did you settle for?

0

Answer 2

slashlos OP

Feb ’21

I got side tracked but with few exceptions, these sub-projects I had exported to GitHub from their origins when they were self contained within their original app I'm now returning to. All was nice and simple. I mused just putting them back, within the app, but that seemed like a bad move, backward, just like using an older system / build environment which last worked and just continue there.

One sub-project in particular - CocoaAsyncSocket, appears to have made the grade to SPM, so I'm wading towards that path for the others(6).

Aside from explicit dependency entry in build settings, the subject of header resolution leads me to think that perhaps I shouldn't have or use such explicit inclusions, as otherwise the SPM and its definitions (headers) should be treated like any framework - black box?

0