Upgraded to 2.3.1, have a few weird build warnings in Xcode 9.1

[schveiguy]

What did you do?

Upgraded my project (and subsequently GRDB) for use with Swift 4 and Xcode 9.1. This means I simply did git checkout v2.3.1

What did you expect to happen?

Well, no warnings. I'm sure I did something wrong here, but I'm not sure what it is! It's likely not a GRDB issue, but probably an xcode issue. I'm hoping you can help.

What happened instead?

I see 8 warnings along the lines of
GRDB/SQLiteCustom/GRDBCustomSQLite-Testing.xcconfig GRDBCustomSQLite-Testing.xcconfig line 6: Unable to find included file "GRDBCustomSQLite-USER.xcconfig"

Note: it still builds (haven't yet tested, was trying to resolve all warnings).

Environment

GRDB flavor(s): GRDB from github
GRDB version: 2.3.1
Installation method: github submodule
Xcode version: 9.1
Swift version: 4
Platform(s) running GRDB: iOS
macOS version running Xcode: 10.12.6

Demo Project

Sorry, it's proprietary. I can attach screenshots of the build warnings, but since this is a build issue, I would expect any project set up this way to have similar errors. git status inside the GRDB submodule indicates HEAD detached at v2.3.1

[groue]

Hello @schveiguy, happy to see you again!

Those warnings are related to GRDBCustom, the flavor of GRDB that links to a custom SQLite build. The "...USER..." files define the customized SQLite compile-time options. Those files are not in the distribution, because they are supposed to be provided by the host application. It happens that something warns about the fact that they are missing.

Those warnings should indeed be harmless, as long as your app does not depend on the GRDBCustomXXX targets.

Yet they are surprising: thanks for the report! Let me investigate what is this "something" that complains.

[schveiguy]

Hello @schveiguy, happy to see you again!

likewise!

Good to hear these are harmless. Let me know if there's anything I can do to help. I hate warnings, even harmless ones 😆

[groue]

The screenshot below is what you're talking about:

They are the consequence of those conflicting requirements:

• the path to those files must be included in the GRDB directory, so that GRDBCustom target can refer to them.
• those files must be ignored by git (.gitignore), so that they can be customized by the user without flagging the GRDB repo as dirty.
• those files must be present in order to avoid the warnings that are the topic of this issue.

The only solution I can see is to split the GRDB project into three projects: GRDB, GRDBCipher, and GRDBCustom.

[schveiguy]

Yes, those are the errors I see. Your solution seems extreme, though. Is there a way in xcode to generate the files as stubs if they don't exist? Like a shell script that copies a template to that file if it is not there?

[james-rant]

I had the same issue. I simply followed the instructions for setting up the custom SQLite stuff to create the missing xcconfigs, but I don't link against the custom sqlite framework or the GRDBCustom framework. This has the effect of silencing the warnings with a bit of extra setup as the cost.

[groue]

@james-rantmedia, that was a very involved workaround :-)

All right, let's list some options:

1. Move from one project with three targets to three projects with one target each. This is a breaking change for users of GRDBCipher and GRDBCustom.
2. (Steven's suggestion): add pre-build actions that generate missing files. There is already such a pre-build action in the GRDBCustom target. We could duplicate this action in other targets. Caveat: those targets are no longer independent from GRDBCustom.
3. (a derivative of James' suggestion): document how to generate the missing files and get rid of the warnings. Today make SQLiteCustom does the trick. The goal of this Makefile target is to setup tests for custom SQLite builds. It generates the missing file. Caveat: it also downloads SQLite sources.

Option 1 if fully automatic, and no user of the regular GRDB ever sees any warning.

Option 2 is fully automatic, but the warnings are visible until the first build.

Option 3 is not automatic at all: user has to type a command in order to get rid of the warnings.

Isn't Option 2 the best? What do you both think, @schveiguy, @james-rantmedia ?

[schveiguy]

Option 2 is fine with me, despite the initial presence of the warnings. In fact, it says right in the files if you double click on the warning, you need to build once to get it to work. That's actually what I tried, expecting the warnings to go away 😄

As far as independence from the GRDB custom target, that's your call, it doesn't bother me at all. I literally just plop GRDB down as a github submodule, and don't worry about the fact that the other targets are in there. As long as it works, I'm happy.

That being said, all 3 options are fine with me as well, as long as there is a standard way to get rid of the warnings.

I'll suggest a 4th option: provide a stub file you can simply copy yourself to the right place if you want to shut the warnings up, and instructions on how to do so. This is a cross between option 2 and 3, and I believe it will remove both the downsides of cross-project dependency (independence from GRDBCustom) and downloading the SQLite sources. However, it still has the downside of being a manual step. I'd suggest putting the instructions right in the file that the warning brings you to, as that's where someone is going to start looking (if they care).

[groue]

As @schveiguy said:

I literally just plop GRDB down as a github submodule, and don't worry about the fact that the other targets are in there. As long as it works, I'm happy.

I wholeheartedly agree. So option 2 ("pollute" any target until those warnings get fixed no matter how) is the chosen path.

Yet it's less trivial than I thought, so it'll take a little more time 😅

[swiftlyfalling]

@groue: Example files with comments and the appropriate default settings exist at:
SQLiteCustom/GRDBCustomSQLite-USER.h.example
SQLiteCustom/GRDBCustomSQLite-USER.xcconfig.example

I'd suggest copying those instead of generating empty files? (If the user decides to switch over to custom SQLite builds they will then have the proper template as a starting point.)

[groue]

@swiftlyfalling Thanks for your input, you're 100% right.

I'm closing this issue, in favor of #282. Will you all follow me there?