Fix parsing problems with FL Studio 20.9 project files. #98
Conversation
…auto-download and default path override options for the FL parser to CMakeLists.txt. Changed referenced Monad FL parser version to be able to parse FL 20.9 project files.
.appveyor.yml
Outdated
| @@ -17,12 +17,15 @@ install: | |||
| Invoke-WebRequest "https://web.archive.org/web/20200502121517/https://www.steinberg.net/sdk_downloads/vstsdk366_27_06_2016_build_61.zip" -OutFile "vstsdk.zip" | |||
| Expand-Archive "vstsdk.zip" "C:\tmp" | |||
| } | |||
| if (-Not (Test-Path "C:\tmp\Monad.FLParser.dll")) { | |||
| Invoke-WebRequest "https://github.com/LeStahL/FLParser/releases/download/compatibility-20.9/Monad.FLParser.dll" -OutFile "C:\tmp\Monad.FLParser.dll" | |||
There was a problem hiding this comment.
should we maybe include the FL parser as source in a subdir, similar to how we handle the VST SDK, instead of linking an external binary?
There was a problem hiding this comment.
No problem! 'Other stuff' turned out great! :)
We could add the FL parser source at configure time and compile it, instead of downloading the binary, with only the implication of requiring a higher .NET build tools version than we do now. We have the options
(1) add the FL parser repo as git submodule.
(2) use CMake to download the source from the FL parser repo at configure time.
To build it together with WS, we could
(a) add a library target for the FL parser to the WaveSabreConvert CMakeLists.txt,
(b) modify the FL parser to include a CMakeLists.txt
Let me know which one you'd prefer. I think (2a) is the option most similiar to the VST SDK handling.
There was a problem hiding this comment.
No problem! 'Other stuff' turned out great! :)
cheers!
I like both 2a and 2b. Obviously 2a is more localized/practical and doesn't rely on external maintainers to do or accept changes in their repo. I especially like it if we can reference a specific commit, which means explicitly updating it from time to time, but I'd rather do that than have the rug pulled under us if/when breaking changes happen.
So yeah, tl;dr I like 2a, and perhaps we can look into 2b at some point in the future of monad wants to support cmake explicitly.
There was a problem hiding this comment.
ok, changed this. Some other changes were necessary:
- Removed the VS 2013 configuration, because it lacks the required C# language version for the FL parser.
- Added the VS 2022 configuration, because it exists now and is interesting.
- Changed the Wayback request URI (this seems to have changed in the meantime, but because of the cache, none of the other pipelines have failed so far).
If Monad decide, at some point, to unarchive their FL parser repo, we can use the now included CMakeLists.txt for a CMake-support-PR.
There was a problem hiding this comment.
Ok, and now it references a specific commit as requested :D
LeStahL
force-pushed
the
fix-flp-null-reference
branch
from
045702b to
402a53b
Compare
LeStahL
force-pushed
the
fix-flp-null-reference
branch
from
402a53b to
a7566c2
Compare
LeStahL
force-pushed
the
fix-flp-null-reference
branch
from
b3d5bd2 to
7a9ddc5
Compare
|
After using the code in this PR for a while, I have mixed feelings about this PR: I should remove the |
Removed the Monad FL Parser binary from the repository. Added opt-in auto-download and default path override options for the FL parser to CMakeLists.txt. Changed referenced Monad FL parser version to be able to parse FL 20.9 project files.
Implements #97.