Closed creationix closed 8 years ago
Note that this doesn't seem to be easily reproducible. On a Debian virtual machine, it includes the local deps properly.
./lit make
lit version: 3.3.3
luvi version: v2.7.2
command: make
load config: /home/ryan/.litconfig
compiling filter: /home/ryan/Luvit/luvit/luvit/** excludes by default (first rule is positive)
skipping: bench
skipping: examples
including: init.lua
including: main.lua
including: package.lua
skipping: tests
including dependency: buffer (/home/ryan/Luvit/luvit/luvit/deps/buffer.lua)
including dependency: childprocess (/home/ryan/Luvit/luvit/luvit/deps/childprocess.lua)
including dependency: codec (/home/ryan/Luvit/luvit/luvit/deps/codec.lua)
...
:/
Strikes again https://travis-ci.org/luvit/luvit/jobs/139775128#L365-L385
I wish I could reproduce it more easily.
Ok, found the issue, but not sure how to solve it. Turns out fs_scandir_next
is getting UV_DIRENT_UNKNOWN
as the type for every file on Travis's Linux build container, which then causes Lit to skip retrieving the metadata for all local deps because baseName ends up being nil.
I added a bunch of debug printing to test it. Here's the relevant portions:
On Linux:
checking /home/travis/build/squeek502/luvit/deps
- iterating buffer.lua
- type nil
- name buffer.lua
On OSX:
checking /Users/travis/build/squeek502/luvit/deps
- iterating buffer.lua
- type file
- name buffer.lua
Found a relevant comment in the luv tests:
https://github.com/luvit/luv/blob/master/tests/test-fs.lua#L77-L78
-- ftype is not available in all filesystems; for example it's
-- provided for HFS+ (OSX), NTFS (Windows) but not for ext4 (Linux).
Published as 3.4.2
As discovered in another issue https://github.com/luvit/luvit/pull/892#issuecomment-217502484, lit doesn't include local deps always on certain platforms.