enlightenment/efl
enlightenment
/
efl
8
7
Fork 14
Code Issues 13 Pull Requests 1 Projects Releases Wiki Activity

edje, build: don't use fullpath() #22

Closed
vtorri wants to merge 1 commits from (deleted):master into master
pull from: (deleted):master
merge into: enlightenment:master
Conversation 14 Commits 1 Files Changed 1 +3 -3
vtorri commented 2023-04-18 21:00:33 -07:00
Owner
Copy Link

this breaks compilation on Windows for meson >= 0.54.2

this breaks compilation on Windows for meson >= 0.54.2
vtorri added 1 commit 2023-04-18 21:00:35 -07:00
raster commented 2023-04-19 01:35:34 -07:00
Owner
Copy Link

hmmm... full path is at least meant to remove $PATH from having an effect. what breaks on windows and why should we not use the full path?

hmmm... full path is at least meant to remove $PATH from having an effect. what breaks on windows and why should we not use the full path?
vtorri commented 2023-04-19 01:40:48 -07:00
Author
Owner
Copy Link

the problem is not edje itself, but the edje in the ethumb module. Basically, meson does not find edje.exe for the ethumb module.

I'll ask the guy for a more precise answer.

the problem is not edje itself, but the edje in the ethumb module. Basically, meson does not find edje.exe for the ethumb module. I'll ask the guy for a more precise answer.
vtorri commented 2023-04-19 04:34:18 -07:00
Author
Owner
Copy Link

reason: it is used in a custom_target

"custom_target(..., command: [edje_cc_exe, ...])"

reason: it is used in a custom_target "custom_target(..., command: [edje_cc_exe, ...])"
eschwartz commented 2023-04-19 06:24:33 -07:00
First-time contributor
Copy Link

hmmm... full path is at least meant to remove $PATH from having an effect. what breaks on windows and why should we not use the full path?

Hi. The problem here is:

  • rich program objects, such as executable() target return values, are intrinsically able to be handled correctly. Meson will already produce build rules that refer to them by filepath rather than $PATH (??)
  • rich program objects automatically produce inter-target dependency linkage, so you don't need to add them as depends: (the latter "should" only be needed in cases where the command internally performs globbing or something)
  • rich program objects know that they aren't available at configure time, but will be available at build time, so e.g. a proper error message can be raised when they are used in run_command() while allowing it to work in custom_target()
  • recentish versions of meson do a quick configure-time check that custom_target commands are installed, so if the command is a string rather than a program object (find_program or executable) it will go and internally do find_program on the string. This fails here, because the string refers to something that won't exist yet
  • running a program using env will skip that "does it exist yet" check because meson doesn't know that the string argument to env is a program rather than a parameter
> hmmm... full path is at least meant to remove $PATH from having an effect. what breaks on windows and why should we not use the full path? Hi. The problem here is: - rich program objects, such as executable() target return values, are intrinsically able to be handled correctly. Meson will already produce build rules that refer to them by filepath rather than $PATH (??) - rich program objects automatically produce inter-target dependency linkage, so you don't need to add them as `depends:` (the latter "should" only be needed in cases where the command internally performs globbing or something) - rich program objects know that they aren't available at configure time, but will be available at build time, so e.g. a proper error message can be raised when they are used in run_command() while allowing it to work in custom_target() - recentish versions of meson do a quick configure-time check that custom_target commands are installed, so if the command is a string rather than a program object (find_program or executable) it will go and internally do find_program on the string. This fails here, because the string refers to something that won't exist yet - running a program using `env` will skip that "does it exist yet" check because meson doesn't know that the string argument to `env` is a program rather than a parameter
eschwartz commented 2023-04-19 06:30:42 -07:00
First-time contributor
Copy Link

BTW since meson 0.57 (a hefty bump in minimum version, I know) you can pass env: {'EFL_RUN_IN_TREE': '1'} to a custom target, and it will either use /usr/bin/env if possible or a slightly slower python implementation (meson --internal exe) for you.

BTW since meson 0.57 (a hefty bump in minimum version, I know) you can pass `env: {'EFL_RUN_IN_TREE': '1'}` to a custom target, and it will either use /usr/bin/env if possible or a slightly slower python implementation (`meson --internal exe`) for you.
vtorri commented 2023-04-22 03:51:54 -07:00
Author
Owner
Copy Link

@eschwartz i have this error now:

[1/295] Generating src/modules/ethumb/emotion/edje_cc_template.edc with a custom command (wrapped by meson to set PATH)
FAILED: src/modules/ethumb/emotion/template.edj
"C:/Documents/msys2/mingw64/bin/meson" "--internal" "exe" "--unpickle" "C:/Documents/msys2/home/vincent.torri/gitroot_64/efl/builddir/meson-private/meson_exe_ed
je_cc_f7ecb5b8bab607b7d0a6603a744b2ed171bde1ad.dat"
Traceback (most recent call last):
  File "C:/Documents/msys2/mingw64/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:/Documents/msys2/mingw64/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:/Documents/msys2/mingw64/bin/meson.exe/__main__.py", line 7, in <module>
  File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 294, in main
    return run(sys.argv[1:], launcher)
  File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 282, in run
    return run_script_command(args[1], args[2:])
  File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 223, in run_script_command
    return module.run(script_args)
  File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/scripts/meson_exe.py", line 121, in run
    return run_exe(exe)
  File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/scripts/meson_exe.py", line 75, in run_exe
    raise FileNotFoundError('due to missing DLLs')
FileNotFoundError: due to missing DLLs
@eschwartz i have this error now: ``` [1/295] Generating src/modules/ethumb/emotion/edje_cc_template.edc with a custom command (wrapped by meson to set PATH) FAILED: src/modules/ethumb/emotion/template.edj "C:/Documents/msys2/mingw64/bin/meson" "--internal" "exe" "--unpickle" "C:/Documents/msys2/home/vincent.torri/gitroot_64/efl/builddir/meson-private/meson_exe_ed je_cc_f7ecb5b8bab607b7d0a6603a744b2ed171bde1ad.dat" Traceback (most recent call last): File "C:/Documents/msys2/mingw64/lib/python3.10/runpy.py", line 196, in _run_module_as_main return _run_code(code, main_globals, None, File "C:/Documents/msys2/mingw64/lib/python3.10/runpy.py", line 86, in _run_code exec(code, run_globals) File "C:/Documents/msys2/mingw64/bin/meson.exe/__main__.py", line 7, in <module> File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 294, in main return run(sys.argv[1:], launcher) File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 282, in run return run_script_command(args[1], args[2:]) File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 223, in run_script_command return module.run(script_args) File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/scripts/meson_exe.py", line 121, in run return run_exe(exe) File "C:/Documents/msys2/mingw64/lib/python3.10/site-packages/mesonbuild/scripts/meson_exe.py", line 75, in run_exe raise FileNotFoundError('due to missing DLLs') FileNotFoundError: due to missing DLLs ```
eschwartz commented 2023-04-22 19:27:17 -07:00
First-time contributor
Copy Link

This would presumably be an even bigger issue for using .full_path, which attempts to run the full path of a .exe without necessarily getting that to work in terms of injecting DLL dependencies.

In theory, that's exactly why you want to use the exe directly, since meson will detect when the first element of a command: kwarg is a returned executable() object, and in that case it will use self.determine_windows_extra_paths() to update the %PATH% for that command when running it. See e.g. https://github.com/mesonbuild/meson/blob/master/mesonbuild/backend/backends.py#L1115

I'm not sure why this is going wrong for you, but in general maybe we should be reporting more error information here anyway, so... can you try to build efl using this personal branch of meson that has a bit more debug information?

https://github.com/eli-schwartz/meson/tree/meson_exe-debugdll

This would presumably be an even bigger issue for using .full_path, which attempts to run the full path of a .exe without necessarily getting that to work in terms of injecting DLL dependencies. In theory, that's exactly why you want to use the exe directly, since meson will detect when the *first* element of a `command:` kwarg is a returned `executable()` object, and in that case it will use `self.determine_windows_extra_paths()` to update the `%PATH%` for that command when running it. See e.g. https://github.com/mesonbuild/meson/blob/master/mesonbuild/backend/backends.py#L1115 I'm not sure why this is going wrong for you, but in general maybe we should be reporting more error information here anyway, so... can you try to build efl using this personal branch of meson that has a bit more debug information? https://github.com/eli-schwartz/meson/tree/meson_exe-debugdll
vtorri commented 2023-04-23 08:39:16 -07:00
Author
Owner
Copy Link

