Search Unity

How to compile code per package? Preprocessor defines for builtin modules such as VR?

Discussion in 'Editor Workflows' started by Xarbrough, Jun 20, 2019.

  1. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    Edit: This was previously a feedback post and feature request, but since the answer below was given, it turns out that the feature already existed for assembly definition files.

    The new package manager and package-based approach for tools is great. It is also a nice addition that Unity has split many parts of the engine into builtin modules, such as Terrain or VR. However, since it is now possible to disable these builtin modules from the package manager, there should also be a way for Unity and other tool developers to check if these packages are present in the current project and also to selectively compile code.

    With our newest project we have ran into the following issue a couple of times: We are not using any VR functionality and have disabled the builtin VR package. However, some Unity packages, as well as third-party assets support VR, which means they have code such as using the XRSettings class, which in our project doesn't exist and does not compile. We don't need this part of the functionality, but there is no way for tool developers to actually check for this problem, because they cannot selectively compile their code for these packages.

    I'm unsure what the best solution would be, but a preprocessor define such as #if UNITY_PACKAGE_VR comes to mind.
     
    Last edited: Jun 27, 2019
  2. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,555
    Is the 2019.1 version define what you are looking for? So if a package is present and resolved, a define is added to your DLL

     
    Xarbrough likes this.
  3. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    @5argon Thank you! Yes, that's actually exactly what I was hoping for, but didn't realize that it was already built into Assembly Definition files. I previously reported my issue to Amplify and they did not know about this solution as well, so I thought this to be a good request, but in this case my feedback is more or less obsolete.

    With this, tool developers can create their own defines for the modules they want to optionally support. In theory, this should work well.

    However, there are two small remaining issues:
    1. Today, it seems as if almost no third party tools use asmdef. All of the asset store product we currently use in our project use the legacy folder structure with editor folders etc and no assembly definitions. Now we need to convince all these tool developers to upgrade even though many users complain about the hassle and lack of benefits of the asmdef feature. Would there be any chance to make this work without having to use asmdef?
    2. What happens if I reference two other asmdef files (3rd party tools) from my own asmdef and both of the other assemblies define the same define string e.g. "UNITY_XY" but use it in different contexts?
     
  4. steego

    steego

    Joined:
    Jul 15, 2010
    Posts:
    969
    The defines are only applied to the assembly being generated from the asmdef file, so this shouldn't be an issue.
     
    Xarbrough likes this.