Přechod na MSVC 2015

13.2.2016 23:47 | Přečteno: 1885× | flame

A komu tím prospějete, co? Druhé straně?! Aneb Zhruba tak nějak by se daly shrnout mé pocity z akce "přechod na MSVC 2015" u Windows buildů GPXSee.

Vše začalo tím, že už mě začal unavovat bug v MSVC 2010, které jsem do té doby používal. Při překladu s "-O2" vytváři MSVC 2010 grafické artefakty ve widgetu grafu a tak po každém běhu qmake musela následovat úprava vygenerovaného Makefile, nehledě na ne zcela optimální výsledek při kompilaci s "-O1" (což je v podání MSVC optimalizace nikoliv na rychlost běhu, ale na velikost binárky). A když už měnit překladač, tak za to nejnovější, co existuje, to dá přece rozum. Nebo ne?

Pro ty co nikdy neměli tu čest s vývojem pro Windows je to asi překvapení, ale v "holém" systému není (nebyl) žádný ekvivalent libc natož libstdc++, vše se musí dotáhnout s aplikací ať už ve formě jednotlivých knihoven přiložených k aplikaci ("hnusné" ale funkční a efektivní řešení), nebo jako tzv. "VS redistributables", které tyto knihovny, vždy pro jednotlivou verzi MSVC, nainstalují globálně do systému.

Důvod, proč preferovat nehezké řešení s "vykuchanejma" knihovnama a ne systémové "redistributables" je ten, že "redistributables" mají ~13 MB, zatímco potřebné C/C++ knihovny jen lehce přes 1 MB. Pokuď tedy chcete distribuovat jakoukoliv malou aplikaci, může to klidně znamenat zvětšit její instalátor o řád! A i v případě běžné Qt aplikace, kde Qt knihovny zaberou ~6 MB je to nárůst na víc jak dvojnásobek.

S příchodem MSVC 2015 se Microsoft pokusil stávající stav vylepšit a fakticky přejít na Linux-like systém, kde je libc vždy součástí systému. Bohužel to s čím přišel je typické Microsoft řešení, které funguje jenom napůl a jenom občas. Nové systémy totiž běhové prostředí (již neverzované podle MSVC) obsahují, ty starší ale obecně nikoliv. Například na Windows 7 záleží na tom, je-li nainstalován update KB2999226, který je označen ale pouze jako volitelný a tak ho půlka instalací Windows 7 nemá. Navíc jde pouze o ekvivalent libc, libstdc++ (msvcpXXX.dll) je stále v režii VS..

Snad proto, že Microsoft tušil, že s takovým polo-řešením spoustu lidí neodradí od toho, přibalovat lokální C/C++ runtime spolu s aplikací, tuto možnost raději zcela zatrhl. Po vlně kritiky (znemožňuje to totiž vyrobit aplikace, které nevyžadují pro instalaci elevaci) to snad zase s prvním service packem VS 2015 umožnil, mě se ale nicméně ty knihovny separovat nepodařilo. Nebo přesněji podařilo, ale (minimálně) na Windows XP z nějakého záhadného důvodu neprojde DllMain() u api-ms-win-core-* knihoven.

Nezbylo tedy než kapitulovat a přibalit "redistributables". Součásně pak přejít u GPXSee na "globální" instalaci do "Program files". Jak to vše v instalátoru (v mém případě NSIS) správně udělat by vydalo na samostatný článek, ale jak se říká: "zdrojový kód lepší než tisíc slov".

Pokud nejste Linus a nemůžete si tak dovolit psát programy podle hesla "Testing"? What's that? If it compiles, it is good; if it boots up, it is perfect.", budete se pravděpodobně snažit nový instalátor nějak otestovat. Vyzkoušet všechny systémy od Windows XP po Windows 10 už dneska v době virtuálů není nereálné, jenže kde je vzít a nekrást? A co takhle třeba přímo u Microsoftu? Jo, časy se mění...

       

Komentáře

[Petr Tomášek]

Že ti ty widle za to stojí...

[Martin Tůma]

Je to suverénně nejpoužívanější desktop OS. Můžu s tím nesouhlasit, můžu proti tomu protestovat, ale to je asi tak všechno co s tím můžu dělat.

A mezi náma - ono vyrobit RPM/DEB balíčky je úplně stejná pakárna...

[randy]

Mas tam chybu :) Vyrobit DEB baliky je pakaren, ale co je na RPM (hlavne ked sa pozriem na tvoj .spec) zloziteho?

[Martin Tůma]

Třeba to, že spec pro SUSE nefunguje pro RHEL a vice versa. K tomu vyrábět oboje je potřeba nastudovat nějakou magii, k čemuž jsem se ještě ani nedostal...

