Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement option to specify location of index files #816

Merged
merged 1 commit into from
Oct 8, 2024

Conversation

fridrich
Copy link
Contributor

This PR implements an option "-b" for base_dir specifying location of index.html and index.js files for welle-cli web interface. It allows not to have to run the binary in the directory where those files are located.

One can test it to run it from other directory with option like for instance "-b /usr/share/welle-io/html" and the index.html and index.js files from that directory will be used.

If this option is not specified, the welle-cli behaves like before. One can test it by starting it without that option in a directory that does not have those files and then without that option in a directory that has those files.

This can be useful when debugging and the directory where the files are is read-only and the dumps go to the current directory for instance.

@fridrich
Copy link
Contributor Author

The requirement of cmake 3.10+ and the C++17 is because I use the std::filesystem::path which requires C++17 (gcc 8+)

@mpbraendli
Copy link
Collaborator

Thanks!

@AlbrechtL I'm ok with the functional change, what's the impact of switching to C++17 for downstream distribution and packaging?

@fridrich
Copy link
Contributor Author

I mean, that is possible with gcc 8. I build it with gcc 8 on SLE 12. Also the cmake 3.10 requirement is not so difficult to achieve, I guess. But the world is is now on gcc 14, so gcc 8 should be really fine. At least for me in SUSE, I am able to build it for all supported distributions.

@fridrich
Copy link
Contributor Author

Better said, I cannot build on sle12 because of the different qt6 and mp3lame and similar, but the cmake and gcc is not a problem

@mpbraendli
Copy link
Collaborator

I'm not too worried about the change. I've recently moved most of the ODR-mmbTools to C++17 too.

@AlbrechtL
Copy link
Owner

@AlbrechtL I'm ok with the functional change, what's the impact of switching to C++17 for downstream distribution and packaging?

Honestly, I have no idea. But let's see..

@AlbrechtL AlbrechtL merged commit 528da37 into AlbrechtL:next Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants