Rewrite the Readme!#20
Conversation
|
@slipher I would like to know the current status of this sentence:
|
illwieckz
force-pushed
the
illwieckz/readme
branch
from
e9c7c22 to
2c986ac
Compare
| - `src/trusted/`: Source code that's used only by trusted code | ||
| - `src/untrusted/`: Source code that's used only by untrusted code | ||
| - `tests/common/`: Source code for examples and tests. | ||
| - `../third_party/`: Third-party source code and binaries that aren't part of |
There was a problem hiding this comment.
I guess we can delete this ../third_party mention. The first purpose of the fork was to not require things outside this repository.
illwieckz
force-pushed
the
illwieckz/readme
branch
from
2c986ac to
0ef9a4e
Compare
Oh that's out of date indeed. NaCl targets work great. You can built NaCl targets, including the IRT, and test everything together. That's why I complain that using CMake is a regression, since it can't handle the multiple toolchains working in concert. I have verified that Linux stuff generally works and tests pass on the |
|
I haven't tested Windows or Mac yet. But I know that |
|
|
||
| ## Dependencies | ||
|
|
||
| - LLVM (must be installed in `/usr/bin`) |
There was a problem hiding this comment.
@slipher do we still need LLVM be in /usr/bin/?
There was a problem hiding this comment.
I suggest to rewrite this line as GCC or Clang.
There was a problem hiding this comment.
Yes the LLVM location is still hard-coded. GCC just needs to be in the PATH. And with the other PR LLVM is now optional.
Great.
CMake can totally use a different toolchain per The reason why my CMake implementation doesn't care about IRT right now is that the first goal is to give the ability to build native trusted binaries from Dæmon's IRT can be downloaded for now, built with SCons in advance. I'm not excluding the opportunity to build the IRT too, but this is not needed to reach the minimal valuable product which is to make the native loader binary buildable with CMake with the exact same ease we do with the engine itself. It's totally on purpose that IRT isn't cared about yet, that's a selling point: I don't want the IRT topic to hold back the CMake implementation. The fact the current CMake implementation doesn't build the IRT should not be used against the CMake implementation. It would be holding it back because of the special effort made to not hold it back. I don't mind that tests remain implemented in SCons forever, run by a CI or something. |
2 participants
Google will no longer update it, we fully adopt this!
This is now our Readme!