2013/10/9 Renato Silva <br.renatosilva@gmail.com>



2013/10/9 Geert Janssens <geert@kobaltwit.be>

Hi,

 

I really like mingw-get as a tool to ease the installation of an mingw/msys environment.

 

I'm unfortunately having some trouble using it for an scripted build environment set up.

 

The script is supposed to install a number of packages via mingw-get the first time it's called. It selects package versions bas

ed on a configuration file. If a package version is updated in that configuration file, the next call of the script should update the relevant package(s).

 

This turns out to be very difficult to do. The command line version of mingw-get doesn't have an interface to query for installed packages. So another way has to be found to detect this.

 

In a previous question on this same list, it was suggested to parse the manifest files for this. I have tried this, but that also turns out to be pretty hard to do in a scripted environment, mostly because package names are not consistent.

 

A few examples:

- packages are names <subsystem>-name-<subcomponent>, but tarballs are names package-<some other stuff>-<subsystem>-<subcomponent>.<packagingmethod>

 

=> This means each package to install must be mangled before the tarball can be checked in the manifest file. This is still possible to work around though, if at least all packages followed the same rules.

 

- package gcc-g++ uses tarballs named gcc-c++

 

=> So to query if package gcc-g++ is installed I have to write an exception in my query code to search for gcc-c++ instead.

 

At this point I have given up for now.

 

Is there another way I can figure out which packages are installed in a scripted environment ?

 

The mingw-get gui obviously can do it, so the logic is somewhere in mingw-get. How hard would it be to expose similar information on the command line ? For example as extra info in the mingw-get list command ?

Or a separate query command ?


Hi Geert. I have a script for setting up the building environment for Pidgin under Windows. I simply don't care to check if the packages are already installed or not, I just install them [1]. If some or all of them are already installed, no harm was done. Can't you use this approach?

Otherwise, do you really need a list of installed packages? Since you know what specific packages you are interested in, you could use the list command including the subcomponent for knowing if the package is installed (you need to know which subcomponents you want too). Example:

$ mingw-get show msys-make-bin | grep -E "^(Installed|Repository) Version"
Installed Version:  make-3.81-3-msys-1.0.13-bin.tar.lzma
Repository Version: make-3.81-3-msys-1.0.13-bin.tar.lzma

When the subcomponent is not installed, installed version is none. If you still want to list all installed packages, I have another script which you may use as inspiration [2]. It searches for packages with a provided name, returning an indexed list of matches. You can then pass that index for having mingw-get showing information about the package. Example:

$ packages ssl
  1 msys-libopenssl
  2 msys-openssl

$ packages ssl 1 | head -5
Package: msys-libopenssl                                 Subsystem: msys
Components: dev, dll
    dev  is installed: libopenssl-1.0.0-1-msys-1.0.13-dev.tar.lzma
    dll  is installed: libopenssl-1.0.0-1-msys-1.0.13-dll-100.tar.lzma

The scripts injects the installed or not information above into the output of mingw-get show/list. This turned out to be quite slow, which is fine for my interactive use, but not for your automation purpose. I'm telling this cause, in theory, you could do something like this:

$ for i in {1..2}; do packages . $i | grep -E '^(Package| {4})'; done
Package: mingw-developer-toolkit                         Subsystem: msys
    bin  is not installed
Package: mingw32-autoconf                             Subsystem: mingw32
    bin  is not installed
    lic  is not installed
 
Which for all of the 186 existing packages is really really slow. But you could take a look at the code and maybe it helps for something. However, I do think it's better to just install like I said above, less problems than it needs.


 


 

Geert


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
MinGW-users@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@lists.sourceforge.net?subject=unsubscribe