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

build: Add support for building mcu code on MacOS #6337

Conversation

thatcomputerguy0101
Copy link

This change is mostly for development purposes so that experimental MCU code can be built and deployed without one of the fully supported Linux environments. I restored some of the deleted files from the bossac dependency and made some tweaks to the build scripts to adapt to the different environment. With the proper compiler installed corresponding to the MCU archetecture, this worked for me on both x86_64 and ARM64 Macs.

I restored some of the deleted files from the bossac dependancy and made some tweaks to the build scripts to adapt to the different environment.

Signed-off-by: Alan Everett <[email protected]>
Signed-off-by: Alan Everett <[email protected]>
The new install script had a few errors since I had installed the packages directly, and several of the packages underwent name changes since I originally wrote it.

Signed-off-by: Alan Everett <[email protected]>
@github-actions
Copy link

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

  1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
    If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
  2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
  3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

@thatcomputerguy0101
Copy link
Author

It may be possible to extend this into full MacOS support, especially with the majority of Klipper being in Python. Would this be useful?

@KevinOConnor
Copy link
Collaborator

Thanks.

One question I have is - is it possible to run a docker container on macos that can successfully compile (and/or run) Klipper?

In general, I'm leery of adding if/else type of conditions to the build rules for individual build targets. In past experience I found that doing so leads to excessive build rules that become difficult to maintain. It seems far simpler to emulate one base build system (eg, via containers) than to maintain custom build rules for so many different possible build environments.

Separately, some changes (like adding bossac build files) seem fine, but would need to be squash-and-merged into a single commit. That is, we don't want to mix changes to flash_usb.py, with Makefile changes, with bossac changes in a single commit - as that makes it difficult to use important tools like bit bisect and git revert.

-Kevin

@thatcomputerguy0101
Copy link
Author

thatcomputerguy0101 commented Sep 29, 2023

As far as I can tell, it seems to be impossible to forward USB or serial ports in the default Docker engine for MacOS Docker Deskop without using some utility like socat to pipe the serial port over a network interface. I believe that is due to missing feature support in the underlying virtualization framework. There is apparently a Virtualbox-based Docker host that can share USB ports, which I haven't yet explored, but would make for a higher barrier of entry over the well-published Docker Desktop.

With one exception, the changes that I made so far are either user-invoked (the install script) or detect feature differences (the serial port detection). The one exception being the cpp compiler condition in the Makefile, which I now realize I could redo to detect the output of cpp --version since that reports using clang if that is the underlying implementation. Would strictly using feature detection instead of making environment assumptions if in "MacOS" make you less leery?

With respect to the commit organization, are you saying that the first commit should be split apart, or that all of these commits should be squashed into one? Not mixing changes to different files and squash-and-merge into a single commit seems to be conflicting information to me.

@github-actions
Copy link

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

@github-actions github-actions bot closed this Oct 14, 2023
@KevinOConnor KevinOConnor reopened this Oct 14, 2023
Rather than detecting if the host is using Darwin, the cpp version script now checks if it's version report includes clang, at which point it will replace cpp with clang (in preprocessor mode). This is slightly less intrusive then the previous iteration as the regular flow of the script is maintained for most operating systems and `CPP` is only changed when needed.

Signed-off-by: Alan Everett <[email protected]>
@github-actions
Copy link

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

@github-actions github-actions bot closed this Oct 30, 2023
@KevinOConnor
Copy link
Collaborator

Thanks. And sorry for the delay in responding.

What I meant is, splitting the commits into separate atomic parts (not merging together, and not having many commits with merged functionality).

So, for example, if we need to place a space between -I and $(OUT) that's fine and if we need a libclean that's fine, but those types of changes ideally would not be in the same commit as a bossac change. Similarly for flash_usb changes.

Also, I'm not sure it is a good idea to try to guess the CPP version in the makefiles - that type of logic could become a long-term maintenance burden. For the unusual build platforms I think it is fine for users to know that they need to run make CPP="clang -E".

-Kevin

@github-actions github-actions bot locked and limited conversation to collaborators Oct 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants