search

ynput / ayon-usd-resolver

Home of AYON USD resolver plugin
Apache License 2.0
5 stars 0 forks source link

Maya + Unreal Build scripts (Win/Linux) #15

Closed Lypsolon closed 2 months ago

Lypsolon commented 2 months ago

im opening this pr to close the other Pr as this branch was created from the other branch and contains all the important work from it. this PR also serves to block further development from me until both plugins are fully working and tested for both Os setups.

this PR implements

m-u-r-p-h-y commented 2 months ago

Is Ondra the only one to help here or can we test something from a user perspective as well? If so, we need some instructions :)

Lypsolon commented 2 months ago

Is Ondra the only one to help here or can we test something from a user perspective as well? If so, we need some instructions :)

im not sure tbh right now. the main thing on this branch is resolver loading on the Usd side and the compile time linking errors that might be there on the windows side.

currently there is no User perspective on this repo because the user interaction / server settings will be handled by the AyonUsd plugin.

so im gonna answer that with an: im not sure.

Lypsolon commented 2 months ago

COMPILEPLUGIN @antirotor

1: I believe the current separation is better than unifying them into one folder. My reason for that is that having all the resolvers inside a folder can make it hard to find things if you build, for eg - win, Alma9, Alma8, CentOs7, CentOsStream9, Ubunto, etc I also want to note: that we currently only support Houdini 19.5 and 20, and with the current separation, this already creates 4 files in the HouLinux folder; if we add 2 more versions, e.g. 20.5, and 21, we will end up with 8 files. if we now unify Windows and Linux foulders then we have 16 files, 8 of those files do not matter to you if you're only working on one platform at a time, and that's mostly the case; even I don't care for the Windows files when on Linux and the other way around. So, in the end, I don't see a disadvantage in having them separated the way they are right now, but I can see an annoyance in having them all bundled up. Do you have a reason for wanting that change?

2: I'm not sure if I'm following TBH. As I see it, the naming is unified ( {platform}{PythonVersoin}{SoftwareVersion} ). I personally avoid . and - in naming schemes as much as I can. We could add underscores between the parts of the name, but I don't know if that would be a big advantage. if you have a naming scheme you would like let me know what it is and why you would like it.

antirotor commented 2 months ago

Do you have a reason for wanting that change?

Nothing really important, just to avoid duplication of information in dir/file hierarchy. So you basically merge {platform} in{app}{Platform}/{Platform}{Python}{App}{app_version}.cmake`. But you have point in number of files in one directory and anyway, it is not that big issue, more like personal preference.

I'm not sure if I'm following TBH. As I see it, the naming is unified ( {platform}{PythonVersoin}{SoftwareVersion} )

By unification, I meant:

HouWin/WindowsPy310Houdini20.cmake vs. MayaWin/WinPy311Maya2025.cmake

(notice Windows vs. Win)

I guess it is problem just for *HouWin scripts and I vote for shorter win. I don't mind came case or snake case - again, it is more of personal preference.

I think dashes and underscores actually help with readability and they are used everywhere - in package repositories, like:

LibRaw-0.20.2-6.el9.x86_64.rpm (centos9) wayland-1.22.0.ebuild (gentoo) libraw_0.20.2-1+deb11u1.dsc (debian)

Lypsolon commented 2 months ago

Do you have a reason for wanting that change?

Nothing really important, just to avoid duplication of information in dir/file hierarchy. So you basically merge {platform} in{app}{Platform}/{Platform}{Python}{App}{app_version}.cmake`. But you have point in number of files in one directory and anyway, it is not that big issue, more like personal preference.

I'm not sure if I'm following TBH. As I see it, the naming is unified ( {platform}{PythonVersoin}{SoftwareVersion} )

By unification, I meant:

HouWin/WindowsPy310Houdini20.cmake vs. MayaWin/WinPy311Maya2025.cmake

(notice Windows vs. Win)

I guess it is problem just for *HouWin scripts and I vote for shorter win. I don't mind came case or snake case - again, it is more of personal preference.

I think dashes and underscores actually help with readability and they are used everywhere - in package repositories, like:

LibRaw-0.20.2-6.el9.x86_64.rpm (centos9) wayland-1.22.0.ebuild (gentoo) libraw_0.20.2-1+deb11u1.dsc (debian)

Okay, perfect, I see what you mean. I would propose to have an extra PR for fixing the naming setup just to have it nice and clean and maybe because I'm afraid off merge confilkts. in that case, I would say renaming to {AppName}{platform}/{platform}{AppName}{AppVersion}Py{PythonVersion}.cmake and for platform I would say (win, linux, mac) as base options but that might need to be extended with things like centOs7 or so if we need specific builds that are linux but need special care. I would still like to keep them in the folders like they are right now because, like I said, I find it annoying to see a lot of files that I don't need at the moment.