I use DUB, and want to include ncurses to project https://github.com/D-Programming-Deimos/ncurses/
it have not explicitly version specification on github page. But during build DUB ask me to specify version explicitly:
WARNING: A deprecated branch based version specification is used for the dependency ncurses. Please use numbered versions instead.
How I can do it?
http://code.dlang.org/package-format
Looks like your "DUB" tool is a later version than the tool used to create the 'package.json' file in the GIT repo. The message is rather obscure, but it's not a GIT message. It seems to mean that the 'ncurses' repo needs updating; send them a pull when you work out how.
This is dub complaining because the entry in your dub.json (or package.json) is "ncurses": "~master"
However, dub is trying to move away from using the "~master" branch (as it's prone to constant changes in most projects)
As the only available branch tag on ncurses is ~master you'll have to use it. I'm suprised that dub isn't working with the master branch however, as it's only a WARNING message, not ERROR.
Maybe pinging the owner of ncurses to create a tag may be a good idea?
Related
I can success install sml/nj as the doc said:http://smlnj.org/dist/working/110.99/install.html
but how to install from source,the way the doc said let me download the config.tgz,than the script install.sh can download and compile other files from the network
but if I want to edit the source code,and test the result,this way seems can't work
eg:I edit the file compile.sml,and want to see the result,so I neet to recompiler the compiler,but install.sh will download the compiler.tgz from internet,not the file I change
so Hot to install sml/nj from source?Thanks!
smlnj.org does not have an SSL certificate, the release-note README links are broken, the GitHub repo doesn't have a top-level README. Scrolling around a bit on their website, there's a link to an installation manual:
Installing SML/NJ on UNIX
It mentions the install.sh that presumably you have tried to run. Running this seems to overcome many of the complications associated with figuring out how the source code is tied together. Unfortunately, it fails on my machine; I don't know if this is because I run MacOS and cc defaults to clang, or what.
install.sh will download the compiler.tgz from internet,not the file I change
I don't experience that re-running config/install.sh will re-download the source code, but I also don't experience this command succeeding. If you notice, there is a file called config/srcarchiveurl that contains the variable SRCARCHIVEURL. When you grep around for that, it occurs in config/download.sh and config/unpack -- the latter, unpack, is a utility used throughout install.sh to ensure that a given sub-directory is present. It is supposed to check that a file was already downloaded on lines 205--209.
Every time I've wanted to install SML/NJ from scratch, I have basically given up and gone with Poly/ML, Moscow ML, MLKit, or MLton, simply because they don't require so much to install. SML/NJ is not a modern piece of software in the way that it is distributed. Poly/ML and Moscow ML are somewhat minimalist (they don't have MLB support), but easier to modify; MLton doesn't have a REPL, but is otherwise manageable to install.
I tried to follow this link to deploy application for Windows, but I don't have the file configure and I am unable to run the command.
Any help ?
Skip the configure step. What you need is the windeployqt utility.
Afterwards you may need to remove some libraries your project doesn't use. For my projects, windeployqt insists to deploy a huge openglsw.dll (or something like that), even though I don't need it.
I also recommend simply copying the MSVC libraries into your distribution rather than installing from the supplied installer package. Just make sure you got all of them, the right version and for the right architecture.
If you use the Qt Network module, you may want to also deploy the OpenSSL binaries - you'll need them if you want to access HTTPS resources.
And my last advice - use Inno Setup for installer. It is well documented, very well written, very easy to use and produces no junk.
P. S. You could use one of my open source projects for reference, I have a script to copy all the necessary files into one folder and pack it into an installer using Inno Setup. I try to keep the scripts as simple and short as possible, no junk there.
How would I write nodejs addon which would support all versions (atleast all stable versions > 0.10.6) of nodejs. For example, one version would have String::Utf8Value name(args[0]); where as another would have node::Utf8Value name(args[0]);. This is just an example but I have many scenarios where there will be different code for different versions of nodejs.
As far as I know this could be achieved in following ways.
Defining pre-processor to check which version and compile code accordingly.
if defined()//Not sure what exactly have to checked
include <nameser.h>
else
include <arpa/nameser.h>
endif
If this is the best option(which I don't think) even if multiple places pre-processor as to be added and code looks ugly, how would I achieve this. Meaning how would I check which version of NodeJS inside C/CPP addon.
Having separate file for each version and defining conditions inside binding.gyp to compile specific file based on nodejs version. If this is the best option, which variable I can refer to check the nodejs version.
Having tags while publishing npm package so that user can install for his specific nodejs version. Tag a published version. Although user has to check for the nodejs, non technical person won't be executing this, so shouldn't be a problem. The only problem I am seeing with this approach is versioning. Example, If there is a fix which has to applied for multiple tags, then, for every tag publish I have to specify different version (Not sure though).
Any other way I can achieve this which I am not aware of, if any the above options is not the good option to go with ?
I have a package I want to install. I would like the files to end up in a different directory than the installation wizard choses for them.
For example, my Sitecore copy is running at C:\SiteCore\website
The module added files to C:\SiteCore\website\Console
I would like the files to ultimately live at C:\SiteCore\website\sitecore_modules\Console
I am using Sitecore 6.5 rev 111230, but we are planning to upgrade very soon. I would like for my installed packages to migrate seamlessly once we have upgraded. For reference, the package I want to install at the moment is the Sitecore Powershell Extensions. Although, I would prefer to apply a similar method to any future packages that I install.
Is there a secret switch in the package installation process to allow me to do this? Can I do it from the package installation wizard? Is there another way to install packages?
I'm assuming I can't just change the package path and expect everything to keep working. Do I have to update a configuration somewhere (a file or inside the Sitecore CMS GUI) to make the package recognize the new file locations?
The module creator defines where files exist. If you move them you run the risk of something not working. The best idea is to ask the creator on the Marketplace page of the module.
There is no turn-key way to change this.
I guess you cand take the code from MarketPlace and you can modify it.
I don't know how exactly is the licenses with MarketPlace modules, but I think people can modify others code.
Please check on code and also on items, maybe on some fields are values for folder path.
I discovered a way to accomplish this, but it can be quite involved or even impossible, depending on the complexity and size of the package.
First of all, I did take the question to the module creator and had a very helpful and informative conversation with the creator. So thanks for that suggestion - they may even move the install location in a future release, based on my request.
The workaround is to first install the package on a system as normal. Then you figure out everything that comes with the package. For files, this is easy if your Sitecore root is under source control. For items, this is really complicated. You can search for the installed items by owner, if you had the foresight to create & use a unique user for the package installation. Or you can check the untyped files in the package that are essentially xml based item manifests.
Once you have a detailed list, you make the desired modifications to the locations. Then you recreate the package yourself using the Sitecore package designer.
This works for simple packages - I did it to one small package that I hope to get up on the Sitecore marketplace as shared source soon. And by small, I mean it was 2 files and 3 items. The package that prompted me to ask this question would not cooperate with this workaround. The included .dll had some assumptions about the file structure hard-coded into it.
The workaround I took for the more complex package was really quite basic: I just created a new source-code external to the required path. That let me wrap everything up neatly without getting medieval on the package files.
Thanks for both your answers, a very fine +1 to you.
For those who have compiled from source knows how much of a pain it is to run "./configure" only to find that X library or missing, worst yet it spits out a silly line saying a cryptic lib file is missing, which you then have to go to a web browser type in the missing file cross you fingers that Google can find the answer for you...
I find that very repetitive, so my question is:
Is there a way to work out all the required dependencies but without doing "./configure"
Read the README* or INSTALL* files in the source distribution, if there are any, or look for any documentation on the website where you downloaded it from. If the package is well documented, dependencies will usually be listed somewhere.
Given that there's no mention of a specific pkg has been mentioned, I assume this is a generic "how to avoid using configure" question. From a source tarball, no there is no automated way to work the dependencies out. That's what configure is for (you can always read the Makefiles and autoconf files and understand the dependencies manually, but then you'll miss configure very quickly). To avoid it, you need use something other the straight tarball, which has already worked out the dependencies.
For example you can switch to building source rpms (or debs, dependending on your system). Or you can use a system such as Gentoo which is really good at working out the dependencies for you. But all of these require the pkg you're interested in to be available in their format, so they won't work for tarballs that you download from the source provider.
Read configure.ac/configure.in. Look for calls to AC_CHECK_LIB, AC_CHECK_LIBS, AC_SEARCH_LIBS, AM_PATH_* (some old packages that don't use pkg-config put their checks into the AM_* namespace for some reason), PKG_CHECK_MODULES (for pkg-config), AX_* (many autoconf-archive macros are written to check for uncommon dependencies) and any macro call that start with an odd name (i.e., not AC_*, AM_* or AX_*. Try grep '^[^A]'?).
One thing you can do that would be good for the community is to submit a bug report/feature request to the package maintainers. There are quite a few packages whose configure script does not abort on the first missing dependency, but runs to completion and then prints a summary of all the dependencies that are missing. That greatly reduces the tedium you describe. Unfortunately, "quite a few" translates to less than .00001 percent (this is a made up statistic). If you can convince the package maintainers to re-write their configure script to support this behavior, you will contribute to making the world a better place.
Good luck with that!