Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Want more efficiency in your development work? Sign up to receive weekly tech and creative know-how from Unity experts.
    Dismiss Notice
  4. Build games and experiences that can load instantly and without install. Explore the Project Tiny Preview today!
    Dismiss Notice
  5. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  6. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Package dependent compilation

Discussion in 'Package Manager' started by Hubertsn, Jul 23, 2018.

  1. Hubertsn

    Hubertsn

    Joined:
    Aug 7, 2015
    Posts:
    6
    With the new package manager it would be great to have symbols for every package or at least for the built-in packages, so you can use #define directives for code depending on a package like you can use them already for platforms and unity versions.

    In other threads I read that some packages like the ECS use the Player Settings/Sciprting Define Symbols, but I couldn't find an overview which packages would already define a symbol.
     
  2. okcompute_unity

    okcompute_unity

    Unity Technologies

    Joined:
    Jan 16, 2017
    Posts:
    248
    Hi @Hubertsn ,

    This is something we are evaluating at the moment. Would having only one symbol for detecting the package presence would be valuable for you? The challenge we are facing in replicating Unity versions symbols scheme is the proliferation of symbols. Let say you have 100 packages in your project, defining symbol for each package versions and any helpful variations (ex: MY_PACKAGE_VERSION_2_2_3, MY_PACKAGE_VERSION_1_OR_GREATER, MY_PACKAGE_VERSION_2_OR_GREATER, MY_PACKAGE_2_2_OR_GREATER, etc) could degenerate quickly. If you could expand on your use case it would be really helpful to define the best solution.

    As for the ECS specific symbol, I suggest asking the question in the ECS forum.

    Regards,

    Pascal
     
  3. Hubertsn

    Hubertsn

    Joined:
    Aug 7, 2015
    Posts:
    6
    Hi @okcompute_unity / Pascal,

    Detecting the package presence would be a good start and in my case sufficient. Sure there will be problems with version compatibility, but I can see that this can get wild with the possibilities of packages.

    My first case where I would need it is the following. I'm using PlayMaker and made a Git Submodule out of it so I have to maintain it just once. PlayMaker offers a wide range of Scripts/Actions for Physics2D. But not all projects use Physics2D and so an error is thrown which could be fixed using a symbol for Physics2D to check if the package is present in the current project.
    For now I moved the Physics2D Actions to an optional unitypackage.

    Greetings
    Michi
     
  4. okcompute_unity

    okcompute_unity

    Unity Technologies

    Joined:
    Jan 16, 2017
    Posts:
    248
    Ok. Will see if it make sense to start up with just this one symbol. Having one voice voting for the feature helps :)

    Thanks for you feedback!

    Pascal
     
  5. sindrijo

    sindrijo

    Joined:
    Mar 11, 2014
    Posts:
    9
    This would allow packages to have 'optional dependencies' on other packages, which I'm not sure is such a good idea.
    It is better to separate 'extra features that have a dependency' into another package (which is dependent on your 'main' package).

    A project is either dependent on a package or not.

    MyPackage (Not dependent on 3rd-party package)
    MyPackage-ExtraFeatures (Dependent on 3rd-party package)

    In any case if this were to be added the defines should probably use a prefix so that they can more easily be searched for, like maybe 'PACKAGE_ or just 'PKG_'
     
  6. Hubertsn

    Hubertsn

    Joined:
    Aug 7, 2015
    Posts:
    6
    @sindrijo Your solution is good as well. It might result in duplicate code. Both solutions have their ups and downs.

    I have another issue on the subject which needs either of the solutions. You can't use the Cinemachine package without the Physics2D package because CinemachineConfiner.cs depends on Physics2D. But to use Physics2D is optional for the script (as far as I understand it).

    EDIT: The Cinemachine and Physics2D package problem is discussed here.
     
    Last edited: Aug 10, 2018