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

Makefile support ARM linux #1

Closed
seanshpark opened this issue Apr 28, 2015 · 9 comments
Closed

Makefile support ARM linux #1

seanshpark opened this issue Apr 28, 2015 · 9 comments
Labels
feature request Requested feature infrastructure Related to GH Actions or the tested targets minor

Comments

@seanshpark
Copy link
Contributor

Hi,
I'm adding this issue as a todo item to support arm-linux and with maybe add other architecture-platform easier. And as there is no issue, I want to start with this not-urgent one.

  • platforms that we can support: linux, nuttx, darwin, ...
  • architectures: armv7, armv6, i686, x86_64, ...
  • type: debug, release, ...
  • mods: cp cp_minimal, mem_stats, ...
  • boards (maybe for embedded): stm32f3, stm32f4, ...
@seanshpark seanshpark added the enhancement An improvement label Apr 28, 2015
@sand1k sand1k added feature request Requested feature minor infrastructure Related to GH Actions or the tested targets and removed enhancement An improvement labels May 13, 2015
@egavrin egavrin added this to the Core ECMA features milestone Jun 5, 2015
@egavrin
Copy link
Contributor

egavrin commented Jun 5, 2015

//Note to self: We need to provide a simple way of adding new toolchain configurations

@egavrin
Copy link
Contributor

egavrin commented Jun 30, 2015

Cross compilation support added 444bd32

@seanshpark
Copy link
Contributor Author

Thank you!
I've checked with arm-linux-eabi-gcc version 4.7 build with

make debug.linux TOOLCHAIN=./build/configs/toolchain_linux_armv7l-el.cmake

with 71bac03 (as of 1 July) and got this problem;

jerry-core/lit/lit-strings.cpp:378:81: error: conversion to ‘lit_utf8_byte_t {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion]

@egavrin
Copy link
Contributor

egavrin commented Jul 1, 2015

@seanshpark I'll check. Thank you!

egavrin added a commit that referenced this issue Jul 1, 2015
Related issue: #1

JerryScript-DCO-1.0-Signed-off-by: Evgeny Gavrin [email protected]
@egavrin
Copy link
Contributor

egavrin commented Jul 1, 2015

@seanshpark please check #291

@seanshpark
Copy link
Contributor Author

@egavrin thank you, I'll wait #291 to land.

@egavrin
Copy link
Contributor

egavrin commented Jul 2, 2015

@seanshpark pushed as 56e7ead

@seanshpark
Copy link
Contributor Author

Just for information, I'm on jerryscript-project/iotjs#117

@seanshpark
Copy link
Contributor Author

Thank you!

ktorpi added a commit to ktorpi/jerryscript that referenced this issue May 25, 2016
JerryScript-DCO-1.0-Signed-off-by: István Kádár [email protected]
ktorpi added a commit to ktorpi/jerryscript that referenced this issue May 31, 2016
JerryScript-DCO-1.0-Signed-off-by: István Kádár [email protected]
bzsolt pushed a commit that referenced this issue Jun 8, 2016
This patch contains a project in which you can run
a small js test inside the Arduino101.

Follows the Nuttx implementation to replicate a command
line in the Quark SE Lakemont architecture.

Everything is self contained in the targets/arduino_101 folder.
It has only been tested with the arduino 101 at the moment.

Check the README.md for a more detailed explanation of
how to compile and run it.

- Command line javascript run test.

Use test to get a default test.

Write any valid javascript in the shell and get it resolved and executed

- Support for qemu
- Added extra verbose mode on the demo function
- Support to build factory images that can be flashed with dfu-util
- Added a few extra examples on the README about commands that work.

Small fixes to readme and libc_support.c (#1)

- Added a few more instructions to the README.md for arduino_101
- Added the stdint.h include in libc_support.c
- Added parameter to check-vera.sh to check a specific folder
- Cleared the libc function duplication

JerryScript-DCO-1.0-Signed-off-by: Sergio Martinez [email protected]
galpeter added a commit to galpeter/jerryscript that referenced this issue Jun 8, 2018
The license checker previously assumed that the
lines of the license will always end with \n
characters. However when checking a file
with \r\n line endings (should only happen for test files)
the checker can incorrectly report invalid license
as the line endings are incorrect.

Additional note jerryscript-project#1: in Python when reading a file
in text mode it can happen that the line endings are
converted to the host system's line ending.
That is the `\r\n` will be converted to `\n` on Linux.
To resolve this problem the io module to disable
the line ending conversion.

Additional note jerryscript-project#2: it is possible that there
are input test files which are not utf-8 conformant
(eg.: to test the parser). These files can't be read
as utf-8 strings and an exception would occur.
By ignoring these errors the tool can check
the file's license. In the license text there is no
invalid utf-8 character so the check will work
correctly.

JerryScript-DCO-1.0-Signed-off-by: Peter Gal [email protected]
galpeter added a commit to galpeter/jerryscript that referenced this issue Jun 11, 2018
The license checker previously assumed that the
lines of the license will always end with \n
characters. However when checking a file
it could happen that other line endings are
returned (should only happen for test files) thus
the checker can incorrectly report invalid license
as the line endings are incorrect.

Additional note jerryscript-project#1: in Python when reading a file
in text mode it can happen that the line endings are
converted to the host system's line ending.
However on Travis the conversion did not happen when
using the open built-in method. By switching to the
io.open call the conversion is enforced and
all line endings are converted to '\n' regardless of
the host system's line ending.

Additional note jerryscript-project#2: it is possible that there
are input test files which are not utf-8 conformant
(eg.: to test the parser). These files can't be read
as utf-8 strings and an exception would occur.
By ignoring these errors the tool can check
the file's license. In the license text there is no
invalid utf-8 character so the check will work
correctly.

JerryScript-DCO-1.0-Signed-off-by: Peter Gal [email protected]
yichoi pushed a commit that referenced this issue Jun 11, 2018
The license checker previously assumed that the
lines of the license will always end with \n
characters. However when checking a file
it could happen that other line endings are
returned (should only happen for test files) thus
the checker can incorrectly report invalid license
as the line endings are incorrect.

Additional note #1: in Python when reading a file
in text mode it can happen that the line endings are
converted to the host system's line ending.
However on Travis the conversion did not happen when
using the open built-in method. By switching to the
io.open call the conversion is enforced and
all line endings are converted to '\n' regardless of
the host system's line ending.

Additional note #2: it is possible that there
are input test files which are not utf-8 conformant
(eg.: to test the parser). These files can't be read
as utf-8 strings and an exception would occur.
By ignoring these errors the tool can check
the file's license. In the license text there is no
invalid utf-8 character so the check will work
correctly.

JerryScript-DCO-1.0-Signed-off-by: Peter Gal [email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requested feature infrastructure Related to GH Actions or the tested targets minor
Projects
None yet
Development

No branches or pull requests

4 participants