We are using the Ant Zip task, which is a bit obsolete (low processing speed for big files).
Can anyone point me to a mature Ant task, ready for production use, that supports multithreaded compression/decompression?
First of all I wish to increase speed of processing archive files.
I found 7ZIP Ant task, but it looks abandoned, and it doesn't support multithreaded.
Why not use the exec task with the command line version of 7zip?
Zip/Jar tasks work well because Java (hence ant) have support for them built in (not sure about the tar support). Built in-support would require 7zip written in Java or at least included in some ant task. It is very easy to write Ant taks. Write you own and shell out to a 7zip/pbzip/etc. If you're REALLY enterprising, give this a shot ... a LZMA library from 7zip w/ Java support
7-zip downloads, CLI versions too
To decrease external dependencies, just bundle a version of the cli compression tool you want to use.
I believe many of the executables (7zip specifically) have cli versions for multiple platform.
Related
I have an application that gets built under MinGW. I have my source code under Git, but I ought to have my build environment under proper configuration management too, so that if I need to repeat a build from 6 months ago I can do it with the same versions of the compiler, libraries etc.
Is there any way of doing this? I've read up on "repeatable" builds, but that seems to be about running the build twice with the same versions of everything and getting a bitwise identical output, which is necessary for certain security properties. My problem is how to restore the version of MinGW files that I had at some point in the past.
The crude and primitive way would be to just archive a snapshot of C:\mingw every time I use pacman. But I'm hoping for something a bit smarter.
The standalone builds of MinGW-w64 from http://winlibs.com/, which can build for both Windows 32-bit and 64-bit, have no installation procedure. Just extract the download and you have a working build environment.
This even allows you to even have multiple versions of MinGW-w64 side by side.
Just make sure no other installed MinGW (like the one in C:\mingw) is in your PATH so the different versions don't get accidentally mixed up.
I installed (extracted) msysgit portable (PortableGit-1.9.5-preview20150319.7z)
The compressed archive is 23 MB, but once extracted the contents take up 262 MB. This is mostly due to the git command binaries (under 'libexec\git-core'). Almost all of the binaries are identical, they just have different names.
Why did the developers build the project like this? I suppose they need an executable for each command to support the CLI on windows cmd.exe.
But isn't there a way to avoid having ~100 identical binaries, each 1.5 MB in size (ex: using batch files)?
Why did the developers build the project like this? I suppose they
need an executable for each command to support the CLI on windows
cmd.exe.
Under unixoid OSes, you can have symbolic links to another file that behave exactly like the original file; if you do that for your executable, your executable can look into argv[0] to find out how it was called. That's a very common trick for many programs.
Under Windows, and especially without installers, it's (to my knowledge) impossible to get the same behaviour out of your file system -- there's just no symbolic link equivalent. Especially when you consider that programs that are meant to run from USB drives have to cope with ancient filesystems such as FAT32!
Thus, the executables simply were copied over. Same functionality, more storage. However, on a modern machine that you'd run windows on, you really don't care about 200MB give or take for such a versatile tool such as git.
In conclusion: the developers had no choice here; since windows (though having some posix abstraction layer) has no proper filesystem support for symbolic links, that was the only good way to port this unix-originating program. You either shouldn't care or use an OS that behaves better in that respect. I'd recommend the latter, but OS choices often aren't made freely...
I am writing a script that pulls files from my development folders and would like to generate an installer with those files.
I would like to if there is a way to create MSI installers using command line.
Yes there is a way. The very flexible Windows Installer XML Toolset. A pretty good tutorial on how to use it is this link
The toolset is here
I think you need to define "create". If you mean "build" or "compile" then yes, pretty much every MSI authoring tool out there supports some form of automated build ... usually even MSBuild support.
If you mean "author" and "build" it's technically possible but not usually advised. Installation is too complicated to be auto magically developed.
I had developed a small program in netbeans using c++. I need to know how can i deploy/run the package on another linux system
Abdul Khaliq
I have seen your code, you probably missing XML files in the current folder... where the executable is located... paste then and then run as ./your-executable
I recommend that you use a makefile to recompile on your target machine which will ensure that your program is deployed properly.
You should use a makefile as suggested. I know that NetBeans can generate one, but it's been a while since I last did so. Maybe this can help: http://forums.netbeans.org/topic3071.html
Typically, once compiled, your executable will need several libraries. Chance is that those libraries will also be available on the target linux system.
Thus, you can simply copy your executable over to the other system. If you run ldd on your executable, you should see the list of libraries your executable is dynamically loading. Those libraries should be available on the target system as well.
In case your executable makes use of resources such as images and other binary files, you can use a resource system (e.g. Qt Resource System) and compile those binary files into your executable.
The easiest way to test is to do the copy, run
ldd yourExecutable
on the target system. It will tell you if you are missing any library. Install those libraries using the system package manager.
Of course, you also have the option to statically build all libraries into your executable. However, this is not recommended since it makes the executable too large and complicates matters.
What type of package is your netbeans compiler creating? deb,rpm? If you are moving the package to a different linux install you will need to use that distributions package type. Ubuntu - deb
Fedora/Redhat - rpm
etc...
I'm not sure how you change this in netbeans but I'm pretty sure it has the ability to. A google search could help you more.
When deploying an extension I follow various steps : copy to a temporary folder all the files, copy/paste back and forth the code to the on-line minifiers / obfuscators and create the zip to be uploaded.
It's obvious that this could be simplified with scripting, but my experience on Windows scripting is very limited (most of my experience is server-side). Do I have to look back to the DOS .bat files like in the 90's or is there some cool tool or method I'm not aware?
Besides something like Ant, PHP is great for CLI scripting, even on Windows. Tons of built-in functions, including .zip creation, and thorough docs.
IMO you'd be better off learning PHP (or Python, or anything else) than batch scripting.
I am using Apache Ant for builds. Maybe an overkill, but you can automate everything - minification (with 3rd party java libs), archiving, automatic license header insertion after minification.
I you are not familiar with Ant (or java) then it will be probably hard to jump right into it.
PS. Here is my open souce extension that uses Ant for builds, you can check it out (it copies files into a build folder, minifies, archives)