-
Notifications
You must be signed in to change notification settings - Fork 110
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
Cleanup and add a Makefile #161
Conversation
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the boards cleanup but I'm not sure if the Makefile is better. We were just relying on cargo to build and now we have cargo + make to maintain. Is this something we could supplement with just documentation?
Thank you for your contribution, I like the idea of moving the layout files. Can we please split out the discussion about the build system in general and the creation of a Makefile in particular to a separate issue? I created one for that topic: #162 |
The advantage with Makefiles is that it's easy for new people to understand. Someone can clone this repo and run As for just using Cargo, I don't think Cargo is powerful enough or easy to use enough for our use case right now. It's also not common (and not used outside of Rust), so it's another learning curve. On top of that, Tock and libtoc-c both use Make, so now we all use the same thing. |
Quick note:
The advantage with Makefiles is that it's easy for new people to
understand. Someone can clone this repo and run make and know what to do.
Was the exact impetus for doing this in the kernel. Phil argued strongly
(and in retrospect correctly) that being able to clone a repo, type "make",
and have something useful happen is very important, even if the Makefile is
just a one-liner that invokes "cargo build" [obviously, the kernel make
does more].
I tried briefly to introduce more complex build systems into libtock-c, but
we walked that back. The reality is that one person investing complexity
into a well-known build system (there are so many $'s in those Makefiles)
is better than 1000 new people learning something complex to be able to
build a project.
The interface is important, and for better or worse, decades of software
history have taught people "(1) Download software. (2) Type 'make'."
…On Tue, Mar 10, 2020 at 10:47 AM Alistair Francis ***@***.***> wrote:
The advantage with Makefiles is that it's easy for new people to
understand. Someone can clone this repo and run make and know what to do.
The current method of run some random scripts is extremely confusing.
Documenting something that is confusing only helps so much as people don't
read documentation and that effort could be better spent just making it not
confusing.\
As for just using Cargo, I don't think Cargo is powerful enough or easy to
use enough for our use case right now. It's also not common (and not used
outside of Rust), so it's another learning curve.
On top of that, Tock and libtoc-c both use Make, so now we all use the
same thing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#161?email_source=notifications&email_token=AACS3XRRDJXVBLC6VTEIVWTRGZ4KVA5CNFSM4LEUJSCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOMOPKQ#issuecomment-597223338>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACS3XUEQUZG5YO3SSFIJITRGZ4KVANCNFSM4LEUJSCA>
.
|
Exactly! It's what everyone expects and our In no way is this a move to get rid of Cargo. Replacing Cargo doesn't give you anything, this is just a simple wrapper to avoid people having to remember/discover the magic arguments to get their board working. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not very convinced that make is a good tool. From my understanding, it was designed to provide build management and change detection to old programming languages. Something that has become completely obsolete with cargo
.
From my point, it's okay to use make if people insist. But I would like to let you know that when I got in touch with Tock OS for the first time, my reaction was that I wanted to stop immediately being annoyed by the fact that I was forced to install make which I considered a tool from the stone age.
Thus, using make is not a guarantee that people will appreciate the toolchain as in my case it lead to the opposite effect.
tools/list_boards.sh
Outdated
#!/usr/bin/env bash | ||
|
||
# Find boards based on folders with Makefiles | ||
for b in $(find boards -maxdepth 4 | egrep 'layout'); do | ||
b1=${b#boards/layout_} | ||
b2=${b1%.ld} | ||
echo $b2 | ||
done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be a part of the makefile?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be able to, but I think it might be cleaner being outside
I agree that make is not good. But it is ubiquitous. Having Having |
4eb378e
to
1cc6a8c
Compare
I'm amazed you didn't have Make installed, it's so commonly used in open source projects. Right now you can build the OpenTitan platform, but accidentally enable atomics via the target flag, which results in a binary that will crash. There is no way that is clear to users and is prone to errors. I have updated the Makefile to support: flashing, features and debug builds. It's all self documenting ( |
1cc6a8c
to
a3bd8c4
Compare
Signed-off-by: Alistair Francis <[email protected]>
It is commonly used in old programming languages that aren't shipped with build management. As I said, for me it's a tool from the stone age of computer science and I was not expecting to ever use it again, especially in the context of Rust which is shipped with a build management system. Keep in mind that, like me, there are a lot of people that never use it and don't have it installed since it's not required when working with more modern languages like Java, Phython, JavaScript or Rust. Installing dependencies like Make was one of the hurdles when we did a workshop involving |
Can we move this discussion to #162 and merge the other changes in this PR in the meanwhile? It's not just adding a Makefile but adding just another build system to the existing one (I doubt that Makefiles will replace cargo, but if we were consequent, it should). I think we should have a structured discussion about the requirements we have for the build system. |
a3bd8c4
to
3d01de5
Compare
Instead of specifying an environment variable each time you can permanently configure your platform by writing its name into a file named `platform`, e.g. | ||
|
||
```bash | ||
echo nrf52 > platform | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, this feature is no longer supported? Then, it should be removed from the build.rs
script. Or you might consider bringing it back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The build.rs
checks whether the PLATFORM
env variable is set and, if not, checks whether the file platform
is present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will still do that, I haven't change build.rs
. I just don't think this needs to be documented in the top level README
anymore as it isn't really user exposed.
3d01de5
to
daa0fea
Compare
Could you adapt |
daa0fea
to
28c3fef
Compare
I just pushed an update addressing all of your comments. |
I partially agree. But this PR commits libtock-rs to having a Makefile instead of a modern build system also in the CI. Moreover, we just wrap some functionality of Cargo in a Makefile (instead of just deleting Cargo.toml). I see important points in the tock kernel build system not to use make:
This is something you get for free when you just use cargo but now require additional work (adding some command somewhere in a Makefile). I tried to fix that by making the kernel repo a cargo workspace but gave up. This is exactly the maintance hell you get into when you use Makefiles. I would agree to having a Makefile in the repo because people coming from the embedded world feel that this takes away some initial hurdles. But the build system should still be make-free so it can be easily maintained by people having only background in Rust (at least this is a Rust library). |
I believe this could be fixed by a validation in ´build.rs` We just were not aware of this issue. |
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
e40e63e
to
cc49bf0
Compare
I have addressed all comments |
@echo " - hail" | ||
@echo " - nrf52840" | ||
@echo " - opentitan" | ||
@echo " - hifive1" | ||
@echo " - nrf52" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I really like about this PR is that the platform names have been cleaned up. Before, it was a mixture of CPU architectures and board layouts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly! :)
The cleanup is really nice and I have the feeling that many find the Makefile helpful. bors d+ |
✌️ alistair23 can now approve this pull request. To approve and merge a pull request, simply reply with |
bors r+ |
Build succeeded |
After looking at #160 I think there are some things we can do to make it easier to get started with
libtock-rs
. One of the key things for me with all new projects is how hard is it to build and run this thing. I find the current bundle of scripts confusing and non obvious what I should do/run. This PR moves the linker files out of the main directory (so they don't clutter everything up) and then adds a Tock style Makefile which can be used to build the examples for the boards.This PR also removes some unused files to again reduce clutter.
If this is merged the next step is to move the
flash.sh
actions into the Makefile and look at supporting building a single app (instead of all of the examples) and how to handle features.