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

[refactoring] Cleanup of cmake build process #946

Closed
Nightwalker-87 opened this issue Apr 25, 2020 · 5 comments · Fixed by #947
Closed

[refactoring] Cleanup of cmake build process #946

Nightwalker-87 opened this issue Apr 25, 2020 · 5 comments · Fixed by #947

Comments

@Nightwalker-87
Copy link
Member

I've been actively working on a major cleanup of our cmake build routine.
Related changes will go into the pkg branch.
We should see some testing and verification as soon as a PR is opened.

@Nightwalker-87 Nightwalker-87 added this to the v1.6.1 milestone Apr 25, 2020
@Nightwalker-87 Nightwalker-87 self-assigned this Apr 25, 2020
@Nightwalker-87 Nightwalker-87 changed the title [Refactoring] Cleanup of cmake build process [refactoring] Cleanup of cmake build process Apr 25, 2020
@Nightwalker-87
Copy link
Member Author

@chenguokai: It looks as if it is necessary to figure out the correct destination for the GUI to install to. As far as I have found out, the file gui.ui and the stlink-gui executable are not installed to the same output directory what should be the case IMHO (otherwise one would have to switch to the directory containing the ui-file in order for the executable to launch, which is not helpful at all). Also we have a stlink-gui-local and a stlink-gui executable. We need to define what should go where upon install.

@Nightwalker-87
Copy link
Member Author

Here is my proposal for the updated cmake GUI build: https://pastebin.com/WmH2Uek6

@chenguokai
Copy link
Collaborator

I am not so familiar with cmake and gtk. Sorry that I cannot provide any comments on the proposal.
One thing that I am sure is, there is no need to tweak those paths specially for macOS. Once I thought the GUI version would be compiled into an .app bundle on macOS that is expected to resident in /Applications. Fortunately it is not, so if Linux and BSDs find one path good, so will macOS do.

@Nightwalker-87
Copy link
Member Author

That's ok, I just have the impression that something was wrong there before I even started to clean things up. Maybe someone else can provide some feedback on this.

Apart from a few minor open questions I seem to be trough with this now. With respect to current coding activities around the stlink-library, st-info and st-flash I have not completely transitioned the file structure yet. Thus the rest will take place in a second step later on.

@Nightwalker-87
Copy link
Member Author

Nightwalker-87 commented Apr 25, 2020

I have made up my mind after some local testing:
Up on sudo make install the executable stlink-gui will be installed to /usr/local/bin (with /usr/local/ being the standard prefix) together with it's stlink-gui.ui file and the other binaries of the toolset (st-flash, st-info and st-util). This ensures that both files for the gui launch are always together and solves the problem mentioned before as the GUI now becomes directly accessible without the requirement for any additional steps or settings.

@Nightwalker-87 Nightwalker-87 linked a pull request Apr 25, 2020 that will close this issue
@stlink-org stlink-org locked as resolved and limited conversation to collaborators Jun 28, 2020
@Nightwalker-87 Nightwalker-87 moved this to Done in Release v1.6.1 Apr 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants