Feedback Feature Request : Allow Packages to define GLOBAL Script Define Symbols

Example problem:

1. I have a package "FOO" that implements feature "FOO_A".
2. I have a package "BAR" that implements feature "BAR_B".
3. I have a small bit of code that depends on both FOO_A and BAR_B, to create feature "FOOBAR_C".

This raises the following problem:
Our company has created literally hundreds of FOOBAR_C code snippets. Some are large enough to justify their own package, but many are not.

But, I would still like to package these smaller FOOBAR_C features. It seems like I have to create a third package, FOOBAR, which depends on the other two. This is cumbersome and leads to exponential package creation. Bleh.

Thus, the feature request:
Feature: Simply including a package in a project would add all scripting define symbols defined in the package.json to the project-wide Script Define Symbols List, implicitly. I could then use this global scripting define symbol to conditionally add this FOOBAR_C code.

Maybe the Inspector could also allow you to TOGGLE those define symbols, with true as the default value.

Thus, rather than having hundreds of packages, I only need optional dependencies and preprocessor directives (e.g.

#if

), making FOOBAR_C automatically enabled when those two packages merge.

Adding this new feature to Unity's example (from here), it would look like this:

Code (JSON):

1.  
2. {
3.   "name": "com.unity.example",
4.   "version": "1.2.3",
5.   "displayName": "Package Example",
6.   "description": "This is an example package",
7.   "unity": "2019.1",
8.   "unityRelease": "0b5",
9.   "dependencies": {
10.     "com.unity.some-package": "1.0.0",
11.     "com.unity.other-package": "2.0.0"
12. },
13. "keywords": [
14.     "keyword1",
15.     "keyword2",
16.     "keyword3"
17.   ],
18.   "author": {
19.     "name": "Unity",
20.     "email": "unity@example.com",
21.     "url": "https://www.unity3d.com"
22.   },
23. "scriptDefines": [
24.     "UNITY_SOMEPACKAGE",
25.     "SOME_CUSTOM_FEATURE_ENABLED",
26.   ],
27. }

Note the new

"scriptDefines"

JSON key with an array of values.

You could even automatically generate based on the name.
E.g.

com.unity.example

becomes

COM_UNITY_EXAMPLE

.

Obviously, this is all possible manually or via our own custom script, but it would be nice to automate. Unity obviously does this under the hood for some internal tools. Thanks!

 

Hello there. Thank you for your feedback and apologies for the delay in reply.

Unfortunately, this would be something that we cannot implement at present. This can/will introduce DEFINE conflicts and problems. For instance, project code could rely on FOOBAR_C to be present to turn on some code, and an unrelated package happens to declare that define, causing the code to be "turned on", but failing to compile because the actual code it needs to use isn't even present.

The other idea that there could be defines generated automatically, e.g. "COM_UNITY_EXAMPLE", is something we don't see much benefit from: without the package version, most dependent code will be turned on (similarly to the above example) and break if the wrong package version is there. We could generate instead: COM_UNITY_EXAMPLE, COM_UNITY_EXAMPLE_2, COM_UNITY_EXAMPLE_2_OR_NEWER, COM_UNITY_EXAMPLE_2_1, COM_UNITY_EXAMPLE_2_0_OR_NEWER, COM_UNITY_EXAMPLE_2_1_OR_NEWER, COM_UNITY_EXAMPLE_2_1_5, COM_UNITY_EXAMPLE_2_1_0_OR_NEWER, ... but as you can easily see that list wouldn't scale up with hundreds of packages at high versions.

A potential workaround for your specific use cases would be to accompany your code snippets with .asmdef files, and use the "versionDefines" property of asmdefs to control which extra define is set.

 

@UnityMaru Fair points, and no worries about the delay. Yeah - generating defines would get quite large quite quickly.

But, out of curiosity, is there a max character limit or count on Script Define Symbols? If not, is there a specific concern about bloat? Even a few hundred packages would only result in a few kb of defines, and it actually would then allow very granular package and dependency management.

AFAIK, preprocessor directives are not included in built .DLL's, so it would only bloat the IDE (possibly) and project (marginally).

 

This is a very important feature!
Please consider implementing it, at least just for the package name (COM_UNITY_EXAMPLE)
Even without version it helps activate code that operates on its own to serve another package!
So 1 define is better than none!

 

As the employee mentioned, version defines can help. I believe they can basically do what you want with nothing special needed.
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html#define-symbols
All you need to do is add the appropriate entries for the asmdef file for the assemblies that require specific packages to be available for parts of the code contained in the assembly. Unity’s first-party packages already do something like this for handling URP/HDRP-specific code when you install one of those render pipelines. This also handles the case where you need to compose a synthetic define based off multiple packages being present - you can do something like the following at the start of C# files that need that symbol:

Code (csharp):

1. #if PACKAGE_1_DEFINE && PACKAGE_2_DEFINE
2. #DEFINE COMBINED_DEFINE_1
3. #endif

This does get a little repetitive, but it’s probably the least of your worries - you can get the functionality (more or less) that OP wants when you package code as a custom assembly, which generally should be the case - you should be able to avoid falling back to dumping your code in Assembly-CSharp just by using your own custom project-wide assembly. You gain additional control over the compilation of your code and don’t really lose much in that transition. When doing that, the real pain is making sure all required assembly definition references etc. are added, but that’s only when configuring things at first or when adding a new package with an assembly that will be referenced by code in that assembly.

 

Ok thanks for the response, i'm already doing this for my upm packages but the definition is not detectable from outside an asmdef unless there's asmdefs everywhere

the end user will have to create an asmdef rule for a define for my package,
and in some cases even an asmdef file, as i'm sure some people don't use them

My post was about an automatic per-package single define that the user could have without setting up any .asmdef or define rule
it can be triggered optionally (i.e. toggle in the package's asmdef)

Also another solution could be to expand the Settings/Player defines section so that the user can add custom rules just as in an asmdef (for users that still don't use them)

 

Thanks for the detailed response, and for shedding some light further on the motivations behind your decisions.
This clears all remaining uncertainty about how to proceed in the best way (from a user perspective).