cmake: Extracted Zephyr module processing into python script #14667

tejlmand · 2019-03-19T10:01:49Z

This commit move the functionality of extracting zephyr modules into
generated CMake and Kconfig include files from CMake into python.

This allows other tools, especially CI to re-use the zephyr module
functionality.

zephyrbot · 2019-03-19T10:08:09Z

All checks are passing now.

Review history of this comment for details about previous failed status.
Note that some checks might have not completed yet.

carlescufi

I am uneasy about this. While parsing the modules with Python seems like a good idea, I am not sure about generating CMake files from Python. This is a bit extreme, isn't it? Wouldn't it be better to print a list of paths to CMakeLists.txt from zephyr_modules.py and then have CMake parse that output and call add_subdirectory() on each?

carlescufi · 2019-03-19T10:17:14Z

scripts/zephyr_module.py

+        with open(module_yml, 'r') as f:
+            meta = yaml.safe_load(f.read())
+
+        schema = yaml.safe_load(METADATA_SCHEMA)


You might need a Loader= param to avoid warnings with newer versions of PyYaml: zephyrproject-rtos/ci-tools@a529866

Thanks, will add.

Took a look at: zephyrproject-rtos/ci-tools@a529866
That code uses yaml.load and not yaml.safe_load as this code.

So that is not an issue here (as well as safe_load doesn't support the Loader argument)

It also feels a bit strange to parse this schema for each module, since it isn't changing. It could either be a global variable or passed as an argument instead to avoid that.

@mbolivar fixed

codecov-io · 2019-03-19T10:37:00Z

Codecov Report

Merging #14667 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #14667   +/-   ##
=======================================
  Coverage   52.92%   52.92%           
=======================================
  Files         309      309           
  Lines       45268    45268           
  Branches    10451    10451           
=======================================
  Hits        23956    23956           
  Misses      16544    16544           
  Partials     4768     4768

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5049694...56a77f8. Read the comment docs.

tejlmand · 2019-03-19T11:34:03Z

Thanks for the comments.
Let me give the reasoning for this.

I am uneasy about this. While parsing the modules with Python seems like a good idea, I am not sure about generating CMake files from Python. This is a bit extreme, isn't it?

It was done this way, as to have same principle used for both Kconfig and CMake.
That is, generating a file that can be included by the corresponding tool.

Secondly, as commented by @SebastianBoe output from scripts should ideally go through a file, and thus, instead of generating text file with a list of folders to include, which then must be parsed by CMake, then I decided to generate the CMake file directly.
See #13067 (comment)

Third, if we in future needs to create additional type of files that can be included, e.g. DTS, then that can be supported with --dts-out.

The --cmake-out can be omitted by CI, and just use --kconfig-out, which means CI doesn't need to generate the CMake files for Kconfig verification.

Wouldn't it be better to print a list of paths to CMakeLists.txt from zephyr_modules.py and then have CMake parse that output and call add_subdirectory() on each?

as mentioned, printing directly from scripts is discouraged, so would need to go through a file anyway.

SebastianBoe · 2019-03-19T11:38:32Z

as mentioned, printing directly from scripts is discouraged, so would need to go through a file anyway.

You don't have to print from a script to do this. You can have the python script write a file that is easily parse-able by CMake, e.g csv, or lines of set(FOO bar).

Generally, it is ok to generate data, but not code. There is a fine line between them, but e.g. add_subdirectory looks like code to me.

tejlmand · 2019-03-19T11:54:12Z

as mentioned, printing directly from scripts is discouraged, so would need to go through a file anyway.

You don't have to print from a script to do this. You can have the python script write a file that is easily parse-able by CMake, e.g csv, or lines of set(FOO bar).

Yes, that's exactly what i'm stating.
The printing was suggested by @carlescufi:

Wouldn't it be better to print a list

And to that I replied a file should be generated from the Python script in any case, just as you also state.

Generally, it is ok to generate data, but not code. There is a fine line between them, but e.g. add_subdirectory looks like code to me.

As does the Kconfig generated file:
osource "<path>/Kconfig"

I think the add_subdirectory() and osource are similar in nature.
But if it preferred that the CMake output generates a plain file and Kconfig output generates code with osource statements, then I can change.

Remember, the python script is now generic, so that it can be used outside CMake, e.g. for CI.

SebastianBoe · 2019-03-19T11:58:04Z

As does the Kconfig generated file:
osource "<path>/Kconfig"

Yeah, but that's unavoidable AFAICT. But for CMake, we are able to avoid more code generation than in the current proposal AFAICT.

SebastianBoe · 2019-03-19T11:58:37Z

But if it preferred that the CMake output generates a plain file and Kconfig output generates code with osource statements, then I can change.

Yes, this is preferable.

carlescufi · 2019-03-19T12:01:38Z

I see that @SebastianBoe aligns with my suggestion. As he mentions, for Kconfig its unavoidable because we are not invoking the python script from Kconfig. But for CMake it's a completely different story since we are actively calling it from the CMake code.

tejlmand · 2019-03-19T15:30:36Z

But if it preferred that the CMake output generates a plain file and Kconfig output generates code with osource statements, then I can change.

Yes, this is preferable.

I see that @SebastianBoe aligns with my suggestion. As he mentions, for Kconfig its unavoidable because we are not invoking the python script from Kconfig. But for CMake it's a completely different story since we are actively calling it from the CMake code.

Fixed.
Thanks for the feedback.

SebastianBoe · 2019-03-19T15:51:53Z

scripts/zephyr_module.py

+        if section is not None:
+            cmake_path = section.get('cmake', cmake_path)
+            kconfig_file = section.get('kconfig', kconfig_file)
+


we should assert when the yaml file is pointing to a non-existent file.

I think you're referring to using try statements to open the file, and doing something like calling sys.exit or printing to stderr in the exception handler, right? Not an actual assert statement.

@SebastianBoe yep, see your point, although I agree with @mbolivar you don't want assert, but instead raise an exception in order to abort with error.

Usually I like stack traces, but I see this would be a user-input error through misconfigured .yml, so this should be a message through stderr and an exit code as @mbolivar says.

Internal system error -> stack trace.
User-input error -> error message.

SebastianBoe · 2019-03-19T15:55:34Z

scripts/zephyr_module.py

+                        help='List of extra modules to parse')
+    args = parser.parse_args()
+
+    if args.kconfig_out is not None:


