View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014795CMakeModulespublic2014-03-07 06:152014-10-06 10:32
Reportertrsystran 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSUbuntuOS Version
Product VersionCMake 2.8.12.2 
Target VersionFixed in Version 
Summary0014795: flex_target: some errors silently ignored
DescriptionCurrent flex version (v2.5.37) sometimes generates an empty output file in case of error.
(at least when m4 program is missing: "flex: fatal internal error, exec of /usr/bin/m4 failed")

In such case flex returns a non zero return code, and cmake correctly reports a target build failure, however flex did generate the output file: an empty file.

This is an issue: if we do two "make" in a row the first one will correctly fail, but the second one will think the target is generated (since the file exists) and proceed without error. It will maybe fail later when symbols are missing (or not if we only build dynamic libraries).
Steps To Reproduce* install flex
* remove m4
* use flex_target
find_package(FLEX "2.5.37" QUIET REQUIRED)
flex_target(Test test.l ${CMAKE_CURRENT_BINARY_DIR}/test.c)
create_library(test SHARED ${FLEX_test_OUTPUTS})
* run cmake
* run "make; make"
* result: the library "test" is build without error on the second make; it shouldn't.
Additional InformationMaybe we should report this to flex, but in any case in order to support older versions we should still have a workaround in FindFLEX.cmake: delete the output in case of flex error.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0035357)
Brad King (manager)
2014-03-10 10:50

 This should be fixed by flex upstream.
(0035360)
Brad King (manager)
2014-03-10 11:00

 According to local testing flex does delete the output file on normal errors like bad input. It is only an internal error produced by cases like missing m4 that cause this behavior. Still, it is an upstream issue.

Working around this issue in FindFLEX.cmake would require wrapping the flex invocation in a script that checks the return code and removes the output.
(0035369)
trsystran (reporter)
2014-03-10 11:35

 Bug opened upstream:
https://sourceforge.net/p/flex/bugs/164/ [^]

The script workaround could be a cmake script, couldn't it? It would still be useful for older flex releases I think.
(0035370)
Brad King (manager)
2014-03-10 11:48

 Re 0014795:0035369: Yes, but it could also be a local flex.sh that is set as FLEX_EXECUTABLE instead.

IMO it is not worth the extra indirection at runtime and extra infrastructure/maintenance within CMake just to work around installations of flex that are missing their dependencies.
(0035371)
trsystran (reporter)
2014-03-10 11:50

 OK, let's close this issue then.
(0035372)
Brad King (manager)
2014-03-10 11:52

 Re 0014795:0035371: Okay, thanks.
(0036938)
Robert Maynard (manager)
2014-10-06 10:32

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2014-03-07 06:15 trsystran New Issue
2014-03-10 10:50 Brad King Note Added: 0035357
2014-03-10 10:50 Brad King Severity major => minor
2014-03-10 10:50 Brad King Status new => backlog
2014-03-10 11:00 Brad King Note Added: 0035360
2014-03-10 11:35 trsystran Note Added: 0035369
2014-03-10 11:48 Brad King Note Added: 0035370
2014-03-10 11:50 trsystran Note Added: 0035371
2014-03-10 11:52 Brad King Note Added: 0035372
2014-03-10 11:52 Brad King Status backlog => resolved
2014-03-10 11:52 Brad King Resolution open => no change required
2014-10-06 10:32 Robert Maynard Note Added: 0036938
2014-10-06 10:32 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team