Hi I have a Windows OS and I currently have the most up to date version of Node.JS running (which includes npm). I would really like build and compile 0.1.91 which can be found here http://nodejs.org/dist/. I'm extremely new to this and any all help would be greatly appreciated.
Node first supported native Windows builds in the .5 dev branch. To make it happen, they had to rewrite many internals from scratch – the platform compatibility layer now exists as libuv.
Before that, you had to build Node under Cygwin. I remember building .4 in Windows with Cygwin, and it was a complete pain. The GitHub wiki has since pulled down all Cygwin-related information since it's no longer relevant. (If you really want to see how Cygwin builds were done, I suppose you could clone the wiki's repo and go digging around. The information isn't available online anymore.)
Support for building on Windows with Cygwin wasn't added until 0.1.98, and support was dropped with .6. So, the specific version you're trying to build won't work.
At any rate, it's a very bad idea to run very old software, especially something like Node 0.1, which was still very early in its development. It's nearly guaranteed to be full of security holes.
Related
Unfortunately, we have projects with different nodejs versions. I am not sure if this is like java where I can have multiple jdks installed(multiple nodejs installed) and each project magically uses the correct version via a config file? Also, most commands in tutorials are not including version numbers when installing tools and libraries like so
npm install -g expo-cli (tool)
npm install #react-navigation/native (library)
Coming from gradle with the gradle wrapper where everyone on the team uses the tools and library versions defined in the build.gradle file, this is odd to me. In the gradle world, everyone on the team uses the same exact version of gradle(gradle itself ensures if one person upgrades it in the repo, everyone gets the upgrade and stays in sync on the same version). Then there is plugins/tools and those versions are defined and then libraries and those versions are defined.
How do I guarantee everyone is using the same npm, node, expo, etc. tools?
How do I guarantee everyone is using the same libraries?
How do I guarantee everyone is using the same typescript?
Ideally, we upgrade any of these in the repo + any fixes to the upgrade so on checkout, developers start using the new tool + new *.tsx files so it is seamless much like in the gradle world. In gradle, I upgrade the
version via a property
versions of plugins/tools
build.gradle files
any source code files
and check that all in as a unit such that any developer that checks out is using all the correct versions together. I want this in react-native for our ios/android mobile project or as close as I can get.
I have hacked things before as in installing 'ant' into the git repo and this worked wonders(even though it is such an ugly hack) and everyone used the tool in the repo instead of the one on their OS. Perhaps there is a way to do that?
A bloated repo with binaries was worth it's weight in gold to prevent version compatibility hell as people upgraded libraries over time. NOT only that we found that tool bugs were easier to track down as we could revert the repo. NOT only that, we could reproduce builds form 1 year ago as the tooling was reverted where todays npm tools can't build the 1 year ago thing due to all the changes. The advantages just kept piling up and up and I can't even remember all of them.
Tooling running from the repo either via bootstrap like gradle wrapper or full blown thing is generally the best option until the full blown thing is really bloated but even then locking it to a hash on another tool repo could be better
Any ideas welcome here to put my team on all the same tooling(works great for people joining the company or team from another project as well to not have to install much).
thanks,
Dean
Typescript and libraries should be taken care of by removing any carets and tildes in your package.json and specifying exact versions.
One low overhead possibility for the rest could be shell scripting and a private package repo. You could host the versions you want to install internally, and get it all through cURLs.
Or you could add some simple scripts in your npm pre-install, for example nvm use 12.2.1 should, through error messages, guide the user to installing nvm and using the proper version.
I use and love cygwin, but every few weeks it notifies me that a new installer is available and I should use it to get the latest bugfixes. But I find this quite annoying because of my company policy, where downloading, installing and running a new .EXE file is a bit of a process due to paranoid company monitoring software.
I am just curious why the installer updates so frequently and what will happen if I don't update it. It is after all just an installer - all it does is it downloads updated packages and installs them (or rather, that is what I believe all it is doing). I do not understand why such a simple tool should have so many fixes/updates over time. If I don't update the installer, will I miss out on updates to the cygwin packages themselves?
I have been using the same cygwin version since years now and not faced any issues.If the application is working as expected then you dont need an update unless you face some trouble or you are migrating to a new windows Os which might have some compatibility issues.
Note : There is no guarantee that there will not be any problems with applying updates and also the cygwin faq section says that after updates issues should be reported to the project or product supplier for remedial action.
https://cygwin.com/faq/
The changes in Setup are usually to improve the functionality or correct some
issue.
See relative Announce:
https://sourceware.org/pipermail/cygwin-announce/2021-April/010021.html
Most of the time, previous version continues to work fine.
Broke of compatibility is very rare.
I was trying to follow the the installation tutorial of the Native Client SDK found here. However, my Samsung Chromebook (in developer mode) does not want to run ./naclsdk (chmod +x done), but instead returns the following:
32-bit runtime environment was not found on this
system. Specifically the 32-bit dynamic loader which is needed by the NaCl
compilers was not found ('/lib/ld-linux.so.2'). On modern debian/ubuntu
systems this is included in the 'libc6:i386' package.
On here they write that the PNaCl should run on ARM computers, however, on some other forums I read that wasn't the case. I've tried enabling two flags, as described on a site which I can't post due to a lack of reputation, but it looks like that'll only change things when using PNaCl, not during the installation of the SDK.
Is it possible to install that SDK on my Chromebook and, if so, how?
There's a bit of confusion: when the documentation says "PNaCl and NaCl work on ARM", it means the part that runs inside of Chrome which users would use. The SDK is currently only built for x86-64 Windows/Linux/OSX, and not for ARM. The main reason is that it's never been requested, probably because ARM machines are quite slow compared to usual development machines.
That being said, I don't think it's silly to use ARM as a development machine, and I've built my own PNaCl toolchain for ARM in the past. There are build instructions for the toolchain. I haven't built it recently, and it may have bitrotted a bit so if you run into issues I suggest emailing the team or better yet sending a patch! I expect any issue to be fairly minor, especially if you only want to use pnacl-clang or nacl-clang (as opposed to the GCC toolchain).
I'm trying to get started with Node.js on a Windows machine. Yes, I found the installer on their site. That worked just fine and I can run it. However, after that there's no instructions or requirements. Some issues I ran into:
I learned that most of these cool modules need to be built locally.
I was told I needed Git installed
I found I needed Python to build modules
I discovered I needed Visual Studio to compile
Once things are built they should be executable. However, they are not natively found in the path. I discovered them under %APPDATA%\npm, but there's no mention of adding that to the PATH.
What else am I going to discover? Is there a guide to this anywhere?
Altough I might suggest you to develope node on a unix based os (Ubuntu 12.04+WebStorm is my favorite combination for many reasons I can mention) I found my self in your situation at work when Windows 7 is a must.
I found this video really helpful
Once youe have node installed on your machine (window or any other) I (and most community) would recommend you to use WebStorm as IDEA it contains every inch of support to make your development process easy and clean, mange your global and local modules and build/debug your code easily.
It sounds like you've actually installed Node.js fine, but are having problems with the packages built by people in the community, some of which use Python or a native C compiler. Git shouldn't be necessary unless you're perhaps cloning projects from a remote repository? Or maybe the packages have dependencies on projects hosted in GitHub?
Keep in mind that Node is separate from all the modules and packages available in the community, accessed through the npm registry. Node provides you the ability to execute JavaScript locally, additional APIs, and an ecosystem to build additional packages which can do, as you've said, really cool things. But each of these packages can have unique installation requirements.
Most packages have dependencies of their own, and are often installed using the npm install command. This (usually) downloads other packages from https://www.npmjs.org/, and in some cases requires compiling additional files. This might have been the issue you hit.
The other thing to keep in mind is that a lot of people might assume things are installed and available since they have it installed for them, or are running a different operating system than you. I've often found that folks will hard code / somewhere in their scripts, which cause problems on Windows based systems. This can lead to problems with the executables that are created as part of the node packages created by the community.
To better understand what Node has and what's available, I'd recommend the nodeschool.io projects. These cover some of the main areas provided by the base Node platform, and get you used to playing around with things from GitHub and npm. Maybe if you run into specific issues there folks can help more directly.
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.