[randy]

To je jasne, kedze nazvy balikov v distribuciach su trosku ine. Malo by stacit tam dat len podmineky pre BuildRequires a hotovo, no neskusal som.

[pavlix]

Tak ani RPM pro Fedoru automaticky nefunguje pro RHEL, ale dá se v případě potřeby napsat s podmínkami.

[podlesh]

Zajímavé. Moje zkušenosti jsou přesně opačné. Zrovna v minulém roce jsem se zase trochu výrobě balíčků věnoval a nadával jsem jak špaček (u RPM samozřejmě ; výroba DEB byla vyloženě oddychovka).

[pavlix]

Mně se na RPM spec líbí, že tam člověk píše víceméně jen to, co je potřeba, kdyžto Deb je snad potřeba nejdřív vygenerovat a pak do toho vepisovat.

[podlesh]

Jako obsah toho balíčku? To je právě postavené na hlavu - pokud už obsah mám připravený, tak musím do spec psát script který to kopíruje z místa na místo. Dává to smysl pokud skutečně začínám od zdrojáků a do specfile dám celý postup buildu, ale přijde mi lepší debianí koncept kde toto je jen nadstavba nad jednoduchými nástroji pro výrobu balíčku (kterou tedy můžu nebo nemusím použít).

kdyžto Deb je snad potřeba nejdřív vygenerovat a pak do toho vepisovat.

... a nebo jsem možná vůbec nepochopil co je míněno. Možná se jedná o ten soubor s metadaty? To mi ale nedává smysl, protože je to přesně naopak - rpm specfile je obludný soubor do kterého se musí vyplnit spoustu různých věciček, zatímco pro deb balík mi stačí jediný soubor s dvojicemi klíč:hodnota

Package: blablaplus
Version: 9.0.2
Maintainer: Kamil Podlesak <bla@bla.bla>
Depends: java8-jdk | java8-sdk, python, debconf (>= 0.5) | debconf-2.0, adduser (>= 3.48), dpkg (>= 1.8.3)
Description: bla bla bla

[podlesh]

Jeden typický příklad, když už se to nakouslo:

Nevíte někdo jako se oficiálně mají dávat python scripty (.py) do rpm noarch balíčků? Míněno aby mi rpmbuild nevynadal, že tam jsou architekture-specific binárky (pyc). Binárky které tam samozřejmě původně nebyly! Vážně, já drogy nepašuju, to mi tm museli podstrčit!!!!

PS: ty fígle s __arch_install_post a __os_install_post, schované někde hluboko v útrobách mailing listů.... ale pořád nemůžu pochopit proč to není normálně zdokumentované.

[smazáno]

Podstrcili! A me taky, IIRC jsem to resil explicitnim smazanim tech .pyc souboru.

[podlesh]

Abych jenom nenadával, tak tady je řešení většiny redhat/centos výpečků:

%define __jar_repack %{nil}
%define __arch_install_post    %{nil}
%define __os_install_post      %{___build_post}
%define _binaries_in_noarch_packages_terminate_build 0

Třeba se to bude někomu hodit

[marbu]

Jo, mám dojem, že rpmbuild vytvoří pro všechny .py sourbory .pyc binárky a přidá je do balíčku. Pokud tohle selže (např. při chybě v syntaxi), tak selže celý build.

[skunkOS]

Maj rozdílný jména balíků. Očekuj si na OBS můj projekt, třeba rssguard-qt5.

[Honz]

Je to suverénně nejpoužívanější desktop OS.

Strašně zvláštní formulizace...

[pavlix]

Legální vývojářská virtuálka Windows použitelná v qemu/kvm by mě docela zajímala. Budu rád, když se podělíš o zkušenosti. Co bych si měl vlastně stáhnout?

[Martin Tůma]

?! A ten link si zkoušel? Jsou to normální virtuály pro Virtualbox. Od Windows XP po Windows 10 volně k použití pro nekomerční účely. Jediný omezení je, že fungujou pouze 90 dní, ale sám Microsoft radí, že si máš udělat snapshoty.

[pavlix]

Tam to nabízí samé cílené na testování webů. Nemají někde něco ideálně na vývoj v céčku?

[Martin Tůma]

Doinstalovat tam Visual Studio jde jako do normální instalace Windows. Hlavní přínos těch virtuálů vidím ale právě v možnosti vyzkoušet výsledný produkt na celém spektru verzí Windows. Pro vývoj bych tak nějak očekával že člověk ty Windows stejně bude mít. Kor když koupit bez nich dneska počítač není zrovna běžný.

Jó kdyby takhle poskytl Apple OS X to by byla jiná, tam už si dovedu představit, že kupovat si kvůli kompilaci (Qt) programu nový počítač se asi moc lidem nechce... Jenomže takhle Apple money machine nefunguje

