Open DAC324 opened 2 years ago
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....
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.
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.
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!
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.
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.
Meanwhile, I was able to identify a cause for
script/bootstrap
failing when called from within aPKGBUILD
. 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 whenscript/bootstrap
is run from thePKGBUILD
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 :)
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
What I do not understand is why that does not work if invoked from a
PKGBUILD
file using themakepkg
tool. In particular,script/bootstrap
fails when called fromPKGBUILD
:When
script/bootstrap
is run directly from the terminal, that error does not occur. Why? Interestingly, if I runscript/bootstrap
subsequently fromPKGBUILD
usingmakepkg -f
, it completes successfully as well.