#534 Build setup fails in OWLMaker

[Zio3D]

Hello.

I'm doing a test project on "C ++ Builder 11 Alexandria" with OWLNext version 6.44.17 by including the file "owl\objstrm.h".

The compiler reports an error in the file "include\owl\private\owllink.h" on line 10 where there is #include of file "owl/version.h".

In fact, the "include/owl" folder does not contain the "version.h" file.

Am I doing something wrong or should there actually be a "version.h" file in the "include/owl" folder?

Thank you.

[Vidar Hasfjord]

Hi Zio3D,

See: FAQ | Why is "include/owl/version.h" missing?

[Zio3D]

I had used OWLMaker and didn't realize it had already created the version.h file as well.
Excuse me and thanks for the information

[Vidar Hasfjord]

I am reopening this, because in my testing OWLMaker does not properly generate "owl/version.h" for 6.44, when the Embarcadero Clang toolset is used and the OWLNext root is not a Subversion working copy — even if build setup is requested.

OWLMaker actually calls "update_version_header.bat", but the latter incorrectly reports that the header is up to date:

1> SubWCRev : E155007: 'C:\OWLNext\6.44-download' is not a working copy
1> update_version_header.bat(34): warning: SubWCRev failed. E.g. the OWLNext root is not a Subversion working copy.
1> update_version_header.bat(67): warning: A version header setting the build number to 0 is generated.
1> Version header is up to date.

[Vidar Hasfjord]

After some frustrating debugging I have found the issue: The use of the "Stop build" command in OWLMaker may corrupt the program execution environment, which may affect subsequent builds. We have seen this before in various other ways.

While "update_version_header.bat" is exactly the same in 6.44 and 7.0, it is executed in different contexts. In 6.44, for the Clang toolsets, OWLMaker calls it directly, as part of the generated build commands. In 7.0, it is called as a pre-build action within the project file; OWLMaker only passes "OWLNextSetup=true" to MSBuild to activate it. This difference is apparently significant for triggering the issue.

The particular issue within the script is the evaluation of the "errorlevel" value. After using "Stop build", this value is no longer evaluated correctly.

I will change the ticket status back to "won't fix", but I intend to include some information about "Stop build" issues in OWLMaker and in the wiki, as to make the user aware.

Please test this issue, and let me know if you see different behaviour.

[Vidar Hasfjord]

With further tests I have confirmed that this issue also affects execution of "update_version_header.bat" within "bc.mak" and "vc.mak" — i.e. it is not limited to the Clang-based toolsets. In fact, the only scenario in which this bug does not appear, is when using the Clang-based toolsets with 7.0 or later (which executes "update_version_header.bat" as a pre-build step within the MSBuild project file).

Hence I have updated and broaden the title of this ticket accordingly.

[Vidar Hasfjord]

This issue can perhaps be fixed by resetting ERRORVALUE.

See: https://stackoverflow.com/questions/1113727/what-is-the-easiest-way-to-reset-errorlevel-to-zero

Edit: I tried prepending ver & to the build command and passing it all to cmd /c, but it had no effect on the issue. After aborting a build, the build setup still fails in subsequent builds, with SubWCRev reporting that the version header is up to date, even though it is missing:

1> SubWCRev: 'C:\OWLNext\branch-7.0'
1> Last committed at revision 6239
1> Updated to revision 6243
1> Local modifications found
1> Version header is up to date.
1> 
1> Error: "include/owl/version.h" is missing. 
1> NMAKE : fatal error U1077: 'if' : return code '0x2'
1> Stop.

As an experiment, I tried launching the build command through "conhost.exe" (I have noticed that Visual Studio launches conhost sub-processes), and this actually fixes the issue! However, conhost opens a console window, and the redirected build output that appears in OWLMaker's Build Output window includes some strange control strings. Still, using conhost fixes the issue, so it seems the trick to avoid corrupting the OWLMaker program environment by aborting a build is to launch the build commands through a child process (such as "conhost").

[Vidar Hasfjord]

@jogybl wrote in [discussion:2780d1a0dd]:

Maybe it is worth it to add option to use detached process, even with an understanding that build won't be stoppable. But it is more important for user to be able to build with the old BC compiler than to be able to stop builds.

Since commands run within MSBuild are not affected, a possibly worthwhile solution to this issue, and possibly also to the TLIB failure issue [bugs:#503], is to encapsulate the old make-files within MSBuild projects. Such make-file MSBuild projects can be easily set up in Visual Studio, I would think. Then to allow OWLMaker to drive these new MSBuild solutions, new toolset classes would have to be defined. These should also be pretty simple and similar to the current MSBuild-based toolsets, basically just passing some arguments to the MSBuild command line.

This could allow us to have a more robust build solution in OWLMaker for the old versions of OWLNext, just as for the latest version 8, which has fully migrated to MSBuild now.

Edit: I've now done a simple experiment with adding such a solution to 7.0.12. A makefile project was easy to set up in Visual Studio and easy to drive with OWLMaker, using the existing Visual Studio 2022 (MSBuild) toolset for version 8 with minimal changes. As expected, this solution solves the issue described by this ticket; I can now stop the build, delete "version.h" and a rebuild will replace it (rather than incorrectly report that it is up-to-date). My experiment only added the MSBuild option for "source/owlcore/vc.mak", but it should equally apply to all the extension libraries and the Borland "bc.mak" solutions as well. Although I will not pursue this further, I will assist if there is interest. Patches for my experiment are attached.

[Vidar Hasfjord]

Since the usage of the unreliable CTRL_BREAK_EVENT signal was eliminated in [r6831], this issue is no longer relevant. The new implementation of "Stop build", which just kills the build processes, works near instantly, seemingly without any issues. Hence, I have closed this ticket.

[Zio3D]

Thank you Vidar Hasfjord for the time you dedicate to the OWLNext project.

[Vidar Hasfjord]

@zio3d wrote:

Thank you Vidar Hasfjord for the time you dedicate to the OWLNext project.

Thanks for the positive feedback!