xcodebuild with a specific configuration

[4brunu]

I need the ability to choose a specific configuration that may be different from the default one specified in Xcode, to passe it to xcodebuild.

Something like

bridgecraft generate <path_to_xcodeproj> <target_name> \
    --configuration Debug

What do you think about this?
If you want I can create a PR.

[lvsti]

Sounds good but do you think there will ever be a need to pass other arguments as well? In that case I'd prefer a more general solution.

[4brunu]

I had the same thought! I think probably there will be need for other arguments, so passing them in a generic way it can be a good solution.
And the arguments sdk and destination can eventually be removed and also passed in a generic way too.

[lvsti]

Yup, I'm thinking along the line what xcodebuild does with the linker arguments. E.g. if I want to pass -a bbb -c=ddd to the linker, it would become -Xlinker -a -Xlinker bbb -Xlinker -c=ddd. I'm not sure though to what extent Commander supports this kind of quoting of arguments...

[lvsti]

or perhaps using -- as a delimiter, after which any subsequent argument would be passed to xcodebuild

[4brunu]

And all of those arguments would be applied to the xcodebuild of the method compilerFlagsForBridgingSource?
Can you please give and example of the -- approach, please? Just to make it more clear. 🙂

[lvsti]

I thought of something like

$ bridgecraft generate some.xcodeproj MyTarget -- \
    -configuration Debug \
    -sdk iphonesimulator \
    -destination 'platform=iOS Simulator,name=iPhone 6,OS=latest'

[4brunu]

I didn't knew the -- approach.
Booth of them look good to me, but I'm also wondering if Commander has support for any of them?

[lvsti]

It clearly doesn't support --, and there is trouble with quoting as well since it tries to process anything that begins with a - as a flag. One quick hack I found was to pass the extra flags in a string and prepend a space to fool Commander:

$ bridgecraft generate some.xcodeproj MyTarget \
    -X " -configuration Debug -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 6,OS=latest'"

this way I was able to get the string as a whole.

[4brunu]

Hum, this approach was my initial thought, but it a hack... do you know if there is any good alternative to commander that supports one of those use cases? I wonder if any swift open project has a similar need, maybe SourceKitten? What about a configuration file like Sourcery or SwiftLint?

[4brunu]

I found a solution in my projects that no longer requires passing the configuration.
So for me we can close this issue, although this would be handy to future proof this question of the arguments.
So it's up to you if you want to close this issue, or keep it open.
But could you please release a new version with the changes already made? (Once you have time of course, no pressue 🙂)

[4brunu]

It's not exactly the same situation, but Sourcery is using a json string to pass arguments (krzysztofzablocki/Sourcery#677).
It remind me of your proposal:

$ bridgecraft generate some.xcodeproj MyTarget \
    -xcodebuildArgs "-configuration Debug -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 6,OS=latest'"

or

$ bridgecraft generate some.xcodeproj MyTarget \
    -xcodebuildArgs '{"-configuration": "Debug", "-sdk": "iphonesimulator", "-destination": "platform=iOS Simulator,name=iPhone 6,OS=latest"}'

[lvsti]

The last thing I'd want would be parsing JSON from the command line 😅
I'd keep this issue open if you don't mind, I think it would be a useful addition to have but we need to investigate more the options.

[lvsti]

Turns out it was pretty easy to add -- to Commander: kylef/Commander#75

[4brunu]

@lvsti any news on this? 🙂 Maybe looking for some Commander alternative?

[lvsti]

well it seems that Commander has been abandoned by its author so I might as well use my fork as dependency

[4brunu]

I tried to search for good Commander alternatives but couldn't find one that would stand out.
https://github.com/Carthage/Commandant is supported, but not sure if it supports this use case.

[lvsti]

According to the tests it should, but I'm not yet committed to replace it already. I'll push my workaround soon

[4brunu]

I just tested the 0.5.0 release and it works great! Thanks! 👍
Could you please upload the last version to cocoapods?

[4brunu]

The 0.5.0 release is already showing up on cocoa pods, thanks! I think now we can close this issue.