[pavlix]

Doinstalovat tam Visual Studio jde jako do normální instalace Windows.

Tak pokud je Visual Studio volně ke stažení a užívání, tak proč ne. I když pak úplně nechápu, proč ho rovnou nedají k dispozici ve formě virtuálky.

Kor když koupit bez nich dneska počítač není zrovna běžný.

Pro mě teda není spíše běžné kupovat počítač s Windows.

Jó kdyby takhle poskytl Apple OS X to by byla jiná, tam už si dovedu představit, že kupovat si kvůli kompilaci (Qt) programu nový počítač se asi moc lidem nechce...

Mně se nechce kupovat dedikovaný počítač ani kvůli pár nekomerčním experimentům na Windows.

[Martin Tůma]

Tak pokud je Visual Studio volně ke stažení a užívání, tak proč ne.

Volně k dispozici (a to IMHO i pro komerční využití) je nejenom kompilátor, ale i velé Visual Studio v Express edici.

I když pak úplně nechápu, proč ho rovnou nedají k dispozici ve formě virtuálky.

Měl jsem dojem, že taky děláš v korporaci, takže víš, že pokládat si otázky proč korporace něco dělá/nedělá je zcela zbytečné...

Mně se nechce kupovat dedikovaný počítač ani kvůli pár nekomerčním experimentům na Windows.

Na Windows dedikovaný HW nepotřebuješ, na OS X ano - virtualizovat OS X na PC je dle Applu nelegální.

[pavlix]

Visual Studio v Express edici.

Tak to asi někdy zkusím. Ale kdyby tohle někdo dával za rozumnou cenu v cloudu, kdy bych platil jen za dobu, kdy to skutečně běží, asi bych neváhal a ušetřil bych si práci.

Měl jsem dojem, že taky děláš v korporaci, takže víš, že pokládat si otázky proč korporace něco dělá/nedělá je zcela zbytečné...

Nevím. Co dělá můj zaměstnavatel řeším jen to té míry, do které se to týká mojí práce.

Na Windows dedikovaný HW nepotřebuješ

Nepotřebuju, ale zdálo se mi, že říkáš, že bych ho mít měl.

na OS X ano - virtualizovat OS X na PC je dle Applu nelegální.

Jenom na osobním počítači? Jinak je to ok?

[Pavel Stárek]

Asi je lepší Visual Studio Community Edition https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx. Umí jednak vývoj pro Windows a rovněž tak pro Android, iOS, Python atd.

[skunkOS]

Proč nepoužíváte vlastně CMake, kterej ty NSIS generuje nádherně?

[Martin Tůma]

Protože je to další (zbytečná) závislost. QMake je pro build zcela vyhovující a NSIS bych potřeboval tak jako tak, tak proč do toho tahat ještě další mezivrstvu?

Co se týče možnosti použít CMake/Cpack na všechny platformy, tak pro Linux se člověk stejně nevyhne nastudování různejch proměnnejch, který jsou v zásadě ekvivalentem DEB/RPM konfiguráků, takže nějaká úspora je zanedbatelná. Navíc si nejsem jistej, jestli třeba OBS, který používám CPack podporuje. No a na OS X je výroba DMG triviální a hlavní "blocker" je stejně nutnost mít k dispozici Maca...

[skunkOS]

Nerozumím té vazbě Cmake & OBS. Mě to normálně funguje. Cpack se vůbec nijak nepoužívá. Alespoň já ho v OBS nijak nevolám nebo tak.

[Martin Tůma]

No právě, takže si stejně musíš napsat spec/debian soubory. Kde je potom ta výhoda?

[tom]

Proc to nekompilujes pres mingw v linuxu jako statickou binarku?

[Martin Tůma]

Obecně mi přijde hnusný mít binárky zbytečně veliký, když můžou používat sdílený knihovny. Mingw taky potřebuje svůj vlastní runtime, takže tady si člověk nevybere, ale obecně je mnohem víc věcí kompilovanejch pomocí VS, takže šance, že se ušetří na sdílenejch knihovnách je větší (i když nyní s asi už 6 runtime verzema, který se běžně používaj je to taky otázka...). Teoreticky se dá i to QT sdílet, ale to moc lidí nainstalovaný nemá. Což ale neznamená, že jim člověk nemůže dát tu šanci.

[tom]

Vzdycky mi prislo, ze u windows je zbytecny se o to snazit, protoze si skoro vsechny aplikace stejne tahaji svoje verze knihoven, takze pak to vlastne neni s kym sdilet. Navic se pri statickem linkovani muze usetrit misto tim, ze se odhodi nepotrebna cast QT.