is it possible to get the IDE to trigger a custom (user supplied) makefile, or even a user specified build script rather than compile the C++ files itself....

Ive quite a few cases now where the simplicity of 'just compile all source files' is not really working for me. or at best, I end up working around it.
typical examples for me include
a) I structure my code into a number of components/shared libraries
this means i currently end up compiling separately which is a bit of a pain
b) I tend to use cmake
Id like to have bela stuff included in this, so its easy to compile outside ide, also keep compiler options in one place
c) (latest one) I'd like to use precompiled headers to speed up compilation (significantly, as ableton link is huge!)
requires you to build pch, with diff compiler options, then compile main program with compiler option to include it.

I think what would be best, is the user being able to specify a build script which gets called....
an 'agreement' that
a) it generates an executable, same name as project
b) it has a return code == 0 , is success

then the ide is simply tasked with
displaying output in console (as it does for make)
know if build has failed/succeeded via (b)

thoughts? is this something that I could achieve, without rewriting lots of code?
(Im not familiar at all with IDE, but perhaps something i can mangle into the Makefile - thought thats quite a complex beast these days)

of a cludge for pch ?
(compiling ableton link header in my render.cpp, is taking about 5 mins each time... so has been very time consuming... to the point I even consider putting it into a shared lib.. but unfortunately that doesnt help, if I need to change that lib code at all)

    note... i do understand that perhaps Bela's primary target was 'ease of use' for non-engineers.

    but on the other hand, I suspect the nature of Bela means there are quite a few software engineers using it, as its a great hardware platform... and for us, we might have slightly more 'complex' needs for projects, esp. when integrating with our other software.

    Ive actually brought this up a long time ago... (Jan 17 ! wow, time flies....)

    https://forum.bela.io/d/223-moved-managing-complex-projects

      There actually is such a feature already, which was maybe used once. If you include a run.sh file in your project, then make(and pressing run in the IDE) will simply run that (see here). This does not even need to do

      a) it generates an executable, same name as project

      the run.sh file will be in charge of doing whatever needed to run the project. What this means is entirely up to you. Notice that if from within run.sh you want to call Bela's own Makefile, you'd need to define some constants (e.g.: make PROJECT=yourProject HAS_RUN_FILE=false SHOULD_BUILD=true PROJECT_TYPE=cpp) when calling it or you'll end up recursively calling run.sh.

      Notice that this at the moment discards all the command-line settings from the IDE, but I guess those could be brought back in editing the line

      RUN_COMMAND?=bash $(RUN_FILE)

      to, e.g.:

      RUN_COMMAND?=bash $(RUN_FILE) CL="$(CL)"

      thetechnobear (compiling ableton link header in my render.cpp, is taking about 5 mins each time... so has been very time consuming... to the point I even consider putting it into a shared lib.. but unfortunately that doesnt help, if I need to change that lib code at all)

      For using it within your project could you not write a wrapper library (or just a class really) whose header does not directly include the long-to-compile headers? Something like:

      fastlink.h:

      #pragma once
class AbletonLink; // instead of including a header file, just say the class exists, don't give any indication as to what is in it

class FastAbletonLink
{
  ... expose here the methods you actually need ...
AbletonLink* obj; // <<-- as long as this is a pointer, there is no need for this file to know about the contents of the AbletonLink class
};

      fastlink.cpp:

      #include <AbletonLink-long-long-header.h>
