I've been reading about youcompleteme plugin for VIM.
The problem is, however, that I want a setup I just can move onto my other dev platforms (OpenIndiana, FreeBSD, Linux and OS X).
Wouldn't using macvim make that somewhat difficult, moving plugin from platform to platform?
Cheers
MacVim is simply a distribution of Vim for Mac OS but most of Vim plugins are compatible with the multiples versions of Vim for the different OS.
Still YouCompleteMe comports a compiled component so your question is legit to wonder if it will work on different OSes. According to the installation section of the Readme of the project, YCM can be installed on OSX, Linux and FreeBSD with a plugin manager like Vundle. (I really don't know OpenIndiana and it isn't mentioned on the Readme page so I can't say if you'll have a problem with this one)
One point you should take care is that if you update the plugin and the compiled component has changed you'll have to recompile it but it doesn't happen that often and you should get a warning at the update.
TL;DR This shouldn't be an issue to use YCM on most of the common OSes but when updating remember that you might need to recompile the compiled component sometimes.
Related
I am in the process of installing SDL 2 on Mac OSX 10.9 via macports, and for reference I have been following the official documentation as well as any sdl-specific information I can find.
https://guide.macports.org/ is straight-forward, as is:
https://guide.macports.org/#using.variants.invoking
I see that sdl2lib is available...
libsdl2 has the variants:
universal: Build for multiple architectures
x11: Enable X11 support
but despite having looked through pages at the above links and having searched for documentation for "SDL with X11", I can't seem to find information about whether I need X11 (and/or universal AKA powerpc) support. I wouldn't want to install SDL only to find that something is broken or missing.
Then again, there were some issues with X11 being enabled by default back when Mac OSX 10.1 was new:
https://forums.libsdl.org/viewtopic.php?t=2871&sid=52ca72a72c285196dd25fd8619715ae9
(That is another problem: much of the information I discover applies to outdated operating systems.)
Apparently SDL wasn't thread-safe at one point unless you used X11, but this was mentioned when SDL verson 1 was the main version:
http://forum.freegamedev.net/viewtopic.php?f=3&t=1078
How am I meant to proceed (Which flags, if any, are usually chosen?)
port install libsdl2 <???>
I would appreciate any help and follow-up warnings for the next stepsinstallation steps.
Thank you in advance.
Most people have moved to Homebrew as their package system, but Macports should work just fine.
Universal does not mean PowerPC necessarily. In fact almost no one needs it anymore. Universal means a fat binary, which architectures this defines is set in your Macports configuration.
SDL2 should work just fine under Quartz, no need to have X11 - as also makes deployment annoying and difficult as you need to have XQuartz installed.
Also don't be afraid to reinstall SDL2 with other options if you miss something, it shouldn't take to long.
TL;DR Just install it without any additional flags unless you discover you need something special.
I have a bit of a problem. I need to use the strace utility to figure out why a command is crashing on an older Linux system. Unfortunately, I don't have strace nor do I have gcc/binutils on that system.
I tried building the app statically on a current Debian system, but calls to getpwnam require a dynamic load of the version of libc that was used at compile time. That would be fine, but being that the utilities on the older system were all built using an ancient version of libc, putting a newer libc on that system breaks everything else.
Short of downloading and installing an old distribution of Linux and then doing the build, is there an easier way around this problem? The original distribution on this system is currently unknown and the more I research it, it's getting to seem like a huge chicken vs egg problem. Any tips would be much appreciated.
Using an outdated Linux system is never wise... can it be upgraded? If not, why not? What is failing, and how? Any chance of updating that?
There should be a file named /etc/release or similar, that should give you an idea of the distribution and version. Or uname -a might give a clue on the distribution. If it doesn't work, try to see if commands like rpm, apt-get, or one of the other package management commands are available, that will narrow down the distribution. A Google search for some of the installed packages with versions might help narrow down the version of the distribution.
Knowing distribution and version you may be able to get strace (and perhaps other needed packages). Many distributions keep archival versions (at least of the original installation media for old versions) around.
I have done a little work on lazarus' free pascal. So when a client asked me to write an application for a mac, after the initial, "it can't be done" stage. (followed by an asp.net maybe stage) i thought about writing it using lazarus.
Question is. I have only a virtual machine running mac OSX, this means that i do not really want to develop on the mac. However, i just cannot seem to get the applications that i have written in lazarus on windows to work on the mac. I have tried the deployment using the Lazarus Wiki and the MACOS folder is empty and so when i put it on the mac it doesn't run the application.
What is the best way of doing this or am i barking up the wrong tree?
It seems you want to do cross-compiling, which is theoretically possible, but may not be practical, for the reasons mentioned by Marco above.
As an alternative, you could install XCode, FreePascal, and Lazarus on a MacOX machine. You could still do your development and some testing on Windows/Linux. When you hit a certain milestone, you can copy your source code to the Mac and compile your application to test and give to the user.
Even if it were possible to easily cross-compile, there some minor differences between platforms, so (especially if it's a GUI app), you would want to test it on an actual MacOS box before giving it to the client.
I've taken the route described by Noah - and I was incredibly surprised that after about three weeks development on Windows, it took about 10 minutes to get the application running on the Mac.
My route was to install Xcode 4.3 on an old Mac Mini running snow leopard, then install Lazarus using the fink version as described here. This took a while but was done in an evening.
Then I just copied my folder across to the Mac, opened the lpi on the Mac, compiled it. It failed so I removed a windows references, recompiled, and it was working. I was truly amazed.
What linker and assembler do you use to generate binaries? To my best knowledge the linker for recent OS X versions is not available in source.
Afaik what you want (crosscompiling to Mac) is not possible for recent versions (and I've done it for PowerPC myself in the past).
The easiest is to use the Unix "file" command on the binary to see what is generated, and make sure it reads something with "MachO" in it. Easiest is if you have a Linux install (where this command is pretty standard), but versions can be found for windows too (cygwin, mingw and 3rd party)
I am sort of switching to a Mac based development environment as the Mac line of laptops and workstations contains some very nice systems, albeit pricey. As an occasional Emacs developer, I want to build Emacs from the git/bazaar sources. Much to my surprise, the first time I attempted to do this using Xcode4, I discovered that the version of autoconf supplied with Xcode is less than that required by Emacs. So this raises the question: what approaches do those who develop Emacs daily using Mac hardware take in order to have the required libraries and headers available to build and run the Emacs development code on OS X? Left to my own devices, I will fetch and build the versions of components required by Emacs that are not satisfied by Xcode and put those into /usr/local/... but it does occur to me that other approaches, using fink for one example, might be less work and/or more satisfying, hence the question. This also applies to the add-on packages for graphics support (pdf, dvi, png, etc.) that are not supplied by Xcode.
The directions in the file nextstep/INSTALL is to issue the following commands:
./configure --with-ns
make install
The resulting "app" can be found in nextstep/Emacs.app.
However, there is an XCode project provided with Emacs, but I haven't got it to work.
I use the macports package 'emacs-app', which is just emacs configured --with-ns. They're currently at version 23.2.1
Even if you want to build emacs direct from GNU repos, using macports to get autotools should save you some time and energy. The autoconf package is at 2.68, and emacs configure.ac requires 2.65
I've spent some time today playing with getting the source for python 3.1.1 to build on my MacBook Pro using the --enable-framework and --enable-universalsdk options with no success. I will humbly admit that I have no real clue why I can't compile 3.1.1 on Snow Leopard, I did make sure to get the new Xcode version for Snow Leopard, and made sure I also installed the 10.4u SDK. It seems to be choking on the 10.4 SDK during the make stage, and has several error regarding headers for wchar, cursor, and ncursor during the configure stage. I have been able to get a make from a plain configure, and most the test pass, but that just isn't challenging enough. Has anyone else attempted to build python 3.1.1 on a Mac running Snow Leopard
There is an automated installer here: http://python.org/ftp/python/3.1.1/python-3.1.1.dmg
You need to set MACOSX_DEPLOYMENT_TARGET if you actually want to use an older SDK.
If you target 10.6, it may be that PPC building is not supported anymore, according to this bug report. In fact, that may be the case even if you target 10.4, using XCode 3.2 (haven't tried myself).
I don't have 10.6 installed yet so I can't say for sure it will work without issue but, in general, if you want to build a batteries-included framework build optimized for 10.6 of Python on OS X, you're best off using the installer build script in the source tree at Mac/BuildScript/build-installer.py after applying the patch in the bug report Martin referred to. Something like this should work [untested]:
./build-installer.py --sdk-path=/Developer/SDKs/MacOSX10.6.sdk --universal-archs=intel --dep-target=10.6 --src-dir=... --build-dir=...
That will build everything including dependent third-party libraries and the documentation but, be forewarned, you'll probably have to tweak things until you get it right and a few things aren't supported yet in 64-bit, most notably, tkinter. As mentioned above, the standard python.org 3.1.1 installer should likely work OK as long as you don't need 64-bit support.
[EDIT: I should clarify that, WRT 64-bit support, the problem isn't in tkinter, rather that the Apple-supplied versions of Tk in 10.5 and earlier were 32-bit only and so there was code in setup.py to prevent attempting to build a 64-bit version of tkinter on OSX. Perhaps that check can be removed now if the 10.6 Tk is 64-bit.]
Kenneth Reitz's soluton doesn't work for me. In fact, the install works fine but my default PATH still points to /usr/bin/python (v2.6.1.). I vaguely recall that we should be modifying our ~/.profile to point to /.../Frameworks and I expected the installer to do this for me (nope).
Anyway, /Library/Frameworks/Python.framework/Versions/3.1/bin exists so we could add it.
But I'm curious why the python bin in there does a crash and burn on me.
No time to resolve this now. Bye.