Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues
-
@andioak Yep there's a big learning curve when moving from KSP to compiling full programs, and both git and github have learning curves of their own. Always assume that any code on github is unstable and may possibly not work, unless it is tagged as a release (or some other tag to indicate it is stable).
-
@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:
@andioak Yep there's a big learning curve when moving from KSP to compiling full programs, and both git and github have learning curves of their own. Always assume that any code on github is unstable and may possibly not work, unless it is tagged as a release (or some other tag to indicate it is stable).
I understand that it´s complicated. But I only used the master branch and files you yourself use in your videos where it supposedly can be used to produce a project, any project.
In the video you state that you "I´ll prefer to just work on the master branch on small projects", but this would not be possible here. If there´s no fix for this while using the master branch.
The master branch was updated lastly 15 months ago, according to https://github.com/christophhart/HISE/branches page. Then the "Active Branches" are "scriptnode", "full_exp" and "scriptnode_codegen_rewrite".
Is the master branch not active? Can I not use it as a current version that is functioning? Or are we waiting for a master branch merge with some of the chances made in the other branches? (where some of these types of issues have been fixed)
*I know how fresh-of-the-boat I am, but this surely has a fix that will work using the master branch.
-
I don't know if the master branch will build but even if it does it's very out of date. Most of us are using the scriptnode branch.
-
@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:
I don't know if the master branch will build but even if it does it's very out of date. Most of us are using the scriptnode branch.
You don´t know if it will build? You used it in the video. Or you don´t know if it will build with a newer version of Linux? Anyway, for me it built fine with the stuff shown in that video. But the video is about a dev situation for backwards compatibility, my favorite perspective by the way
And as I state above that is what I used to create my Linux OS.I guess compared to the other branches the master could be less up-to-date on matters pertaining to the features made in those new branches, but I would never figure that it is out of function, cause it functioned at the time of the last commit. Also it is still waiting to be merged with the issue-fixes that could be merged with it, right? Isn´t that the point of branches? To be used as dev points and later integrated/merged into the master?
But how did you manage to use this? You used the identical OS with the identical libs and dependencies, did you never use this? Surely there is a simple fix for my issues above using only the master branch.
-
You don´t know if it will build?
I think I said in the video that if you want stable code to go to the releases.
Anyway, for me it built fine with the stuff shown in that video.
In the video I use the release version, not the master branch. But they are pretty close in date so probably not much difference between them.
but I would never figure that it is out of function, cause it functioned at the time of the last commit.
It should function just fine, but usually I can offer better advice to help you solve problems if you are using the same version as me (and probably anyone else who responds to this thread). However I think the solution to your problem might be as simple as going into the directory containing the makefile and running
make cleanand then trying to compile again.Isn´t that the point of branches? To be used as dev points and later integrated/merged into the master?
Yes, when the next stable version of HISE is ready all necessary dev branches will be merged into the master branch.
More recent version of HISE in the scriptnode branch should contain various changes I've made to make it simpler to compile on GNU/Linux and this may also be a solution to your issue.
-
I think I said in the video that if you want stable code to go to the releases.
I downloaded the zip from your video, so that is the release, then. I knew nothing about the "master" branch or any other at the time. So my version is the release 2.1.
... I think the solution to your problem might be as simple as going into the directory containing the makefile and running
make cleanand then trying to compile again.As I state in my explanation I "delete the previous export by clicking on “Clean build directory” and then clicking on “Export as Standalone Application” regenerating all files". That deletes and clean the entire "Binaries" directory. No need for
make cleanafter that. Also in my initial message I say:upon saving the .jucer file it generates the same files later generated by the shell script “batchCompileLinux.sh”. Having had issues with the build during the execution of the .sh batch file I therefore delete the folders “Builds” and “JuceLibraryCode” (folders created upon saving .jucer file) while leaving the folders “Source” and “temp” untouched, since they were exported by HISE export procedure.
Meaning I completely delete the two folders that are generated when saving the .jucer file after adding IPP flags and the
-no-pie, as you mention in your earlier posts when you dealt with this issue specifically. So they are not present in the "Binaries" folder when running thesh batchCompileLinux.shagain.More recent version of HISE in the scriptnode branch should contain various changes I've made to make it simpler to compile on GNU/Linux and this may also be a solution to your issue.
So are you using Linux Mint 17.3 still or did you give up and upgrade to a newer system? Or does your updates to the scriptnode branch have fixes for building and exporting on Linux Mint 17 or Ubuntu 14? (or older Linux´s)
I ask because I want to keep it as old as possible, to not have to ask future customers to upgrade their OS:es. Feels unprofessional.
Also additionally, linux distros are not like macOS where an OS upgrade is super easy, seems more like the opposite. -
@andioak I'm on 19.3 for my main system but I build on 17.3 for the same reasons you do. Upgrading Linux Mint is pretty straightforward if you use the upgrade manager (I'm not sure what version of Mint that was introduced in though). Try the scriptnode branch, I'm doubtful also whether it will solve the problem, but at least we'll both be using the same version so it will rule out that possibility.
-
Try the scriptnode branch
I have downloaded the latest zip from /tree/scriptnode/ as you suggested, but I have errors with compiling on mac. Errors that seem to change using different settings in the .jucer file, as seen here:
Building HISE on macOS (10.13) errors and questions about using /auto_build/ files in hise source folder
I just tried to compile the latest commit of the branch "scriptnode" (2020-08-20) on my macOS system. 21 errors and about 59 warnings. The errors stop the bu...
Forum (forum.hise.audio)
My question here is if there are any requirements for changing the settings in the "HISE standalone.jucer" project included in the /Projects/ folder? Is there a magic formula one needs to choose for that to work from the Projucer?
I ask because the settings on some things in that .jucer file have changed since the video, based off the Release 2.1.
-
I haven't built on Mac for a few months so I'm not sure if anything has changed with regards to building on that platform, hopefully some of the Mac users around here can chip in and answer those questions.
-
@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:
... hopefully some of the Mac users around here can chip in and answer those questions.
Indeed, hopefully. But on the other forum post.