... implementations of the methods, which may be mostly just calling the corresponding method from the AbletonLink class ...

      If there are not many methods this could be a good option (unless I am misunderstanding the issue).

      Another option to simplify your workflow, as you often use cmake could be to have the Bela code code built as a library (make lib makes lib/libbela.so and lib/libbelaextra.so) and then add that (or those) libraries as dependencies to your cmake project. This is what we do for Supercollider and Csound.

        given how this is an under-used feature currently, let me know if you have any suggestions on how it could be improved and we can probably roll them in

        sure, I'll look into it...
        in the meantime , i got the stuff working properly... so kind of left it 🙂

        This thread's kinda dead, but I've spent a good amount of time on this subject myself so I'll chime in 😁

        I've found that cross-compiling some pieces of my program with the Linaro toolchain (as discussed in this wiki page) works well for me. I have a script that needs to run on boot before initing the Bela environment, so if there are changes to it, I cross-compile and copy it to the board as part of my build script. The build script I use is just a shell script that automates input to several of the Bela build scripts so that I can run a bunch of build tasks with a keyboard shortcut from vscode.

        thetechnobear note... i do understand that perhaps Bela's primary target was 'ease of use' for non-engineers.

        but on the other hand, I suspect the nature of Bela means there are quite a few software engineers using it, as its a great hardware platform... and for us, we might have slightly more 'complex' needs for projects, esp. when integrating with our other software.

        This is pretty spot on imo - on this forum especially, I tend to see the "engineer" and "non-engineer" interests diverging more and more. However, I don't imagine that it's in the Bela dev's best interest to devote a lot of time to supporting a relatively small high-end community, so I think the more community-driven work that can be done in that field, the better.

            ebai101 However, I don't imagine that it's in the Bela dev's best interest to devote a lot of time to supporting a relatively small high-end community,

            yeah, I totally agree.... I think 'hooks' and a recognition is all we could wish for.
            (e.g. the fact the make field on the IDE is only 20 chars wide... thats not even enough for an include path 😉 )

            BUT... I do agree, perhaps the IDE is not really the right tool for my purpose...

            cross-compiling - yeah, this is something Ive been seriously considered a few time, and recently was thinking about it again - i don't need an ide, but it would I could use my favourite code editor.
            I also like the idea of not having bela running 'extra code' (ide)

            of course bela is open source, so I could be tackling these issues myself and contributing back, but unfortunately it seems whenever I bring out bela... its due to wanting to get something done, so I never invest the time I really should do to make it better (for me and others)

            hmm... will see if I can invest some time in this....
            very tempted with the cross-compiler route (I'm reasonably familiar with this due to axoloti),
            if i do it, I could document the process for others.

            one thing id like to also consider is if/how the new UI (and old 'scope') aspects could be used in this environment...
            perhaps node could run on the local machine?

            anyway, thanks @ebai101 , nice to hear others thoughts and ideas on this topic.

                k, Im building up the cross compile environment, trying to use clang
                seems to be find, except im getting a link error

                 "/usr/local/bin/arm-linux-gnueabihf-ld" --sysroot=/Users/kodiak/Projects/bela_client/sysroot -EL -X --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-linux-armhf.so.3 -o render /Users/kodiak/Projects/bela_client/sysroot/usr/lib/arm-linux-gnueabihf/crt1.o /Users/kodiak/Projects/bela_client/sysroot/usr/lib/arm-linux-gnueabihf/crti.o /Users/kodiak/Projects/bela_client/sysroot/usr/lib/gcc/arm-linux-gnueabihf/6.3.0/crtbegin.o /Users/kodiak/Projects/bela_client/sysroot/usr/lib/gcc/arm-linux-gnueabihf/6.3.0/crtfastmath.o -L/Users/kodiak/Projects/bela_client/sysroot/usr/lib/gcc/arm-linux-gnueabihf/6.3.0 -L/Users/kodiak/Projects/bela_client/sysroot/root/Bela/lib -L/Users/kodiak/Projects/bela_client/sysroot/usr/local/lib -L/Users/kodiak/Projects/bela_client/sysroot/usr/xenomai/lib -L/Users/kodiak/Projects/bela_client/sysroot/lib/arm-linux-gnueabihf -L/Users/kodiak/Projects/bela_client/sysroot/lib/../lib -L/Users/kodiak/Projects/bela_client/sysroot/usr/lib/arm-linux-gnueabihf -L/Users/kodiak/Projects/bela_client/sysroot/usr/lib/../lib -L/Users/kodiak/Projects/bela_client/sysroot/lib -L/Users/kodiak/Projects/bela_client/sysroot/usr/lib --no-as-needed -lcobalt -lmodechk -lpthread -lrt -lprussdrv -lstdc++ -lasound -lseasocks -lNE10 -lmathneon -ldl -lbela -lbelaextra /var/folders/82/hvyfd1n518vfcys507wjrgtm0000gn/T/render-8a46bb.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /Users/kodiak/Projects/bela_client/sysroot/usr/lib/gcc/arm-linux-gnueabihf/6.3.0/crtend.o /Users/kodiak/Projects/bela_client/sysroot/usr/lib/arm-linux-gnueabihf/crtn.o
/usr/local/bin/arm-linux-gnueabihf-ld: /Users/kodiak/Projects/bela_client/sysroot/usr/lib/arm-linux-gnueabihf/crt1.o: in function `_start':
(.text+0x28): undefined reference to `main'
/usr/local/bin/arm-linux-gnueabihf-ld: /Users/kodiak/Projects/bela_client/sysroot/root/Bela/lib/libbela.so: undefined reference to `BelaContextSplitter::setup(unsigned int, unsigned int, BelaContext const*)'
/usr/local/bin/arm-linux-gnueabihf-ld: /Users/kodiak/Projects/bela_client/sysroot/root/Bela/lib/libbela.so: undefined reference to `BelaContextSplitter::cleanup()'
/usr/local/bin/arm-linux-gnueabihf-ld: /Users/kodiak/Projects/bela_client/sysroot/root/Bela/lib/libbela.so: undefined reference to `BelaContextFifo::push(BelaContextFifo::fifo_id_t, BelaContext const*)'
/usr/local/bin/arm-linux-gnueabihf-ld: /Users/kodiak/Projects/bela_client/sysroot/root/Bela/lib/libbela.so: undefined reference to `DataFifo::DataFifo()'

                as you can see I include -lbela -lbelaextra , and -L/Users/kodiak/Projects/bela_client/sysroot/root/Bela/lib contains the libs (a/so)

                btw: really like belaconfig - thats really cool 🙂

                is libbela/libbelaextra missing something - or have i got something missing?

                you have to add the objects build/core/DataFifo.o build/core/BelaContextFifo.o build/core/BelaContextSplitter.o to whatever settings you are using to create libbela.so. If you created that on Bela itself, make sure you have at least this commit on it

                commit 63d5ccf053843ccc7030bbda2f8186dc96fed267
Author: Giulio Moro <giuliomoro@yahoo.it>
Date:   Sun Jan 26 20:45:05 2020 +0000

    core: added more object files to libbela

                actually just figured it out... I just needed to rebuild lib

                make lib

                the other thing i needed to do, was to copy over default_main.o (or I guess i can compile that locally)
                EDIT: indeed now I copy default_main.cpp, and compile that on the host.

                anyway cross compiling is now working nice on macOS
                im going to do some tidying up, and ensure its all running on Linux nicely, then will share what Ive done 🙂

                basically, the goal is a quick to setup environment for anyone that wants to cross compile and use the the command line on mac or linux.

                theres not really a lot to it, but I wanted it to be quick to install on new machines, as I use a few different macs and linux boxes here 😉

                ok, Ive got the basics working on both linux and macos

                https://github.com/TheTechnobear/bela_client

                basic goal is cross-compiling client on mac/linux thats easy to install and use, currently im only interested in C++ support - so not SC/PD , but I guess those are no more than copying files and launching.

                currently, it provides:
                - a quick/easy install
                - belaCompile, belaRun, belaCompileRun ... to compile/run simple cpp code (i.e. single render.cpp type things)
                - belaExec, belaCopy functions to copy/execute on bela
                - sets up normal Bela/scripts , so you can just type ide.sh stop

                testing:
                the mac version ive done a proper clean install on, the linux was a bit 'made up as i went along... as I had issues with the available clang/llvm versions on my distro... but i pretty confident its accurate (and certainly past installation its fine)

                to do:
                - add default options when running (as per IDE i guess)
                - cmake template

                cmake is the main thing, really things like belaCompile were just created so that I was clear on what compile option and executables I need to get things to compile - should be relatively easily for me to translate that to cmake (which Im pretty familiar with).

                once thats done, I'll start using 'in anger' so no doubt might add a few more things, that make it easier to do the edit,test,run workflow....

                I also want to think about
                - where i put the compiled 'projects' on bela
                - tailoring 'startup', so that i can run these projects.. or perhaps make 'compatible' with current startup routing (which starts via make)

                  thetechnobear , but I guess those are no more than copying files and launching.

                  Actually Pd projects are all built (linked-only, because all the .o files will already be ready), though - unless the provide a custom C++ file - the binaries are all the same. Either way, Bela/scripts/build_project.sh can take care of those.

                  ebai101 However, I don't imagine that it's in the Bela dev's best interest to devote a lot of time to supporting a relatively small high-end community, so I think the more community-driven work that can be done in that field, the better.

                  yup. The IDE is the pain-free way to getting started. More advanced users can use the scripts, make or any solution they come up with. The existence of the pre-built library is a way to encourage integration in different workflows (see, e.g.: here).
                  @ebai101 do you want to add a wiki entry for your VS workflow?

                  FWIW: I use vim on the board and make from the command line most of the times.

                  thetechnobear (e.g. the fact the make field on the IDE is only 20 chars wide... thats not even enough for an include path 😉 )

                  I know right, I just reopened this, which got closed for unclear reasons https://github.com/BelaPlatform/Bela/issues/362

                  As always, there is much more to do than there is time available, so ... we do what we can and we very much welcome community contributions 🙂

                          @thetechnobear looks awesome! I'll try it out when I can.

                          giuliomoro @ebai101 do you want to add a wiki entry for your VS workflow?

                          For sure - I wrote a post about it a while ago which I could edit into a page. I'd love to try and integrate with this new xc instead, though, since it looks like it'll make the setup easier.

                              giuliomoro a docker image

                              Funny you mention that, I actually tried that a little while ago - I imported a Bela image into docker and compiled some examples in a container. Everything seemed to run fine when I copied them to the board, with no other config required. I didn't have the time then to write something to interface it smoothly with the board, so I left it be.

                              A toolchain like dockcross might be perfect - would just need to make the container filesystem line up with the Bela. It could probably be extended from a dockcross image actually; their linux-armv7a image is set up for the stock BBB.

                                  ebai101 A toolchain like dockcross might be perfect - would just need to make the container filesystem line up with the Bela. It could probably be extended from a dockcross image actually; their linux-armv7a image is set up for the stock BBB

                                  sounds promising, I may have a look if time allows

                                    sent you a PR for #624 to build a 'full' library of bela objects.

                                    also Ive switch xcBela over to use update_board and xcCompile now uses this new lib.