Search Unity

  1. Get all the Unite Berlin 2018 news on the blog.
    Dismiss Notice
  2. Unity 2018.2 has arrived! Read about it here.
    Dismiss Notice
  3. We're looking for your feedback on the platforms you use and how you use them. Let us know!
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Learn more.
    Dismiss Notice
  5. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  6. Magic Leap’s Lumin SDK Technical Preview for Unity lets you get started creating content for Magic Leap One™. Find more information on our blog!
    Dismiss Notice
  7. Want to see the most recent patch releases? Take a peek at the patch release page.
    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:
    139
    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:
    139
    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 at 1:29 PM