Open aaaaalbert opened 8 years ago
The simple fix of employing strip() resolves this issue and also issue #8. The same should be done to SeattleTestbed/common/build_component.py when it parses config_build.txt. Did that, tested, works. I guess I can't issue a single pull request to two repositories, so I'll... do it separately.
Ajay (@kellender) reports that editing an init config on a Windows machine breaks the build process. I can reproduce the problem by appending a
\r
(by typing^V^M
) on the end of a line of the init config. This causes the repo on that line to begit-clone
d into a directoryreponame\r
; subsequently, the build script fails as the dirname it uses doesn't match the one we cloned into.The issue is in
initialize.py
, which loops over the files of the init config here, but doesn't care tostrip()
off whitespace (which includes\r
and\n
!) when constructing thegit
command line here.Apart from the obvious fix, we may consider dealing with line endings on the level of local Git configs.
Example
This clones
seattlelib_v2
into../DEPENDENCIES/seattlelib_v2^M
. Then, firing up the build:History side-note
It has been brought to my attention that the fact that different operating systems historically use different character(s) to signal the end of a line of text should not be considered common knowledge.
Of relevance today are two different schools of line endings:
\r\n
(often rendered in descriptive text asCR/LF
, from old line-printer commands "carriage return" and "line feed"; sometimes labelled "DOS line breaks"), whereas\n
.This causes some cross-platform grief for Seattle time and again. See here for a list of open issues/PRs concerning Seattle and CR/LF. For more intricate detail, please refer to Wikipedia.