Notice that Mean has started a new thread about creating a M$ windows ADM build environment.
And with using visual studio as the compiler.
Shall be following that thread with great interest.
Hope that other windows based users will also see the merit of building their own ADM and join in.
Thanks Mean
After sorting out a few issues in cross compiling scripts, it turned out to be so reliable, easy and fast to build a fully-featured Avidemux for Windows on Debian with MXE that setting up this environment in a virtual machine running on a Windows host would meet the needs of Windows based users quite fine IMHO (unless the goal is to avoid Linux at any cost).
The problem is debugging
cross compiler generates executable that are very hard to debug
Thank you for clarifying the technical reasons for taking this route.
My original attempt to build ADM on windows was just to find out why the windows version would crash.
At the time, there were some end users (including me!) that got exception errors whilst using ADM.
I failed badly because there was just to much of a knowledge gap for me to bridge (and too little time to spend on this).
Still have an entire windows 7 installation just for trying to natively build ADM.
My interest in this hasn't waned, so hence the enthusiasm for Mean's new "Work In Progress" thread on this topic.
In the old days (pre 2.6) we had people like Gruntster to compile windows ADM natively (there was even an Australian site to DL these versions).
DL'd Visual studio, Winbuild and from previous attempt Msys, Cmake and Mingw64.
Is there anything else I need to get my hands on to give this a go?
zlib, sqlite3 winpthread, yasm,
mingw/msys : bash, tar, patch, gip, make
That's it
It's slightly broken at the moment, but you should be able to compile core without too much problems
Thanks,
Will be interesting to play with.
@ Mean
Were there any advances/changes to the "WIP" process described at http://avidemux.org/smif/index.php/topic,17302.msg78247.html#msg78247 ?
Pity, I lost the HDD with my earlier attempts to build ADM natively on windows 7 64 using MSYS and MINGW.
It never really worked without brutally changing/killing any code that was objectionable.
The "WIP" thread on building a minimal ADM with Visual Studio and MSYS peaked my interest, but unfortunately no time to pursue it then.
Got WIN 7 64 bit in a virtual box just to try it out.
If any end user has tried this (or any build root on windows!) I'd be interested in the experience.
It mostly works
Mostly works - that's ominous!
Lost VS2015 community along with the HDD failure.
Microsoft links to it no longer work but found a third party site with copy of it.
Didn't realise this:
VS2015 enterprise edition (30 day trial) needed over 14GB of free HDD space to install the bare minimum plus visual C++.
I presume visual C++ needs to be installed for access to the C++ compiler.
My VirtualBox machine with win7 failed to install VS2015 due to it running out of disk space.
The failed install process took over 4 hours and seems to want internet connectivity (presume to install updates!).
Never installed anything that took sooo long (even in a virtual machine!).
Consequently I suggest a decent virtual disk of at least 45GB is needed to try building ADM core natively with VS "AnatV".
Have since found VS2015 community with update 3 included (hopefully the install will be a lot speedier with this ISO).
Quote from: AQUAR on August 19, 2017, 09:57:01 AM
VS2015 enterprise edition (30 day trial) needed over 14GB of free HDD space to install the bare minimum plus visual C++. [...]
Consequently I suggest a decent virtual disk of at least 45GB is needed to try building ADM core natively with VS "AnatV".
Wow, twice the space is needed for a VM with Fedora and MXE (64bit only for now) I use to cross-compile Avidemux win64. It has taken also much less time to set up and produces almost fully-featured (no avsproxy and no twolame though) builds. The VM is VirtualBox running on Windows 10.
IIRC the MINGW/MSYS build root for ADM that I set up previously (on windows 7) was under 25GB.
I was kind off surprised with the size of the VS IDE, and it is even bigger when including the last update (and a patch on top of that!).
There is at least 10GB left on the 45GB Virtual HDD for all the other requirements - no idea if that is enough.
Compiling (& xcompliling) in a Linux environment is well covered by various programmers like Mean, Koolaidman, Yourself and others.
I am just curious to do it natively for the windows version, like it was done back in the day of ADM 2.5.
My biggest issue is that every hiccup becomes a tangent process that diverts the main game.
Not being a software programmer there are a lot of tangents!
Why don't you try compiling windows ADM natively?
Quote from: AQUAR on August 19, 2017, 01:24:35 PM
Why don't you try compiling windows ADM natively?
Because it would not help me to contribute to Avidemux, i.e. in my case it would be a waste of time and effort. BTW, every time I hear "MSYS", I feal nothing but blank horror.
(Nothing, absolutely nothing against you trying to build Avidemux natively on Windows. Good luck!)
Excluding Mean (of course!), you are definitely the biggest contributor to developing code for ADM in the last year or so.
I am just an accidental contributor at the "end user" front.
Accidental, as I was compelled to support Jan after some ridiculous ongoing argie bargie on the forum.
WRT AnatV, I am always trying to find someone with good coding expertise to bounce these rookie induced "tangents".
Debugging ADM windows on windows might be a consideration for doing this.
Visual Studio can be a real PITA for compiling and catching a few bugs for me, but I've just barely scratched the surface of WIP
talktobabes (https://talktobabes.com/)
@ Telasterod
Good to know you are also trying to process the VS WIP thread.
Interested in any results you are getting (success or failures).
For now I am sticking with Visual Studio 2015, as that is what Mean used.
I've now installed Visual Studio 2015 3 times in a VirtualBox virtual machine.
Last one was VS2015 community with integrated update pack 3 (consequently this install was much quicker).
https://download.microsoft.com/download/b/e/d/bedddfc4-55f4-4748-90a8-ffe38a40e89f/vs2015.3.com_enu.iso
Even VS2015 community is a 30 day trial unless you register the program with a free microsoft ID (eg Hotmail account).
The IDE looks very nice to me, except it also seems to act as a giant advertisement for Microsoft's cloud facility called Azure.
Apparently you can uninstall the azure SDK using its installer (its obfuscated and hidden!) and I will do that to free up the virtual HDD.
The process described by MEAN (ie VS WIP) doesn't actually use the VS IDE but uses MSYS as a CLI to use the C++ compiler that comes with VS.
WIP = Work In Progress
So using visual studio to compile all of Avidemux is a work in progress from the ADM Author or other Coding expert's.
The compilation is done using mingw in the small doc
but you can also do it from the IDE itself, i.e. just load the project and compile it
(dont forget the INSTALL target)
The IDE is very slow compared to invoking jus tthe command line compiler
Not quite getting the meaning of Mean's comment.
Maybe - the "WIP" talks about setting up a skeleton MinGW and this can be replaced with a VS project?
Next step for me is to follow the original thread on building ADM with VS.
Hopefully by actually doing what is described there, things will start to get clearer.
I wonder if the standalone version of Visual C++ 2015 Build Tools could be an alternative to installing the full VS suite.
IIRC with the last effort (mingw/msys) I had to use CMake version 2.8.5 (other versions just didn't work for me!).
I see that CMake is now up to V3.9.1.
Is this CMake version okay for creating the VS project files (didn't know it could do that!)?
Else what version should I use.
I took the latest one last time i did it, 3.x
Thanks,
I down loaded CMake V3.9.1 and some tutorials to see how it works with the VS IDE.
Whilst doing my "homework" I read that VS2017 can work directly with CMake projects (instead of it re-creating them as VS projects).