Xcodegen: Improving support for ${target_name} expansion

Created on 7 Feb 2020  ·  9Comments  ·  Source: yonaskolb/XcodeGen

I have found there are times when it is helpful to have some variable expansion. In particular, I have a postBuildScripts that I'd like to execute. In this case it is copying some files and would be great if I could use ${target_name} in this case to expand the name to use the target name so I can cut and paste this into files.

Right now it doesn't do anything, so it remains ${target_name}.

This is what I'd like to ideally do:

    postBuildScripts:
      - script: |
          cp ${DERIVED_FILES_DIR}/${target_name}-Swift.h ${BUILT_PRODUCTS_DIR}/${target_name}.framework/Headers
          cp -rv ${BUILT_PRODUCTS_DIR}/${target_name}.swiftmodule ${BUILT_PRODUCTS_DIR}/${target_name}.framework/Modules
        name: Copy SWIFT_OBJC_INTERFACE_HEADER_NAME and swiftmodule   

Note that I have improved the above script by assigning the target name to a single variable first and then using that internally. But it will still be a nice to have.

Most helpful comment

Riffing on @liamnichols question a bit. Has there been any thought in perhaps allowing to define an alternate pattern for replacement. If this could be set either at a global level or on a property level.

Admittedly I haven't looked at any of the code. Just throwing it out there, since it would be helpful in the scripting case since you can define your shell which may change what pattern you'd need.

All 9 comments

What if you intend to or accidentally define ${target_name} as normal bash variable though?
How could we differentiate them?

Great question. Perhaps there is no good solution for this with scripts.

I did also try and use ${target_name} in not script cases and it also didn't seem to work. It only seems, per the spec, to work with targetTemplates

It only seems, per the spec, to work with targetTemplates

Sorry I didn't get your point.

But my point is, that (IMO) this would be too complicated feature to have.🙅‍♂️

I think that you can get around the limitation of the fact that target_name isn't expanded in all properties of the template by expanding it into a build setting and then referencing that... Something like this:

InternalFrameworkBase:
  templates: [VersionedInfoPlist]
  platform: iOS
  settings:
    base:
      MYPREFIX_TARGET_NAME: ${target_name}
  postBuildScripts:
    - name: Copy SWIFT_OBJC_INTERFACE_HEADER_NAME and swiftmodule
      script: |
        cp ${DERIVED_FILES_DIR}/${MYPREFIX_TARGET_NAME}-Swift.h ${BUILT_PRODUCTS_DIR}/${MYPREFIX_TARGET_NAME}.framework/Headers
        cp -rv ${BUILT_PRODUCTS_DIR}/${MYPREFIX_TARGET_NAME}.swiftmodule ${BUILT_PRODUCTS_DIR}/${MYPREFIX_TARGET_NAME}.framework/Modules 

@toshi0383 Understandable

@liamnichols A co-worker ended up using a macro to solve it.

I'd like to keep this open as I see value in this

@yonaskolb: do you see any downsides for using the ${} pattern for replacements while generating given that it’s also used at build time?

I’m just wondering if using a different pattern has ever been considered?

Riffing on @liamnichols question a bit. Has there been any thought in perhaps allowing to define an alternate pattern for replacement. If this could be set either at a global level or on a property level.

Admittedly I haven't looked at any of the code. Just throwing it out there, since it would be helpful in the scripting case since you can define your shell which may change what pattern you'd need.

Maybe we can replace ${target_name} to something like {% target_name %}.💪

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ImLaufderZeit picture ImLaufderZeit  ·  5Comments

igorkulman picture igorkulman  ·  5Comments

rpassis picture rpassis  ·  5Comments

yonaskolb picture yonaskolb  ·  3Comments

ismetanin picture ismetanin  ·  3Comments