Trying to set up IntelliJ IDEA with the Lua plugin. This requires me to direct it to the location of a Lua SDK. All instructions I have been able to find for this are on a Windows system, pointing to a specific directory in Program Files. I am running a Linux system. I've built and installed Lua 5.3.4 (newest version at time of writing) from source, but as far as I can tell that doesn't include any equivalent to the SDK needed – it just drops a variety of necessary files in /usr/local/{bin,include,lib,man/man1} and creates two empty directories /usr/local/{lib,share}/lua/5.3.
Am I missing something conceptual? Do I need to get something else (the existence of which I have been unable to confirm)? Should I just give up on this and find another IDE? The plugin seems to come with two SDKs, Kahlua and LuaJ, but I don't know how well either of these match up to either standard Lua or LuaJit, which are what I would be using.
This is assuming you are using this Lua plugin for IntelliJ:
If you have installed Lua via DNF or yum simply guide IntelliJ to /urs/bin and it'll find it. (I assume this also works for other installers like apt or brew.)
It looks like the SDK is just looking for two files lua and luac which both live in /usr/bin.
Related
Assuming that I have a script that will be run on a clean build server with Nuget.exe installed on it, what is the best way to programatically determine the path for where NuGet.exe is installed?
Is there a way to infer its location by going through NuGet.targets, or reading some sort of external config file, or following some sort of convention?
Note: The closest question I've seen so far is this one that points to where NuGet can be downloaded, but I'm not interested in downloading NuGet manually. I need a way to determine where it is installed, but I'm not sure if there's a convention that I can follow to determine where it might be installed.
In general, nuget.exe is not shipped with any product. Most people need to manually download it.
The only exception is for people who install Mono. Mono ships nuget.exe, but that's generally limited to people developing on Linux or Mac. But people who use .NET Core exclusively don't need Mono, even on Linux/Mac, so they won't have it either.
Few developers on Windows install Mono, so chances are you don't have a nuget.exe on your system unless you downloaded it yourself, or someone checked it into a repo that you cloned.
So I saw this project http://mxe.cc/ and tried it, it seems like it is very easy to compile stuff for windows with this. I tried to hack it a little bit to compile binaries for linux instead, because, if it compiles for other system so easily how can it be hard to compile for host? 90% of the stuff seems to just build out of the box, but there are some errors and therefore I cannot build. I want to ask, how correctly should I configure mxe to build for the linux host? I know this is not supported but I don't think it should be that hard because we build from source anyway. And there are next to no modifications for downloaded sources too (in a windows build that is).
For people who might ask why I don't want to use shared stuff, I want to basically have two options:
dpkg package for user with dependencies specified (the linux way)
single standalone static executable
Any suggestions? Or maybe there's whole another guide on linux on how to build things from scratch (without a lot of manual work like mxe does)?
I'm trying to build an embedded simple web browser for an embedded device and I've decided to use WebKit / WebKitGTK+. However, our device uses a Linux environment somewhat based on CentOS 5.8. I haven't been able to find any RPMS or mention of support for WebKit / WebKitGTK+ for CentOS 5.8 while doing several web searches.
Does anybody know if it's possible to build an older version of WebKitGTK+ such as 1.2.6-2.el6_0 which works well on CentOS 6.3? Are any RPMS available for CentOS 5.8?
The goal here is to be able to run a relatively current, at least 1.2.6 version of WebKitGTk on CentOS 5.8
Note: I was able to sort everything out. Just took a long time compiling all of the dependencies in the correct order with the correct options. I was able to get WebKitGTK 1.6.0 running on Centos 5.8.
You shouldn't have any problems building an old version of webkit if you can install the older versions of libraries that it requires.
If you have older or newer versions of GTK+ etc installed than the old version of webkit requires it may need quite a bit of porting to compile.
I'm not aware of any RPMs that meet your requirements
Depending on the compilation options you should be able to compile the dependencies in an isolated directory. With each library you typically use the --prefix option to specify the destination. Then when compiling something that depends on that library, you typically have an option to specify where to look for that library - something like --with-libraryname=/path/to/library. You want to check ./configure --help of each thing you're compiling to get the correct options.
It'll be quite a bit of work, but you should be able to compile everything you need into an isolated directory without replacing anything on the system. I would highly recommend you avoid doing this in root to ensure you have the right options.
I want to bundle JRE 6.0 together with my java application. All my source code reside in CVS. My client will check-out the code and build it themselves. Should I store JRE in CVS?
I normally advocate putting most everything in source control, but this seems a little excessive. Why ?
the JRE is readily available from http://java.sun.com
it doesn't change that often. I'd expect you to specify a minimum version for your code to run against (e.g. 1.5, 1.6 etc.)
I would not put a JDK or JRE into a source code repository:
It is bad practice to put externally versioned things into your version control because it usually leads to over-constraining, obscuring and/or hard-wiring your app's external dependencies. (Maven or Ivy are good solutions for dealing with external dependencies, though not in this case,)
Putting binaries into version control is a bad idea for some version control systems.
But I think your real problem (actually, your user's organization's problem) is the IT folks who refuse to contemplate upgrading the JRE:
They need to be made aware of the
fact that they can install multiple
JRE versions on the one machine, and
configure apps to launch with the JRE
version they require. (It is trivial
on Linux ...)
They need to be made aware of the fact
that their policy is an impediment to
progress.
They need to be made aware of the fact
that their policy is a potential security
issue. If they force users to deploy their
own copies of JDKs / JREs in random places,
it will be difficult to ensure that JRE security
patches get applied. (Besides, 1.4.2 is due
to be end-of-life'd soonish, and security
patches for it will cease.)
EDIT: and there is also the legal question of whether "redistributing" a JRE out of your source code repository is a violation of Sun's click-through JRE/JDK download license. (I don't know ...)
As best practice, you shouldn't keep any binary files in the source control system. For Java developers there is maven that does it's work better in versioning jar files. The reason is that we want to keep our source repository as small as possible so it is faster for those that checks out our code for the first time.
But if you still want to keep binary files in the source control, it would be best to avoid using CVS, because CVS is bad in versioning binary files. You can search with google, why it is bad. If you use SVN, then it still okay because SVN handles binary files much better than CVS.
I see nothing wrong with storing the JRE in CVS.
However, it's not so important whether you do or not as long as your script can pull it as part of the build. For example, if you want to host a downloadable jre.zip on an HTTP server, or point to it in a Maven repo, that's just as good.
Well won't your client all ready have the JRE if you expect him to compile the code before running it? The JDK contains the JRE.
Depends a lot on what you use to handle dependencies. If you use Maven, then create a maven package with the stuff you need, and host it on a local repository.
If you just have CVS (like we do) then it is fine to create big binary packages (since you will need them) which you can then put in CVS. Just be aware that they should be static for best CVS performance.
ALso note that the jsmooth package can create an EXE file of your jar with an JRE embedded in it. This might solve your deployment problem.
For remote compilation, Eclipse can work with a plain JRE. You just need to tell Eclipse where JRE you already have prepared above is located on the disk. There is also a folder inside the Eclipse distribution where the launcher looks automatically.
I'm wondering about the client building the application themselves. It will require some kind of Java compiler, most probably javac wich is part of the JDK. So your client will not only need a JRE, but a JDK as well (unless they will be using Jikes or another alternative compiler).
javac is capable of generating bytecode for previous versions of Java, so using a newer compiler should not pose any problems.
Personally, I would not include large binaries like a JRE as part of my own repository. The JRE can be considered very stable and just listing the minimum version required should be enough. Installing a JRE is also something quite different than installing a single Java application. The two activities should not be mixed.
I have a program that I intend to install on Linux and Windows machines. I have it cross-compiling fine (with autotools), but at some point I would like the program to be able to update its binaries. The only ways I can think of doing this are:
Give users write access to "C:\Program Files\Foo Program" or "/usr/bin/foo_program".
or
Install the program to the user's profile/home directory.
Neither of these seems like a good idea. What would you do?
You need to give us more details on what you are trying to do - I don't understsand the link between cross platform, patching and your question.
If you need to be able to auto update the program, on linux at least, the best solution is to provide a binary package (rpm, deb, whatever, depending on your target), which is updated regularly - so that new versions will be picked up by the package manager. On windows and mac os x, things are usually more decentralized, each program has its own update manager. The best technical solution depends on the technology (C/C++/python/whatever). One exception I can think of on Linux is vmplayer, which tells you when there is a new version - but you still have to install the new version.
If the program binary is writeable, you could download the patch or the new bits to %TEMP% or /tmp then apply them to the binary. I don't think you need to be able to create new files in the directory. But you're going to run into problems on Windows with the file being in use while you try and patch it.