View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013366 | CMake | CMake | public | 2012-07-01 16:59 | 2012-12-03 07:46 | ||||
Reporter | Josh Faust | ||||||||
Assigned To | Peter Kuemmel | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Microsoft | OS | Windows | OS Version | 7 | ||||
Product Version | CMake 2.8.8 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0013366: Ninja generator on windows does not take everything into account when checking the command line length limit | ||||||||
Description | When generating the ninja build files, on windows cmake will check the command line length and generate a response file if it's too long. It does this by checking the args and the build line passed to the ninja rule. This does not take into account, though, what the ninja rule actually expands to including any variables passed such as link flags, full executable path, etc. CMake sets the command line limit to 8000 characters on windows, though the actual limit is 8192. I'm assuming it's set to 8000 because it's trying to account for the lack of these flags, but this is not always enough. In rare cases the build can still fail with a "The command line is too long." error. In my specific case, these extra flags account for ~500 characters, while cmake only actually checks 0005058:0007700 characters -- and added together they're above the 8192 limit. The quick fix seems to be changing the max command line to be shorter (say, 7000) in cmNinjaNormalTargetGenerator.cxx:483. The real fix would be to retrieve the rule and expand all the variables in the command, which I do not see an easy way of doing after a quick look through the code. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0029870) Peter Kuemmel (developer) 2012-07-01 18:14 |
Yes, I thought 8000 would be enough and other cases are "esoteric", but it seems this was wrong. The variables used by the rule are also written there: build build\bin\kst2d.exe: CXX_EXECUTABLE_LINKER src\kst\CMakeFiles\kst2.dir ... FLAGS = /DWIN32 /D_WINDOWS /W3 ,,, LINK_FLAGS = /STACK:10000000 /machine:X86 ... LINK_LIBRARIES = E:\sandbox\qt\_4.8_zehner\lib\qtmaind.lib ... POST_BUILD = cd . PRE_LINK = cd . TARGET_IMPLIB = src\kst\kst2d.lib TARGET_PDB = build\bin\kst2d.pdb so we could simply consider the length of all the variable assignments. I've pushed a fix to next. |
(0029871) Josh Faust (reporter) 2012-07-02 03:02 |
That's still not quite exact, as there's still the overhead from the rule itself, e.g.: $PRE_LINK && C:\Users\josh\packages\cmake\build\bin\Release\cmake.exe -E vs_link_dll c:\PROGRA~2\MICROS~2.0\VC\bin\link.exe /nologo $in /out:$out /implib:$TARGET_IMPLIB /pdb:$TARGET_PDB /dll /version:0.0 $LINK_FLAGS $LINK_LIBRARIES && $POST_BUILD has about 170 non-variable characters in it. To be safe you may still want to up the 192 character buffer. Your change does fix my use case though, thanks! Not sure what the policy here is, should I close this ticket? Actually, can I even do that? I don't see any way for me to edit the ticket. |
(0029872) Peter Kuemmel (developer) 2012-07-02 04:37 |
OK, also the length of the command line is used. It is still not 100% perfect because you could write rules which use a variable multiple times. But I think such cases then are really "esoteric". I also could only write comments here, I assume the release manager will close it. |
(0029888) Peter Kuemmel (developer) 2012-07-03 05:44 |
On 02.07.2012 17:40, Bill Hoffman wrote: > > Can we just put the link step into the response files? > The code now catches nearly all cases. I don't think it will fail in any real-live usage. |
(0031814) David Cole (manager) 2012-12-03 07:46 |
Closing resolved issues that have not been updated in more than 4 months. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2012-07-01 16:59 | Josh Faust | New Issue | |
2012-07-01 18:14 | Peter Kuemmel | Note Added: 0029870 | |
2012-07-02 03:02 | Josh Faust | Note Added: 0029871 | |
2012-07-02 04:37 | Peter Kuemmel | Note Added: 0029872 | |
2012-07-02 12:54 | Bill Hoffman | Assigned To | => Peter Kuemmel |
2012-07-02 12:54 | Bill Hoffman | Status | new => assigned |
2012-07-03 05:44 | Peter Kuemmel | Note Added: 0029888 | |
2012-07-03 05:44 | Peter Kuemmel | Status | assigned => resolved |
2012-07-03 05:44 | Peter Kuemmel | Resolution | open => fixed |
2012-12-03 07:46 | David Cole | Note Added: 0031814 | |
2012-12-03 07:46 | David Cole | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |