search

pkulchenko / ZeroBraneStudio

Lightweight Lua-based IDE for Lua with code completion, syntax highlighting, live coding, remote debugger, and code analyzer; supports Lua 5.1, 5.2, 5.3, 5.4, LuaJIT and other Lua interpreters on Windows, macOS, and Linux
http://studio.zerobrane.com/
Other
2.61k stars 519 forks source link

Cleanup wrapper script that launches IDE #1039

Open alerque opened 4 years ago

alerque commented 4 years ago

See commit comments.

Eventually a configure/build time flag should be added to set a system supplied Lua without having to patch at all, but this step in that direction at least makes things easier to start with.

alerque commented 4 years ago

Oops, branched from an old repository, I'll rebase on current master.

alerque commented 4 years ago

Rebased. Note the difference was that in 78229a90 you suppressed warnings. My rebase also reverts that. Suppressing everything on STDERR is also an anti-pattern. If launched from a zbstudio.desktop type launcher there will be no warnings anyway. If running it from the shell then STDERR needs to be passed through to the user (incidentally I am not seeing any warnings at all launching and editing a few files).

pkulchenko commented 4 years ago

Suppressing everything on STDERR is also an anti-pattern.

I agree, but it's done for practical purposes, as there are some messages from libraries that wxwidgets using, which clutter the output unnecessarily. Those of us who run debug builds and need to see assertions and other related messages, can easily tweak the launch script, but for everyone else I don't see a reason to get those messages.

I like the idea of providing lua executable path to launch with, but I think it needs to be specific to the IDE (in name), as there is a version dependency on (included) libraries.

pkulchenko commented 4 years ago

@alerque, how is LUA_EXECUTABLE set in your environment? Can we replace it with something like ZEROBRANE_STUDIO_EXECUTABLE? I'd prefer not to rely on LUA_EXECUTABLE, as it's too generic and may run into conflicts when the version of the executable and the one expected by the IDE don't match.

pkulchenko commented 4 years ago

@alerque, just to get back to my earlier question: do you need specifically LUA_EXECUTABLE name in the script or can we use an alternative (as suggested above)?

alerque commented 4 years ago

I believe this is because LUA_EXECUTABLE is what gets set by autoconf tools with the Lua detection macros we were using for SILE. I don't think there is anything magic about it.

In your case your CMakeLists.txt is already using finding Lua and setting the value in LUA_EXECUTABLE (so both GNU autoconf and CMake use the same variable) and you don't have to do anything further to get this substitution. You shouldn't use something specific to ZBS here, just go with the variable CMake is already setup to generate for you.