I have an Ubuntu server (with a VPN and a samba share), where I store all my project files and so on.
I would like not to have to back up the files I have on my computer to the server, but instead, directly use the files that are on the server.
But, when I want to build a project on Windows, it gets really slow, since I basically have to be transferring that whole bunch of files visual studio creates through the internet, so I can build the project.
The core concept is:
Open files that are on the server and use them (ie. saving one file at a time is fast enough not to make a difference).
Compile the code on Linux (Maybe code a VS extension with sockets that will tell the server to build, and that server-side, when done building, will send a message back, for VS to run and debug the program). Which would be much better since my laptop is nothing compared to the server performance-wise.
Run and debug the program with VS on windows.
I've so far only been able to find this(which is not what I want because it uses g++, and I'd like VC++) and this(which is not what I want because it's compiling for linux and executing it remotely). What I'm looking for is a mixture of both.
Remote compiling, local programming and executing.
Would also be great because supposedly, I could build with whatever VC++ version I wanted with whatever SDK I wanted. So I could basically easily switch between compiling for Windows 7 and 10.
I'd just like to know: Is it possible to achieve that? And if so how?
Using VC++ directly on Linux is not possible.
To let the Linux server do the compiling with VC++ anyway you could either use wine which apparently works with older Versions (see https://appdb.winehq.org/objectManager.php?sClass=application&iId=5766
) but propably is not easy to set up in a CLI envrioment and might cause License Issues with Microsoft, or use Windows Virtual Machines, which tend to have some Performance drawback.
The best Solution would be to use GCC (g++), which works on a wide range of architectures and operating systems and supports cross compiling.
Related
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).
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
I've been fighting a whole day with UNIX utilities - so sorry if I appear confused! I'm describing my painful and (so far) fruitless process a little because maybe someone may correct me, or maybe describing the process might be helpful to someone later on. If you want to skip this, the question is bolded below.
So I'm trying to convert a Linux program developed using kdevelop. I'm trying to make it run on Windows 7. (This is the SHoUT Speech Took mentioned here, developed by Marijn Huijbregts).
I've wasted half a day trying to install kdevelop on Windows, only to understand that kdevelop can't run on Windows and that I've been installing KDE all that time :( (If kdevelop CAN run on Windows, information would be highly appreciated).
OK, so following the advice in SO's Best environment to port C/C++ code from Linux to Windows, I installed MinGW32 only to find out that SHoUT's makefile contains targets such as aclocal, autoheader etc. - I've come face to face with the hitherto unknown GNU Build System.
I'm now in the middle of installing GnuWin32 using GetGnuWin32. This is taking hours. And I suspect that once it finishes, I'll stumble on something else.
A day of pain - and still not one code line compiled :((.
So, I'm thinking about an alternative approach: Install Linux and run kdevelop as a cross-compiler to compile to Windows. As this is a console application, MAYBE it'll be easier.
So, finally, my question:
If I want to install Linux guest in VMWare Workstation (8, running on Windows 7 host), I understand I need a "distribution". I understand there's a ton of distributions, some free, some paid.
Which distribution should I choose which would run kdevelop and be as simple as possible? I just want to ##$$ing compile, and I can't stand one more day like this...
Avi
Edit:
I've tried compiling the code using VS - very tedious. Many differences between Linuix/GCC and windows/MSVC. Moreover, this is code deveoped by someone else, and I'm not even sure that the program sovles the business needs. So I've decided on the following process:
Configure Linux and run the software on Linux.
Validate that program solves business rule. If not - Abort.
Try cross oompiling on Linux. If running on Windows, verify by comparing outputs to those obtained on Linux. If good - Done.
Try compiling on Windows using ported Windows versions of the GNU Build tools. Use understanding and values obtained from building on the Linux target. If good - Done. Else
Abend and try another solution to the business problem, or try the MS tools (again using understanding and values obtained from building on the Linux target).
Many distributions are possible. Mandriva is KDE based.
But you can also install a Debian distribution, and install KDE in it.
I suggest to contact the ShOUT project community.
You should not cross-compile. MinGW can come handy but it is not required. What you need is to port the code and its dependencies to Windows, and there is nothing wrong if you use Visual Studio, for example.
I am using Ubuntu on VirtualBox OSE and through it use kdevelop and it runs seamlessly. Alternatively you can try kubuntu.
Why VirtualBox OSE - Free, Mature
It is easier to compile with MinGW on Windows than cross compile on Linux.
Build system... It could be quite easy to write Your own. Much easier than actual porting of C++ code. Could be even easier than using GNU Build System.
Please DON'T install Linux! It will take you another half a day and another questions asked here if you're doing it for the first time.
Just install VirtualBox and grab some VirtualBox image from some site. Kubuntu should be working fine with your KDE stuff: http://virtualboxes.org/images/kubuntu/
It will get you a running KDE Linux in just 5 minutes.
Newbie here. I made a project in visual studio 2010, and it works perfectly. Now i need to compile and run this code in a machine that runs ubuntu. Is there some export/import method, or how does it work (of course assuming such thing is possible).
What i am thinking is making a makefile in visual studio, then take the code and compile it in ubuntu? does such thing make sense?
Thank you in advance.
In an ideal world, the code is independent of any IDE or build chain, which keeps its own metadata saparate. Windows doesn't play nice with Linux.
On the other hand if you set up your project with CMake or something like that, then you can generate Visual Studio projects for a given code base just as easily as Linux makefiles.
You shouldn't need to change much code itself. Or, at least you should be aware of what is windows-specific. You probably will have to expend some effort in creating your CMakeList.txt or whatever you end up using, but it's pretty easy once you're familiar with it.
If you mean take Visual Studio source code and compile it on Linux: the answer is yes, though there may be anywhere from zero to a lot of work to make the code compile properly and run. It all depends on programming choices. Unfortunately, standard practice with Visual Studio generally is to use the most Microsoft-specific API features, thus greatly complicating porting to a POSIX or Linux environment. It is possible to make most non-GUI choices very portable, however a GUI intensive program is the least portable unless a cross-platform GUI API is used.
If you mean take the resulting .exe file output from Visual Studio and run that on Linux, that is usually much easier. Install the Wine package, (yum install wine or whatever the Ubuntu equivalent is) and fire up the program with wine program.exe. I have had very good luck (98+%) running Windows programs this way. The major exceptions are Microsoft software: in particular Visual Studio uses many non-standard Windows API operations, so much so that the Wine developers call VS's support level "garbage", a surprising outlier considering the number of Windows games which are well behaved and run under Wine straight out of the box.
Just today i checked my ubuntu with installing wine in it ,
Delphi 3 to 7 worked perfectly (Rad studios did not work because they use .net scraps).
But all of the application i made worked perfectly!!!!!
And i heard that it also works well in mac with WineBottler
Is it possible to create a header linux executable and put my vcl application and requird wine stuff into it and distribute as a single executable (.bin)
there is(was) a solution for Linux from Borland, called Kylix. Kylix is based on some older Qt-stuff.
But I would give FreePascal/Lazarus a try, it's pretty cool! and the compiler compiles for many different platforms.
I guess this is what winelib is for. However I have never tried it. (Wasn't Kylix Delphi + winelib compiled for Linux?)
Since Wine is now stable (reached the 1.0 version some time ago), it could make sense to ask the user to install it using its Linux packages manager. It's very fast and easy. So Wine will be always up to date, according to the distribution used.
Then it's very easy to install any Windows program with Wine.
Since Delphi executables are mostly self-contained (if you don't use the BDE or some external database libraries), your clients will install your Delphi application alla "Windows" way, that is, by running a Setup program from Wine.
And it will work fine, as is.
Using WineLib is not a good idea, even not advised by Wine developers, as far as I remember. At least for closed-source software: in one or two years, perhaps you won't release another version of your program, but Wine and WineLib will have evolved a lot... If you use Wine as an external package, your client can be sure there will be some end user enhancements.
If your software is purely Open Source, then using WineLib could make sense. But even the WineLib headers can evolved, so perhaps your source won't evolve at the same speed...