Composer/Vagrant like tools for C++/Java/.NET

[roosevelt]

Hi,

 

I have been programming in couple of languages lately Java, C++, PHP, Python, and even .NET on Windows. Among them I noticed that Java and .NET applications are very close to being portable. The end user will just have to install Java or the .NET framework and run the executable and the application just works.

 

But when it come to deploying applications for Mac or Linux, things gets a little bit tricky with C++/PHP/Python. Ideally Java would be the way to go but it also has some limitations. Because a Control that is already done and available in .NET may have to be created from scratch on a Python/Java app. So, even though I love to program in Python, I end up choosing .NET because it is already done. But it leads to a situation where I leave out a great number of Mac/Linux users.

 

C++ is the ideal solution for making Cross Platform applications but static linking and library dependencies gets ugly real quick. And frankly end users don't like installing Qt or updating their environment variables, etc... because they just don't have the knowledge or perhaps the courage to do so. So, what I am after is a universal solution... that might achieve the following:

• Cross Platform Solution
• Depending on the User's OS it automatically installs the required libraries in one shot

Some of the solutions that really mimics this behavior are Vagrant or Composer for PHP. The script reads the dependency definitions and grabs everything so when you execute the application everything is already present.I don't see anything like that for desktop development. I would love to have a solution where upon executing a script it automatically installs Qt5, WxPython, Python, whatever my application needs.

 

InstallShield, etc... would be overkill... any open-source alternatives?

[snaphat (Myles Landwehr) Member]

Personally, I have never seen anything that simplifies this process (though, I think you probably could have guessed as much from our previous discussion on pyinstaller). I really don't think there is anything that will make cross-platformness uniform and easy, I think you will just have to continue to do the annoying leg work. I mean even something like cmake (cross platform make ;-) ) for a build system isn't great at being cross-platform -- you have to do the leg work to account for platform differences there also.

[Krome]

Skimming through your post, it is hard to decide if you are more interested in Web Applications or Desktop Applications.  You are talking about a mixed developing tools for both and yet you want the compilation to be crossed platform.  Very confusing to me. :)

[roosevelt]

  On 11/02/2014 at 01:41, Krome said:

Skimming through your post, it is hard to decide if you are more interested in Web Applications or Desktop Applications.  You are talking about a mixed developing tools for both and yet you want the compilation to be crossed platform.  Very confusing to me. :)

 

haha, for the most part I am looking for a solution for Desktop Applications. To give you an example, I will install Python on my computer, and install the WxPython module to develop my desktop gui app. Now the end user will download my compiled python app with a script that has all the dependencies listed (e.g. Python, WxPython). So, if the end user does not have Python or WxPython, running that script would install Python and WxPython for him. The catch is... the script that he will run has to be compatible to his particular OS (e.g. .sh/.bat, etc...).

 

I can create a script of my own to take care of that but I was wondering if such package manager already exists? Because it seems like it is a very common practice to include a script that takes care of all the dependencies. I was using Vagrant and PHP Composer as an example.

[Andre S. Veteran]

A Python application can be compiled to a stand-alone executable, for instance with cx_Freeze or PyInstaller. You don't need to run a script that downloads dependencies if you bundle them with your package.

[snaphat (Myles Landwehr) Member]

^This has dependency issues though (glibc versioning incompatibilities being the large one) so it doesn't work great in practice

[roosevelt]

  On 11/02/2014 at 17:14, snaphat (Myles Landwehr) said:

^This has dependency issues though (glibc versioning incompatibilities being the large one) so it doesn't work great in practice

 

See this is exactly what I am talking about. You'd think Pyinstaller or any other program of that nature would make deploying applications on the user's computer easier. But there is no way of knowing beforehand what libraries it may depend on, what version or even where to get them. But if we had a repository similar to Vagrant or PHP Composer, overtime developers could add a link to all the dependencies and package them together if needed.

 

I ran into couple of situations where some of my clients never even heard of Python, let alone their system will have them installed. Or they start shaking if you tell them to launch the Terminal/Command Prompt. I am not talking about exclusively about Python but I ran into this situation with C++ libraries, Ruby on Rails and PHP as well. But with a dependency manager you are only worried about configuring a single item and the dependency manager would grab rest of the libraries in one shot. But without a dependency manager you are on your own to configure glibs, c++ libraries, python, wxpython or whatever libraries the application uses.

 

Basically I want a solution where the guy who is installing or running my desktop application is a regular joe and not a computer wiz of any kind :p... think grandma!

[snaphat (Myles Landwehr) Member]

^ And these are the types of clients that are liable to have the really old OSes where the glibc interfaces indeed change from the ones you are using on your own development systems  :wacko:

 

This is one example where Windows DLL hell can be somewhat better in practice than Linux for library dependencies (sadly). You can't reliably distribute glibc or the other system runtime libraries because of system call differences between different versions of the Linux kernel. So dropping glibc 2.6 on an older system using 2.4 system isn't going to work (at least, it didn't work when my twin tried it). This is one thing that I rather dislike about Linux.

[Andre S. Veteran]

  On 11/02/2014 at 17:14, snaphat (Myles Landwehr) said:

^This has dependency issues though (glibc versioning incompatibilities being the large one) so it doesn't work great in practice

Why not bundle your version of glibc then? (perhaps dumb question)

[snaphat (Myles Landwehr) Member]

  On 12/02/2014 at 17:57, Andre S. said:

Why not bundle your version of glibc then? (perhaps dumb question)

See my last post: there are issues even with that because of syscall changes as one moves forward the Linux kernel revisions (because glib invokes syscalls directly): Here's a list of ABI changes between kernel revisions: http://man7.org/linux/man-pages/man2/syscalls.2.html. What's interesting is something else I didn't know, even if you compile the newer glib versions to target an older kernel, they aren't guaranteed to provide all functionality: https://gitlab.com/bminor/glibc/raw/e6ff5e32b8374ca1adb5f93b3ad81681d195ea55/README (they broke thread support with older kernels).

 

I neglected to mention in my previous post that glib itself also has other library dependencies you need to bundle with it so it's not as simple for bundling purposes as just tarring a single .so. That being said, I do imagine that bundling works fine in cases where you aren't moving between systems with large gaps in kernel revisions.