Just

if args.kconfig_out:

is best-practice.

I agree that if foo and if not bar for the current set of arguments is more readable. But this is not a universal best practice.

If there were any arguments with type=int then you would need to explicitly check for None if you want to test "argument not provided", to avoid issues when the value is given, just zero:

#!/usr/bin/env python3 import argparse parser = argparse.ArgumentParser() parser.add_argument('--foo', type=int) args = parser.parse_args() if args.foo: print('foo!') else: print('no foo :(')

E.g.:

$ ./foo.py no foo :( $ ./foo.py --foo 1 foo! $ ./foo.py --foo 0 no foo :(

I don't think that is best practice, also PEP8 states:
https://www.python.org/dev/peps/pep-0008/#id51

Comparisons to singletons like None should always be done with is or is not, never the equality operators.

Also, beware of writing if x when you really mean if x is not None

And here, I do indeed mean is not None

And here, I do indeed mean is not None.

But we want to express "x is not None and x != empty_string", which we will get with "if x", but we don't get with a None comparison.

Allowing x == empty_string will cause weird issues further down the line AFAICT.

@mbolivar : I agree, we wouldn't want to use "if x" for the int type.

@SebastianBoe you're right, haven't consider that a user could write --cmake-out= without providing a filename in which case the value would indeed be an empty string.

So that is fixed now.

SebastianBoe · 2019-03-19T15:59:53Z

scripts/zephyr_module.py

+        type: str
+'''
+
+AUTO_GENERATED_HEADER = '# NOTE: THIS FILE IS AUTOGENERATED - DO NOT EDIT\n\n'


Can we drop this?

Then we can drop the regex:

https://github.com/zephyrproject-rtos/zephyr/pull/14667/files#diff-af3b638bc2a3e6c650974192a53c7291R581

Users really should know that they can't modify any files in the build directory ...

Fine with me, but it was originally introduced due to this comment: #13067 (comment)

the filename should reflect that, e.g. modules.generated.kconfig

Add a header of "# NOTE: THIS IS AUTOGENERATED BY " to this file.

I disagree with that comment.

Most files in the build directory are generated (as opposed to copied from source, which is rarely done in CMake-based build systems). And most files do not have the word generated in the filename or in the header.

But I can understand having the disclaimer in generated C code for users with editors that don't make it obvious that they have opened a file in the build directory.

I disagree with that comment.

Personally this is not important to me, and per default I would not have put it in first place.
I was just referring to why it was there.

So it's removed again.

SebastianBoe · 2019-03-19T16:01:46Z

scripts/zephyr_module.py

+def generate_file_header(includefile):
+    path = os.path.dirname(includefile)
+    if path != '' and not os.path.exists(path):
+        os.makedirs(path)


This can be dropped, the user should be able to make the directory of the path he inputs.

Well, the user in this case is CMake, and at this point in time, then the folder ${PROJECT_BINARY_DIR} doesn't exist.
The reason this worked in CMake was because file(write <path>/filename) will automatically create <path>, if it doesn't exists.

${PROJECT_BINARY_DIR} is used because that variable is already exported to Kconfig

CMake should create the directory then.

Folder creation moved to CMake.

SebastianBoe · 2019-03-19T16:02:30Z

scripts/zephyr_module.py

+    path = os.path.dirname(includefile)
+    if path != '' and not os.path.exists(path):
+        os.makedirs(path)
+    if includefile is not None:


This if-statement is always true so it can be dropped.

yep. has become obsolete when I refactored code.
Thanks for spotting.

SebastianBoe · 2019-03-19T16:03:24Z

scripts/zephyr_module.py

+    if path != '' and not os.path.exists(path):
+        os.makedirs(path)
+    if includefile is not None:
+        with open(includefile, 'w+') as f:


the '+' can be dropped.

agree.
Fixed

SebastianBoe · 2019-03-19T16:05:06Z

scripts/zephyr_module.py

+        os.makedirs(path)
+    if includefile is not None:
+        with open(includefile, 'w+') as f:
+            f.write(AUTO_GENERATED_HEADER)


Assuming you agree about https://github.com/zephyrproject-rtos/zephyr/pull/14667/files#r266966468 we can just 'pass' here to create the file.

That would be a bit weird. If the entire point of this function is to generate the header, and that is not needed, we could just delete the function and move the with statement to a place in the file where the contents are available or generated.

yeah. as I wrote #14667 (comment)
it seems people have different opinions about headers.

Personally I agree with @SebastianBoe that when files are in build folder, they should be assumed to be generated.
But if people wants a header, that also fine with me.

Purpose of code is correctly to generate the header (and folder if missing)

as it seems we agree to not have the header in files then that code is now removed.

mbolivar

Just some comments about style since I guess this won't be merged for v1.14 and we are thus in no hurry and can discuss what's Pythonic or not at our leisure ;).

mbolivar · 2019-03-19T17:41:02Z

scripts/zephyr_module.py

+    Process a list of projects and create Kconfig / CMake include files for \
+    projects which are also a Zephyr module''')
+
+    parser.add_argument('--kconfig-out', required=False,


False is the default for required when the argument is optional, so you could just drop those kwargs entirely, here and below.

true, and completely agree.
This was simply reuse of the old code from yaml_to_cmake.py, where the output arg was required=True
Should have deleted instead of changing to False

mbolivar · 2019-03-19T17:45:25Z

scripts/zephyr_module.py

+                        help='List of extra modules to parse')
+    args = parser.parse_args()
+
+    if args.kconfig_out is not None:


I agree that if foo and if not bar for the current set of arguments is more readable. But this is not a universal best practice.

If there were any arguments with type=int then you would need to explicitly check for None if you want to test "argument not provided", to avoid issues when the value is given, just zero:

#!/usr/bin/env python3 import argparse parser = argparse.ArgumentParser() parser.add_argument('--foo', type=int) args = parser.parse_args() if args.foo: print('foo!') else: print('no foo :(')

E.g.:

$ ./foo.py no foo :( $ ./foo.py --foo 1 foo! $ ./foo.py --foo 0 no foo :(

mbolivar · 2019-03-19T17:49:40Z

scripts/zephyr_module.py

+        os.makedirs(path)
+    if includefile is not None:
+        with open(includefile, 'w+') as f:
+            f.write(AUTO_GENERATED_HEADER)


That would be a bit weird. If the entire point of this function is to generate the header, and that is not needed, we could just delete the function and move the with statement to a place in the file where the contents are available or generated.

mbolivar · 2019-03-19T17:53:01Z

scripts/zephyr_module.py

+
+def main():
+    parser = argparse.ArgumentParser(description='''
+    Process a list of projects and create Kconfig / CMake include files for \


Why is a backslash being used in a triple quoted string, where it is not necessary? Are you sure it's needed?

no it's not needed.
Wonder how it got in there in the first place.

mbolivar · 2019-03-19T17:54:10Z

scripts/zephyr_module.py

+            meta = yaml.safe_load(f.read())
+
+        schema = yaml.safe_load(METADATA_SCHEMA)
+        pykwalify.core.Core(source_data=meta, schema_data=schema).validate()


Probably worth putting this in a try statement and aborting with a clean error if it fails, instead of just printing a stack trace

guess moving code around catches you attention ;)

now catching a printing more informative message to user.

mbolivar · 2019-03-19T17:55:43Z

scripts/zephyr_module.py

+        val_str = '{}:{}\n'.format(os.path.basename(module), cmake_path_abs)
+
+        with open(cmake_out, 'a') as f:
+            f.write(val_str)


It seems a bit strange to do it this way. Why not just assume cmake_out is a file-like argument if it is not None, and open it up once for appending in the loop that calls this function?

Then this could just be:

if os.path.isfile(cmake_file_abs) and cmake_out is not None: print('{}:{}'.format(os.path.basename(module), cmake_path_abs), file=cmake_out)

It should be a bit faster as well, since the program won't be opening and closing the file every time a line is added.

If it's important that it's just a \n and not a CRLF on Windows, then using end='\n' in the call to print would make sure of that.

yep, good point.
Guess it's just a personal preference for the

with open(<file>) as f: f.write(<something>)

As you avoid the close, as well as the try-catch for the IO handling.
Although, I do agree, that only opening the file once for writing is a small optimization.

mbolivar · 2019-03-19T18:09:24Z

scripts/zephyr_module.py

+    if os.path.isfile(kconfig_file_abs) and kconfig_out is not None:
+        val_str = 'osource "{}"\n\n'.format(kconfig_file_abs)
+
+        with open(kconfig_out, 'a') as f:


Same comment for the way cmake_out is handled, above, applies here.

mbolivar · 2019-03-19T18:11:59Z

scripts/zephyr_module.py

+        with open(module_yml, 'r') as f:
+            meta = yaml.safe_load(f.read())
+
+        schema = yaml.safe_load(METADATA_SCHEMA)


It also feels a bit strange to parse this schema for each module, since it isn't changing. It could either be a global variable or passed as an argument instead to avoid that.

mbolivar · 2019-03-19T18:14:07Z

scripts/zephyr_module.py

+        if section is not None:
+            cmake_path = section.get('cmake', cmake_path)
+            kconfig_file = section.get('kconfig', kconfig_file)
+


I think you're referring to using try statements to open the file, and doing something like calling sys.exit or printing to stderr in the exception handler, right? Not an actual assert statement.

tejlmand · 2019-03-20T11:25:08Z

@mbolivar @SebastianBoe all comments addressed

Also removed the section from arguments to be internal knowledge, as that is where it correctly belongs.
The section was leftover from the original yaml_to_cmake.py script

tejlmand · 2019-03-20T11:25:51Z

Thanks for the review

tejlmand · 2019-03-22T07:47:23Z

@carlescufi @SebastianBoe @mbolivar Can you recheck, everything should be fixed :)

carlescufi · 2019-03-28T16:53:45Z

@nashif @mbolivar @tejlmand pushed a couple of commits to fix #14989

carlescufi · 2019-03-29T10:08:43Z

@mbolivar @nashif @tejlmand this is ready to be merged

Revert on next upmerge, once zephyrproject-rtos/zephyr#14667 is merged. This is required because CMAKE_CURRENT_BINARY_DIR is the same as CMAKE_BINARY_DIR upstream, but not in NCS. Signed-off-by: Carles Cufi <[email protected]>

carlescufi · 2019-03-29T13:38:45Z

@tejlmand @nashif after this is merged, we should remove the equivalent python code in ci-tools/scripts/check_compliance.py and use this zephyr_module.py script instead.

Fixes: zephyrproject-rtos#14513 This commit move the functionality of extracting zephyr modules into generated CMake and Kconfig include files from CMake into python. This allows other tools, especially CI to re-use the zephyr module functionality. Signed-off-by: Torsten Rasmussen <[email protected]>

In order to parse all the Kconfig files that make up the whole Kconfig tree we need to process the modules, since this can optionally provide Kconfig files. In order to do so, include the modules CMake file so that they are listed and a Kconfig.modules is generated. Signed-off-by: Carles Cufi <[email protected]>

When generating the Kconfig reference documentation, enable the warnings for undefined Kconfig options in order to make sure all references are met. Signed-off-by: Carles Cufi <[email protected]>

marc-hb · 2019-03-30T06:01:12Z

Looks like this broke "hello_world" (and everything else) when not using west. I'm aware not using west is "living in the past", however I didn't really expect this at this time between -rc3 and -rc4. A meaningful error message mentioning (the lack of) west would also be nicer than a cryptic kconfig stack trace. Has the documentation been updated to clarify that west is now mandatory?

Just some comments about style since I guess this won't be merged for v1.14 and we are thus in no hurry

Famous last words :-)

Kconfig.modules used to be an empty file when no modules. PR zephyrproject-rtos#14667 / commit bd7569f "cmake: Extracted Zephyr module processing into python script" unintentionally changed that to no Kconfig.modules file at all when no west and no modules. kconfig.py doesn't like that and crashes. Restore the empty file. Signed-off-by: Marc Herbert <[email protected]>

ioannisg · 2019-03-30T23:47:41Z

@carlescufi @tejlmand @nashif
Merging this PR has broken my Windows10 build setup:
Here's some log info, when running cmake -GNinja -DBOARD=nrf52840_pca10056 ..:


-- The C compiler identification is GNU 7.3.1
-- The CXX compiler identification is GNU 7.3.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/gccarmemb/bin/arm-none-eabi-gcc.exe
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
Including module: tinycbor:C
CMake Warning at ../../../../CMakeLists.txt:1464 (message):


        ------------------------------------------------------------
        --- WARNING:  __ASSERT() statements are globally ENABLED ---
        --- The kernel will run more slowly and use more memory  ---
        ------------------------------------------------------------


-- Configuring done
CMake Error: Cannot open file for write: C:/Users/iogl/Documents/nordic/workspace/zephyr/zephyr/tests/kernel/mem_protect/userspace/build_nrf52840_pca10056_2/tinycbor:C/cmake_install.cmake.tmp
CMake Error: : System Error: Invalid argument

Looks like we are trying to include module tinycbor:C

I am no expert on this, but reverting these commits seem to solve the problem.

aescolar · 2019-03-31T08:58:56Z

@ioannisg : Does #15042 fix it for you? Could you or @marc-hb file a bug for this regression?

carlescufi · 2019-03-31T18:26:53Z

This is very strange. A module named "tinycbor:C" is being found by west. Can you please run the following west list --format={posixpath}?

Kconfig.modules used to be an empty file when no modules. PR #14667 / commit bd7569f "cmake: Extracted Zephyr module processing into python script" unintentionally changed that to no Kconfig.modules file at all when no west and no modules. kconfig.py doesn't like that and crashes. Restore the empty file. Signed-off-by: Marc Herbert <[email protected]>

tejlmand requested review from mbolivar, nashif, SebastianBoe and carlescufi March 19, 2019 10:01

carlescufi requested changes Mar 19, 2019

View reviewed changes

tejlmand force-pushed the issue_14513_zephyr_modules branch from 0c3e30f to 21a2e64 Compare March 19, 2019 11:45

tejlmand force-pushed the issue_14513_zephyr_modules branch from 21a2e64 to 0e50cb3 Compare March 19, 2019 15:18

SebastianBoe reviewed Mar 19, 2019

View reviewed changes

mbolivar reviewed Mar 19, 2019

View reviewed changes

tejlmand force-pushed the issue_14513_zephyr_modules branch 2 times, most recently from 22ee119 to 0211794 Compare March 20, 2019 11:07

tejlmand force-pushed the issue_14513_zephyr_modules branch from 0211794 to 678d7f4 Compare March 20, 2019 11:27

carlescufi added this to the v1.14.0 milestone Mar 28, 2019

carlescufi added the DNM This PR should not be merged (Do Not Merge) label Mar 28, 2019

carlescufi force-pushed the issue_14513_zephyr_modules branch 2 times, most recently from e58a3bc to 1c3ca94 Compare March 28, 2019 16:53

carlescufi force-pushed the issue_14513_zephyr_modules branch 2 times, most recently from 7989556 to bbe4909 Compare March 29, 2019 10:07

carlescufi removed the DNM This PR should not be merged (Do Not Merge) label Mar 29, 2019

nashif approved these changes Mar 29, 2019

View reviewed changes

tejlmand and others added 3 commits March 29, 2019 15:19

doc: Enable undef warnings in Kconfig

56a77f8

When generating the Kconfig reference documentation, enable the warnings for undefined Kconfig options in order to make sure all references are met. Signed-off-by: Carles Cufi <[email protected]>

carlescufi force-pushed the issue_14513_zephyr_modules branch from bbe4909 to 56a77f8 Compare March 29, 2019 14:20

nashif merged commit c6249ac into zephyrproject-rtos:master Mar 30, 2019

marc-hb requested review from andrewboie and dbkinder March 30, 2019 05:55

marc-hb mentioned this pull request Mar 30, 2019

zephyr_module.cmake: restore ability to build without modules #15042

Merged

tejlmand deleted the issue_14513_zephyr_modules branch December 9, 2020 09:12

tejlmand mentioned this pull request Aug 12, 2021

cmake: add a comment header to zephyr_settings.txt #37554

Merged

marc-hb mentioned this pull request Aug 19, 2022

west build doesn't process select in Kconfig for module correctly zephyrproject-rtos/west#595

Closed

cmake: Extracted Zephyr module processing into python script #14667

cmake: Extracted Zephyr module processing into python script #14667

Conversation

tejlmand commented Mar 19, 2019 • edited by carlescufi Loading

zephyrbot commented Mar 19, 2019 • edited Loading

carlescufi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Mar 19, 2019 • edited Loading

Codecov Report

tejlmand commented Mar 19, 2019

SebastianBoe commented Mar 19, 2019

tejlmand commented Mar 19, 2019

SebastianBoe commented Mar 19, 2019

SebastianBoe commented Mar 19, 2019

carlescufi commented Mar 19, 2019

tejlmand commented Mar 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SebastianBoe Mar 20, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mbolivar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tejlmand commented Mar 20, 2019

tejlmand commented Mar 20, 2019

tejlmand commented Mar 22, 2019

carlescufi commented Mar 28, 2019

carlescufi commented Mar 29, 2019

carlescufi commented Mar 29, 2019

marc-hb commented Mar 30, 2019

ioannisg commented Mar 30, 2019

aescolar commented Mar 31, 2019

carlescufi commented Mar 31, 2019 • edited Loading

tejlmand commented Mar 19, 2019 •

edited by carlescufi

Loading

zephyrbot commented Mar 19, 2019 •

edited

Loading

codecov-io commented Mar 19, 2019 •

edited

Loading

SebastianBoe Mar 20, 2019 •

edited

Loading

carlescufi commented Mar 31, 2019 •

edited

Loading