برنامهٔ نصب کیوت



  • p{direction:rtl; text-align:right}. سلام

    p{direction:rtl; text-align:right}. اکثر توسعه‌دهنده‌ها با توزیع کیوت تحت سیستم عامل ویندوز مشکل دارن. چون ویندوز خیلی خنگه و امکاناتی نظیر packaging و implicit sharing نداره، توسعه‌دهنده مجبوره تمام کتابخانه‌های مورد استفاده‌ش رو به برنامه پیوست کنه. اگر قرار باشه صد تا برنامهٔ کیوت روی یک کامپیوتر اجرا بشه، هر کدوم جزئی از یک نسخه از کیوت رو خواهد داشت. در حالی که می‌شد همه از یک نسخه استفاده کنن.

    p{direction:rtl; text-align:right}. برای حل این مشکل درنظر دارم یک اینستالر برای کتابخانه‌های کیوت تحت ویندوز بنویسم. به این ترتیب توسعه‌دهنده به‌جای پیوست فایل‌های کیوت داخل برنامهٔ خودش، می‌تونه از کاربر بخواد کیوت رو روی سیستم نصب کنه. با لاگ کردن اطلاعات در رجیستری میشه جلوی ناهمخوانی‌ها رو گرفت. مثلاً برنامه‌ای که با کیوت ۴٫۸٫۳ کامپایل شده نمی‌تونه با کیوت ۴٫۶ استفاده بشه. و یا اگر با MinGW کامپایل شده باشه نمی‌تونه به VCC لینک کنه. این اطلاعات می‌تونن در مرحلهٔ استقرار توسط برنامهٔ نصب بررسی بشن. همچنین این امکان وجود داره که روی یک ماشین نسخه‌های متعددی از کیوت مستقر بشه.

    p{direction:rtl; text-align:right}. تعطیلات عید این پروژه رو کلید می‌زنم و حدوداً یک هفته کار خواهد داشت. هرکسی خواست همکاری کنه بهم "ایمیل":mailto:soroush-r@users.sf.net کنه.



  • p{direction:rtl;text-align:right}. خوبه سروش جان. یکسری امکانات مثل downloader هم لازم داره که نسخه های جدید رو هم دانلود کنه و روی سیستم نصب کنه.
    یک سیاست توزیع هم باید براش در نظر گرفته بشه که مثلا تعداد زیادی برنامه با کاربرد های مختلف که عموما مورد استفاده هستند تولید بشه که به شکلی این توزیع روی سیستم ها نصب بشه.
    با هم هماهنگ میکنیم.



  • p{direction:rtl;text-align:right}. قضیهٔ توزیع یکمی پیچیده‌ست محسن. مثلاً کسی که برای ویندوز با ابزار گنو/متن‌باز کد می‌نویسه و داره از کیوت استفاده می‌کنه قطعاً از کتابخانه‌هایی مثل OpenSSL و یا Crypto++ به‌جای کتابخانه‌های پیش‌فرض ویندوز استفاده می‌کنه. کیوت‌هایی که برای ویندوز منتشر میشن معمولاً به شکل خاصی کانفیگ شدن که مشکلاتی رو به‌وجود میاره. مثلاً برای کتابخانه‌های jpeg و zip از فراخوانی‌های سیستمی استفاده شده که من به‌جاش از پیاده سازی‌های متن‌باز استفاده می‌کنم.

    ویندوز نسخهٔ ۶۴ بیتی نداره و خیلی چیزها هست که هنوز ۶۴ بیتی روی ویندوز ندارن. قصد دارم کل ابزارهایی رو که کیوت برپایهٔ اون‌ها ساخته شده (پیش‌نیازهای باینری و کدها) به سیستم ۶۴ بیتی پورت کنم. برای این کار یک سیاست خیلی سخت‌گیرانه درنظر گرفتم که ابزارها رو به‌شدت محدود می‌کنه و دست برنامه‌نویس رو می‌بنده.



  • p{direction:rtl;text-align:right;}. خوب openssl هم باهاش میفرستیم. اینا کانفیگ خاصی ندارن فقط مسیراشون باید تو env var قرار بگیره. الان همین mysql هم یه همچین داستانایی داره ولی خوب باید باشه دیگه!
    نسخه 64 بیتی هم با vs میشه کامپایل کرد. من این کارو کردم. کیوت 5 هم نسخه 64 بیتی داره. اینم لیستی که گذاشتن

    |Platform|Configuration|Compilers|Notes|
    |windows-7-64-msvc2010-angle|Microsoft Windows 7 64 bit, ANGLE|MSVC 2010 SP1 64-bit| |
    |windows-7-32-msvc2010-opengl|Microsoft Windows 7 32-bit, OpenGL|MSVC 2010 SP1 32-bit| |
    |windows-7-64-msvc2010-opengl|Microsoft Windows 7 64-bit, OpenGL|MSVC 2010 SP1 64-bit| |
    |windows-7-32-mingw-builds|Microsoft Windows 7 32-bit|gcc 4.7 (MinGW-builds)| |
    |windows-xp-32-msvc2008|Microsoft Windows XP SP3 32-bit|MSVC 2008 32-bit| |
    |osx-10.6-64|Apple Mac OS X 10.6 "Snow Leopard" Cocoa 64 bit|as provided| |


    "QtExperts":http://www.qte.ir?ref=9807e8ebfb97d09f0b9ac74acd2c0454



  • p{direction:rtl;text-align:right;}. دقیقاً می‌خوام همین اتفاق نیفته :| کانفیگ‌های پیش‌فرض خیلی generic هستن و زیاد جالب به نظر نمی‌رسن. طوری که خیلی از چیزها رو کلاً حذف کردن و یا گذاشتن به عهدهٔ سیستم‌عامل. این خوب نیست و باعث دردسر میشه. هدف من اینه که:

    p{direction:rtl;text-align:right;}. ۱. تمام فراخوانی‌های سیستمی برای هر پلتفرمی کاملاً native باشن.
    ۲. تمام ابزارها یکپارچه و مستقل از پلتفرم باشن. اگه قراره سیستم مبتنی‌بر گنو باشه باید OpenSSL, dbus, libz, MySQL و غیره به‌جای یوتیلیتی‌های خود ویندوز باشن.
    ۳. پشتیبانی کاملی از ۶۴بیتی‌های MinGW وجود داشته باشه. این کار سنگین خواهد بود. چون تمام موارد ۲ هم باید دوباره کامپایل بشن. کامپایل کردن و لینک کردن برنامه‌ها توی ویندوز روند خیلی دردناک و غیرمنطقی داره.

    p{direction:rtl;text-align:right;}. توی کانفیگ‌هایی که ریلیزهای رسمی دارن شرط دوم اصلاً رعایت نشده. توی ویندوز مخصوصاً همه‌چیز به‌عهدهٔ سیستم‌عامل گذاشته شده.



  • p{direction:rtl;text-align:right;}. فهمیدم چی میخوای بگی. منظورت اینه که باید کیوت رو خودمون کانفیگ و کامپایل کنیم. خوب من چیزی به غیر از این فکر نکردم. باید این اتفاق بیفته ولی کامپایل هر پلتفرم رو به یک نفر واگذار میکنیم که سنگینی کار رو دوش یک نفر نباشه.

    bq. تمام ابزارها یکپارچه و مستقل از پلتفرم باشن. اگه قراره سیستم مبتنی‌بر گنو باشه باید OpenSSL, dbus, libz, MySQL و غیره به‌جای یوتیلیتی‌های خود ویندوز باشن.

    p{direction:rtl;text-align:right;}. اینا همشون توی ویندوز هم independent هستن. DBus که کلا تو ویندوز ساپورت نمیشه. MySQL هم باید build بشه، native نمیشه استفاده کرد مگر odbc باشه که منطقی نیست. برای SSL هم کیوت فقط از openssl استفاده میکنه.

    p{direction:rtl;text-align:right;}. بهرحال همه اینا باید باشن چون قراره که پکیج کامل باشه. علاوه بر اینکه redist pack تولید میکنیم، یک installer کامل برای کیوت میشه تولید که دردسر های نصب رو نداشته باشه. همچنین لایبرری های 3rth party هم به عنوان addin بشه به installer اضافه کرد مثل opencv و cgal و این قبیل لایبرری ها که طرفدار دارن. اینا به ذهنم میرسه ولی اگه این کار انجام بشه واقعا کار با ارزشیه.

    p{direction:rtl;text-align:right;}. بنابر این تولید و serialize کردنش بیشتر از 1 هفته زمان میبره و فکر کنم همون تعطیلات عید زمان مناسبی باشه که با هم این کارو انجام بدیم.


    "QtExperts":http://www.qte.ir?ref=7a68443f5c80d181c42967cd71612af1



  • p{direction:rtl;text-align:right}. سلام
    خدا خیرت بده سروش جان
    راستش اینقد سوالای اجرای برنامه رو جواب دادم مردم :D
    ولی خودمم تو فکرم بود که اینکارو بکنم ، اما اصلا وقتشو نداشتم.
    در هر صورت ما در خدتیم واسه کمک ;)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.