Parse spaces in -l/-L/I args correctly, default to no absolute path warnings

[pimlu]

Fixes #3777 and #2713. This includes changes to the documentation (and a rebuild of the docs) to reflect #2713. Let me know if anything is out of place – it may be easier to read the first four commits without the clutter aa3c1b7 throws in in the PR diff.

This fails two tests in other; however, these both fail on incoming and master for me as well, so I believe something is wrong with my development environment rather than the PR. Do you recognize these errors? I'm running relatively fresh Linux Mint 17.2 with the latest packages.

======================================================================
ERROR: test_crunch (test_other.other)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pimlu/Documents/emscripten/tests/test_other.py", line 2131, in test_crunch
    assert os.stat('test.data').st_size < 0.25*os.stat('ship.dds').st_size, 'Compressed should be much smaller than dds'
OSError: [Errno 2] No such file or directory: 'test.data'

======================================================================
FAIL: test_llvm_lit (test_other.other)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pimlu/Documents/emscripten/tests/test_other.py", line 2764, in test_llvm_lit
    assert p.returncode == 0, 'LLVM tests must pass with exit code 0'
AssertionError: LLVM tests must pass with exit code 0

----------------------------------------------------------------------
Ran 172 tests in 1910.554s

FAILED (failures=1, errors=1)

[kripken]

Looks very good, thanks!

I have 2 notes:

• Let's add a test that checks that -l x works, and not just that it doesn't cause a build error. Can add just a few lines to the end of other.test_l_link (might also want to refactor the test a little, perhaps).
• I am generally worried about Default to not warn about absolute include paths. #2713. I understand the motivation for it, but this is a common pitfall, and no-one will see weird build errors and think to turn on that flag, since they never heard of it. Perhaps we should turn it on when -Wall is on, or when ASSERTIONS is on, or when ASSERTIONS is 2, or something like that? Or do we feel that if we document this well enough in the FAQ that that would be enough?

[pimlu]

Alright,

• For number 1, this line should test if -l c builds for us (I assume -l x was a typo), though it might be better to place that particular functionality in other.test_l_link, since the focus of other.test_lib_include_flags is CLI parsing. Should this be moved? (Also, is it preferred to put source files in tests rather than write them out from inside the test method? That might be a part of a test_l_link refactor)
• Regarding the second, I don't know for sure what the best route is, but for one thing, are there common use cases where most of the pitfalls are caught at? Like, if we turned on this warning by default when someone used emmake, for example? If we do make -Wall enable absolute path warnings, it might be advisable to reintroduce -Wno-warn-absolute-paths, so you can get every warning besides absolute paths.

[kripken]

1. The problem is that the command on that line will work even without -l c, since we link in libc automatically anyhow. test_l_link on the other hand creates a library and uses it via -l, so it actually tests that a library is linked in. (In general, for small test files I don't mind them in the .py, but I agree it is nicer when they are outside.)
2. I'm not sure, but I think a common pitfall is someone runs configure without emconfigure, and ends up with a bunch of -I/usr/include directories to local system libs. But, this might just be me worrying too much :) If you and @juj both think this is a better default, I'm probably ok with that. But another thought came to me meanwhile: with -v, all include paths are printed out, so perhaps we could add warnings there?

[juj]

I think it's a worthwhile note that -I/usr/include paths and similar are bad. However I think caring about those occurs mostly in the inception of porting a new project, which is relatively small surface area, compared to the number of people who have to add the -Wno-warn-absolute-paths to their build systems. I don't think there's much danger of silently hiding bugs by accidentally including -I/usr/include or similar, because most of the time, that causes builds to catastrophically fail anyways?

[kripken]

Fair enough, agreed.

[pimlu]

How does this look?

[kripken]

Very good! Just one last comment there, and please squash commits that it makes sense to squash.

[pimlu]

Alright, I think it's ready to go.

[kripken]

Thanks!

[mlogan]

FWIW, It would have been nice if emcc had continued to consume -Wno-warn-absolute-paths, as this change breaks our build upon upgrading emscripten. The option is now passed on to clang, which of course has never heard of it. Not the end of the world, of course.

[kripken]

Yeah, good point. Sorry about that. Fixed on incoming.