List of extensions in application descriptor

[j3k0]

Maybe my use case is a little tangent, but here is some explanation in case some discussion might be fruitful.

Some ANEs prevent the app to execute on macOS, so I want them NOT to be present when compiling for desktop.

I also happen to use a different bundle identifier for macOS and iOS platforms (because App Store Connect wouldn't let 2 apps have the same bundle id).

To achieve this, I basically have 2 project.apm files (one for mobile, one for desktop).

My build script does:

cp project-desktop.apm project.apm
apm generate app-descriptor

Or:

cp project-mobile.apm project.apm
apm generate app-descriptor

However, after changing the project.apm file, ANEs are still listed under the generated application descriptor's <extensions> tag when building for desktop. (I'm being careful to remove the generated "src/My-app.xml" before running APM (so it's not a leftover).)

apm list does return the correct list of extensions (based on those in the project.apm file), so it looks like the process generating the list of <extensions> in the application descriptor isn't using the same method to list them. My guess is it's going through the apm_packages folder.

---

Shouldn't apm have some built-in solution to handle this use case?

I think it would be nice for example to be able to specify the path to the apm_packages and project.apm file when running apm. Another bonus would be in CI environment where the src folder is read-only, or you need to keep it clean.

An example:

APM_PACKAGES=/tmp/apm_packages \
PROJECT_APM=project-ci.xml \
apm install

Most build utilities I used in other languages had the option to put all generated / downloaded files in a different folder than the source folder.

[marchbold]

Yeah sure, we were expecting this and we really want feedback from several developers before making a decision on this as we know people use very different setups with AIR currently.

Ideally we are trying to follow the principles of convention-over-configuration.

One thing I'd like to stamp out is extensions that fail to function correctly on a platform. This is bad practice and I don't think they should be published in the repository. It disobeys the primary "cross-platform" principle of AIR, in that they should always provide a default implementation and fail gracefully on unsupported platforms.

I have a few things in progress that will help here, changing the name of apm_packages being one of them and some additional deploy options.

My suggestion currently is to follow something like this for your project, which is how we generally handle applications that require major differences between platforms:

app
|____ ios 
| |____ project.apm
| |____ src
| | |____ ApplicationIOS.as 
| | |____ ApplicationIOS-app.xml
|____ android
| |____ project.apm
| |____ src
| | |____ ApplicationAndroid.as 
| | |____ ApplicationAndroid-app.xml
|____ macos
| |____ project.apm
| |____ src 
| | |____ ApplicationMacOS.as 
| | |____ ApplicationMacOS-app.xml
|____ common
| |____ src   

You setup a common src tree and import it into all your project trees with all your common application code / resources / assets etc. This is a very common structure that we have found many of our clients over the years have used and works well. It keeps the structure clean and the differences between the platforms clear.

---

Your approach of copying a project definition file and expecting the generate functions to succeed is not how the tool is intended to be used. You must call apm install, (which will construct the cache), before any of the generate commands are designed to succeed. The generate commands use the cache as they need the contents of the packages.