Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues
-
@andioak Yeah I'll probably do an update video at some point. HISE development moves so fast it's hard to keep up with the most up to date (working) branch unless you're following the forums daily, so my video was intended as a sure fire way to get up and running with a working version of HISE.
-
@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:
@andioak ...my video was intended as a sure fire way to get up and running with a working version of HISE.
I would have to agree with it moving fast. I would though strongly disagree that I might want to or should move to a newer version of hise, since unless I change branch would not be possible, which was not stated in the video or anywhere on the download page or any documentation.
The master branch does not work to export one´s own projects from, if there is no solution to this without moving to another branch, right? That´s a problem. Unless the "scriptnode" branch or any of the others is the only one people are using, which is not at all apparent from just getting into this project, unless you are a well versed githubber.
And moreover it´s irrelevant. If the master branch is not working, where is the disclaimer?
As of 10 minutes ago I knew nothing about branches and thus had no way (for all I know) of getting this project to work at all. Anyone just getting into this project from a KSP environment or other lighter dev stuff will also be surprised, as I am.
-
@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.
