[ENH] Remove bin folder2

[juangpc]

Related to #927. Different strategy. Linking to resources folder rather than data, general, design, etc... independently.

Still to do:

• [x] solve module mne-cpp-test-data so that it resides in data folder.
• [x] search for any reference on mne-cpp-test-data and update
• [x] search and update references to mne_rt_server/plugins
• [x] deploy.bat
• [x] wasm.sh and wasmtest.yml
• [x] wasm_test.yml ( review all workflow files)
• [x] release.yml
• [x] coverity.yml
• [x] search for any reference to bin folder. in code or documentation.
• [x] Search and remove any reference to jom which we no longer need. (housekeeping).
• [x] review and update all documentation for references to bin folder. In documentation, for instance we should stipulate clearly that we show examples for Release version anything will be the same for Debug build type.
• [x] mne_scan_plugins should be saved inside resources? (instead of bin)
• [x] mne_analyze_plugins should be saved inside resources? (see ci_deployment.md)
• [ ]

[juangpc]

Can we go through the remaining field? Got doubts on wasm, coverity and plugins during deployment.

[juangpc]

wasm problems will be updated in a future pr.

ready for final reviews.

[juangpc]

Not working on windows.

Problem is that there is only two options to make the executables (apps, tests, examples) find the correct library.

1. have everything in the same folder. --> bin.
2. modify the path variable before calling any executable.
3. linking statically.
4. have a symlink in every directory where there is an executable looking at the lib/ directory where the actual file is.

1 is Exactly the opposite of all this work. 2 is impractical, breaks abstraction and requires to have a script wrapping every executable. 3 this is where we should live. 4 the less disgusting solution.

While developing you don't notice because Qt Creator "tricks"/"helps" you and injects the necessary paths where the libs are before calling an application. aka the wrapper solution.

Another solution is to have everything in the out/Build_Name/ folder. It will still allow to have several competing development to test. However it is a big distinction between scripts/tools because now you have to search for tests given a pattern rather than go to a folder.

This is a bit crazy.

[juangpc]

Also, for some reason both static and dynamic libraries are being compiled on windows a the same time.

[juangpc]

I think the best option is to keep the sound configuration for mac and linux and in windows just put all the applications and libraries into apps folder. After all examples, tests and applications are all applications. Librariesa are not but it is the only way to work with windows. Besides the documentation stays the same because we talk of the the out/Release/apps folder there.

[juangpc]

Experimenting with different library linking strategies, ended up sending different flags to cmake. Checkout build_project.

Todoes:

• [x] some tests are failing for some reason. but only on windows. cant see the printf or std::cout on windows for some reason.
• [x] some files have editing changes on them that need to be reverted. for instance some tests.
• [x] finish build_project with extra args.
• [x] finish update deploy.bat
• [x] finish update on test all bat
• [x] Wasm needs tlc.

notes. There is quite a lot written out there about linking dynamically and statically. I think that shared linking is a bit more restrictive regarding seg fault capacity when you try to access a variable before loading or after unloading, for instance. but what works for shared, should work for static. (i guess).

nice cmake reference another nice ref last one got from here another must read last one is quite interesting because it shows how the cmake project is driven.

At this point not sure if dual linking is a good idea. static linking i think is the way to go, given we're open source an so on. not exactly the correct license but that could change if needed.

notes to me. dynamic linking has few advantages other than in plugins. and hot loading modules etc. if qt doesnt allow static linking for specific licenses, it is a bad choice. qt creator does quite a few things implicitly to ease user experience. You need to understand those (path injection for libraries so that they are found, etc...) It is important to understand those so that differences between dev and user environment render the project a dll-nightmare to use. cmake is not multiplatform, breaks abstraction all the time, has quite a few quirks, tricks, implicit features, etc. and most importantly it requires you to go beyond the intended api and understand how things work at the backend. so you start building the tool rather than your original objective. It is a standard, it is just a bad one.

This is close to being ready. @gabrielbmotta can you help me with the remaining todoes? Some decisions being made are arbitrary, can be reverted. Im thinking for instance on putting all tools into tools/ folder rather than separate folders. we can talk about it.

[juangpc]

Why deploy.bat in its linux configuration depends on AppImage? (line. 518) This is ready for a review.

[juangpc]

ready for review