@eschwartz here is the result

[1949/1957] Generating data/elementary/objects/prefs_compile with a custom command (wrapped by meson to set PATH)
FAILED: data/elementary/objects/test_prefs.epb
"C:/Documents/msys2/mingw64/bin/python.exe" "C:/Documents/msys2/home/vincent.torri/gitroot_64/meson/meson.py" "--internal" "exe" "--unpickle" "C:/Documents/msys
2/home/vincent.torri/gitroot_64/efl/builddir/meson-private/meson_exe_env.EXE_ef7178bc96c2b2b7a9dea1f2422d9ee4fdbdd210.dat"
while executing ['C:\\Documents\\msys2\\usr\\bin/env.EXE', 'EFL_RUN_IN_TREE=1', 'C:/Documents/msys2/home/vincent.torri/gitroot_64/efl/builddir/src/bin/elementar
y/elm_prefs_cc.exe', '../data/elementary/objects/test_prefs.epc', 'data/elementary/objects/test_prefs.epb']
--- stdout ---

--- stderr ---

[1955/1957] Generating data/elementary/themes/edje_cc_default.edc with a custom command (wrapped by meson to set PATH)
@eschwartz here is the result ``` [1949/1957] Generating data/elementary/objects/prefs_compile with a custom command (wrapped by meson to set PATH) FAILED: data/elementary/objects/test_prefs.epb "C:/Documents/msys2/mingw64/bin/python.exe" "C:/Documents/msys2/home/vincent.torri/gitroot_64/meson/meson.py" "--internal" "exe" "--unpickle" "C:/Documents/msys 2/home/vincent.torri/gitroot_64/efl/builddir/meson-private/meson_exe_env.EXE_ef7178bc96c2b2b7a9dea1f2422d9ee4fdbdd210.dat" while executing ['C:\\Documents\\msys2\\usr\\bin/env.EXE', 'EFL_RUN_IN_TREE=1', 'C:/Documents/msys2/home/vincent.torri/gitroot_64/efl/builddir/src/bin/elementar y/elm_prefs_cc.exe', '../data/elementary/objects/test_prefs.epc', 'data/elementary/objects/test_prefs.epb'] --- stdout --- --- stderr --- [1955/1957] Generating data/elementary/themes/edje_cc_default.edc with a custom command (wrapped by meson to set PATH) ```
eschwartz commented 2023-04-23 08:43:32 -07:00
First-time contributor
Copy Link

This isn't the missing DLL error. It appears to be https://github.com/msys2/MINGW-packages/issues/11864

The issue there is that cpython itself randomly segfaults, but setting the debugger up actually stops it from segfaulting. :D

It's a flaky issue, so rerunning ninja should cause that segfault to go away.

This isn't the missing DLL error. It appears to be https://github.com/msys2/MINGW-packages/issues/11864 The issue there is that cpython itself randomly segfaults, but setting the debugger up actually stops it from segfaulting. :D It's a flaky issue, so rerunning ninja should cause that segfault to go away.
raster commented 2023-04-23 08:48:42 -07:00
Owner
Copy Link

ok. that explains it a bit more. thanks! :)

ok. that explains it a bit more. thanks! :)
raster commented 2023-04-23 08:50:48 -07:00
Owner
Copy Link

waaait... now i told gitea to rebase it on current master it says

 This pull request is broken due to missing fork information.

WTF?

waaait... now i told gitea to rebase it on current master it says ``` This pull request is broken due to missing fork information. ``` WTF?
vtorri commented 2023-04-23 08:54:02 -07:00
Author
Owner
Copy Link

@eschwartz i've relaunched ninja, same failure as above

@eschwartz i've relaunched ninja, same failure as above
vtorri commented 2023-04-23 08:56:49 -07:00
Author
Owner
Copy Link

@eschwartz if the problem is python, we have to move away from meson and use muon :p but lattis should be more reactive on irc :(

@eschwartz if the problem is python, we have to move away from meson and use muon :p but lattis should be more reactive on irc :(
raster commented 2023-04-23 08:57:25 -07:00
Owner
Copy Link

merged by

8c30cb2ef8

merged by 8c30cb2ef81c552503b6ce900ca769c13466c37e
raster closed this pull request 2023-04-23 08:57:26 -07:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: enlightenment/efl#22
No description provided.
Delete Branch "(deleted):master"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?