Arch Linux: Scripts do not work properly when called from PKGBUILD

[DAC324]

Hello all,

meanwhile, the atom build process has, fortunately, been simplified significantly. Thanks a lot to everybody who contributed there!

Literally, all you have to do is

git clone https://github.com/atom-community/atom.git
cd atom
script/bootstrap
script/build --no-bootstrap

What I do not understand is why that does not work if invoked from a PKGBUILD file using the makepkg tool. In particular, script/bootstrap fails when called from PKGBUILD:

internal/modules/cjs/loader.js:1187
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: /opt/.cache/yay/atom/src/atom/apm/node_modules/atom-package-manager/node_modules/git-utils/build/Release/git.node: undefined symbol: git_net_url_is_default_port
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1187:18)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
    at Module.require (internal/modules/cjs/loader.js:1025:19)
    at require (internal/modules/cjs/helpers.js:72:18)
    at Object.<anonymous> (/opt/.cache/yay/atom/src/atom/apm/node_modules/atom-package-manager/node_modules/git-utils/src/git.js:3:22)
    at Module._compile (internal/modules/cjs/loader.js:1137:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
Error: Command failed: /opt/.cache/yay/atom/src/atom/apm/node_modules/atom-package-manager/bin/apm --version
    at checkExecSyncError (node:child_process:828:11)
    at Object.execFileSync (node:child_process:863:15)
    at installApm (/opt/.cache/yay/atom/src/atom/script/lib/install-apm.js:20:18)
    at /opt/.cache/yay/atom/src/atom/script/script-runner/node_modules/threads/dist/worker/index.js:109:26
    at Generator.next (<anonymous>)
    at /opt/.cache/yay/atom/src/atom/script/script-runner/node_modules/threads/dist/worker/index.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/opt/.cache/yay/atom/src/atom/script/script-runner/node_modules/threads/dist/worker/index.js:4:12)
    at runFunction (/opt/.cache/yay/atom/src/atom/script/script-runner/node_modules/threads/dist/worker/index.js:106:12)

When script/bootstrap is run directly from the terminal, that error does not occur. Why? Interestingly, if I run script/bootstrap subsequently from PKGBUILD using makepkg -f, it completes successfully as well.

[kaosine]

I'd recommend getting it from the azure pipelines in the readme. But this might also be related to some fixes someone is working on in their personal repo that hasn't been pulled in yet. We're trying to update a lot of the toolings from the original atom builds that don't seem to work properly as of right now for some reason....

[DAC324]

I'd recommend getting it from the azure pipelines in the readme.

That readme says:

binaries can be downloaded from the [Azure Pipeline](https://dev.azure.com/atomcommunity/atomcommunity/_build/latest?definitionId=10&branchName=master). From this pipeline, the latest run can be selected. From there, the 8 published link should be selected to download the files.

Sorry if that sounds stupid but I must admit that using the link provided, I am unable to find the "latest run" and also that "8 Published" link the readme is referring to.

[DeeDeeG]

the "latest run" sentence is out of date, and was supposed to be deleted, but someone merged before it got deleted. Feel free to disregard that bit.

Edit: the sentence is out of date, not the run itself.

Do a find in page (Ctrl + F, or Cmd + F) and search for "published". It's a pretty small button, and it's not immediately obvious from its styling that it's even a button.

[DAC324]

script/bootstrap indeed is a masterpiece of programming.

It is even able to distinguish between

GYP_DEFINES="openssl_fips="
script/bootstrap

and

GYP_DEFINES="openssl_fips=" script/bootstrap

Previously, I assumed both methods of calling the script are equal to each other - but that does not seem to be the case. I take my hat off!

[DeeDeeG]

There are a lot of subprocesses involved in many Node scripts.

In the first example, you set an environment variable in the current shell session, then call the script.

In the second example, you set the env var specifically/only for the context running the script.

(I'm not sure why it makes a difference? Second example could be seen as more explicitly asssociating the env var with the script execution context, I guess?? Sorry for the hassle this caused. I'm still unclear what the exact cause of the problem is, to be honest. But I definitely believe it happened.)

I think export VAR=VALUE is the most portable way to do it. Tends to work best for me.

[DAC324]

Meanwhile, I was able to identify a cause for script/bootstrap failing when called from within a PKGBUILD. You have to clean ~/.atom/compile-cache and ~/.atom/snapshot-cache first. After that, atom/apm/node_modules/atom-package-manager/node_modules/git-utils/build/Release/git.node: undefined symbol: git_net_url_is_default_port error does not occur anymore when script/bootstrap is run from the PKGBUILD file.

[DAC324]

Meanwhile, I was able to identify a cause for script/bootstrap failing when called from within a PKGBUILD. You have to clean ~/.atom/compile-cache and ~/.atom/snapshot-cache first. After that, atom/apm/node_modules/atom-package-manager/node_modules/git-utils/build/Release/git.node: undefined symbol: git_net_url_is_default_port error does not occur anymore when script/bootstrap is run from the PKGBUILD file.

OK, looks like this has been fixed.

Now that error occurs even when script/bootstrap is executed directly from the command line. Good work :)