Awesome: Error generating awesomerc.lua on FreeBSD

Created on 10 Jan 2017  ·  10Comments  ·  Source: awesomeWM/awesome

Output of awesome --version:

Not possible since it's a build issue

How to reproduce the issue:

Try to build 4.0 it on FreeBSD

Actual result:

[  1%] Built target generated_sources
/usr/bin/make -f CMakeFiles/generate_awesomerc.dir/build.make CMakeFiles/generate_awesomerc.dir/depend
cd /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0 && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0 /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0 /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0 /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0 /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0/CMakeFiles/generate_awesomerc.dir/DependInfo.cmake
Scanning dependencies of target generate_awesomerc
/usr/bin/make -f CMakeFiles/generate_awesomerc.dir/build.make CMakeFiles/generate_awesomerc.dir/build
[  2%] Generating awesomerc.lua, docs/05-awesomerc.md
lua52 /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0/docs/05-awesomerc.md.lua /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0/docs/05-awesomerc.md /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0/awesomerc.lua /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0/awesomerc.lua
lua52: ...x11-wm/awesome/work/awesome-4.0/docs/05-awesomerc.md.lua:247: attempt to index local 'rc' (a nil value)
stack traceback:
        ...x11-wm/awesome/work/awesome-4.0/docs/05-awesomerc.md.lua:247: in main chunk
        [C]: in ?
*** Error code 1

Stop.
make[3]: stopped in /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0
*** Error code 1

Stop.
make[2]: stopped in /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0
*** Error code 1

Stop.
make[1]: stopped in /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0
*** Error code 1

Stop.
make: stopped in /usr/home/garga/freebsd/ports/head/x11-wm/awesome

Expected result:

Error happens because rcfile doesn't exist and awesomerc.md.lua, on line 247 tries to open it for reading:

rc = io.fopen(rcfile)

and after that there are no checks to make sure fopen returned desired file descriptor. If I do 'touch /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.0/awesomerc.lua' and run it again it passes this step

Most helpful comment

@psychon Re-assigning myself. I don't much time, but I have a branch with the doc example system rewrite in pure Lua+less processes. It also fix this issue by turning the problem on its head. My patch make LDoc/CMake/TestsExamples create a "dirty" copy of the files and don't touch the original (+ a custom fix for awesomerc.lua). This way the line numbers are never changed. The backtrace will start working again. The downside is that the installed files will have --@DOC____EXAMPLE@ in them. But you can't view images in a text editor, so this is a non-issue.

  • It's much faster than the current CMake based tests/example system
  • It's a "single" process (well, 1 dispatcher/sink and 2 worker threads)
  • It removes some hacks for codecov/coveralls line numbers
  • It run as a compilation unit instead of CMake
  • It create releases with "clean" backtraces instead of the current offset issue
  • It doesn't lose any features compared to the current system

Most of the code is written and it can generate most examples correctly. But it isn't complete yet, but it will get there.

All 10 comments

Looks like it happens because SOURCE_DIR and BUILD_DIR are the same, then original file is deleted at some point

The bad error message should be fixed by https://github.com/awesomeWM/awesome/commit/b4387d387d3badc6ad08a66d5a6675db5e320789.

Looks like it happens because SOURCE_DIR and BUILD_DIR are the same, then original file is deleted at some point

Thanks! The last time I heard this, the reporter had no idea why this occurred. @Elv13 Do you want to take a look at this?

Should we perhaps make one of the Travis builds do such a build to make sure it works in the future?

On FreeBSD I moved awesomerc.lua to awesomerc.lua.in before start buiding and fixed awesomeConfig.lua

@psychon @Elv13 FYI, I'm attempting again to upgrade AwesomeWM on FreeBSD ports collection. this time to version 4.1 and the problem persists. As I mentioned before the root cause is BUILD_DIR and SOURCE_DIR having the same value. Then When I extract awesome sources, awesomerc.lua is there:

garga@tp ~/f/p/h/x/awesome ❯❯❯ make extract
===>  License GPLv2+ accepted by the user
===>   awesome-4.1,1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by awesome-4.1,1 for building
===>  Extracting for awesome-4.1,1
=> SHA256 Checksum OK for awesomewm-awesome-4.1-v4.1_GH0.tar.gz.
garga@tp ~/f/p/h/x/awesome ❯❯❯ ls -l work/awesome-4.1/awesomerc.lua
-rw-r--r--  1 garga  garga  23108 Mar 18 06:49 work/awesome-4.1/awesomerc.lua

But during build it is removed at this stage because 05-awesomerc.md.lua is called and 2nd and 3rd parameters points to the same file:

--- awesomerc.lua ---
[ 17%] Generating awesomerc.lua, docs/05-awesomerc.md, script_files/rc.lua
lua52 /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.1/docs/05-awesomerc.md.lua /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.1/docs/05-awesomerc.md /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.1/awesomerc.lua /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.1/awesomerc.lua /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.1/script_files/rc.lua
lua52: ...x11-wm/awesome/work/awesome-4.1/docs/05-awesomerc.md.lua:241: /usr/home/garga/freebsd/ports/head/x11-wm/awesome/work/awesome-4.1/awesomerc.lua: No such file or directory
stack traceback:
    [C]: in function 'assert'
    ...x11-wm/awesome/work/awesome-4.1/docs/05-awesomerc.md.lua:241: in main chunk
    [C]: in ?
*** [awesomerc.lua] Error code 1

The solution I found to get it building is to rename awesomerc.lua to awesomerc.lua.in before start building, and then patch awesomeConfig.cmake replacing:

${BUILD_DIR}/docs/05-awesomerc.md ${SOURCE_DIR}/awesomerc.lua
${BUILD_DIR}/awesomerc.lua

by:

${BUILD_DIR}/docs/05-awesomerc.md ${SOURCE_DIR}/awesomerc.lua.in
${BUILD_DIR}/awesomerc.lua

If this is an acceptable change let me know and I can provide a Pull Request.

Or the other possible solution would be to teach 05-awesomerc.md.lua to save target file to a temporary place first and then rename it in the end...

How about just forbidding builds with $SOURCE_DIR == $BUILD_DIR instead? What "nice thing" does one gain from doing in-tree builds anyway?

Ok, that can work around the problem too. But it doesn't mean 05-awesomerc.lua is not broken when it simply delete the file

@psychon BTW, I saw BUILD_DIR is set to CMAKE_CURRENT_BINARY_DIR and SOURCE_DIR is CMAKE_CURRENT_SOURCE_DIR. And on awesome port I don't explicit set none of those variables. Does it mean cmake is broken on FreeBSD by any chance?

@psychon I just found a parameter on FreeBSD ports tree to run out--source build using cmake. The default is insource. Now it builds without any intervention.

But IMO it should stop with a warning when users try to run in-source builds to make it easy to understand what is happening

@psychon Re-assigning myself. I don't much time, but I have a branch with the doc example system rewrite in pure Lua+less processes. It also fix this issue by turning the problem on its head. My patch make LDoc/CMake/TestsExamples create a "dirty" copy of the files and don't touch the original (+ a custom fix for awesomerc.lua). This way the line numbers are never changed. The backtrace will start working again. The downside is that the installed files will have --@DOC____EXAMPLE@ in them. But you can't view images in a text editor, so this is a non-issue.

  • It's much faster than the current CMake based tests/example system
  • It's a "single" process (well, 1 dispatcher/sink and 2 worker threads)
  • It removes some hacks for codecov/coveralls line numbers
  • It run as a compilation unit instead of CMake
  • It create releases with "clean" backtraces instead of the current offset issue
  • It doesn't lose any features compared to the current system

Most of the code is written and it can generate most examples correctly. But it isn't complete yet, but it will get there.

Was this page helpful?
0 / 5 - 0 ratings