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
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.
tests/example systemMost of the code is written and it can generate most examples correctly. But it isn't complete yet, but it will get there.
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.tests/examplesystemMost of the code is written and it can generate most examples correctly. But it isn't complete yet, but it will get there.