Mudroom v0.2.0: นักพัฒนาแชร์เบื้องหลังพอร์ต Swift CLI สู่ Windows
เจาะลึกปัญหาและวิธีแก้เมื่อนำ Mudroom เครื่องมือรัน AI agent สู่ Windows ทั้ง Clang 19, DLLs 15 ตัว และบั๊กซ็อกเก็ต
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Mudroom v0.2.0 เพิ่มเวอร์ชัน Windows รองรับ x64 และ arm64 ใช้ Docker หรือ Podman เป็นแซนด์บ็อกซ์
- เจออุปสรรคคอมไพเลอร์เพราะ Swift 6.2 ใช้ Clang 19 ชนกับ Visual Studio 2026 C++ headers
- ไฟล์ซิปรุ่นรีลีสมีขนาดประมาณ 29 MB บรรจุ DLLs จำเป็น 15 ตัวเนื่องจาก Windows SDK ไม่มีสแตติกไลบรารี
- ปัญหาเครือข่าย ซ็อกเก็ต และ PowerShell ถูกแก้ไขเพื่อให้ระบบบน Windows ทำงานเสถียร
Mudroom เครื่องมือที่ช่วยรัน coding agents เช่น Claude Code, Codex หรือ Gemini CLI ภายในลินุกซ์คอนเทนเนอร์บนสำเนาโปรเจกต์ของคุณ เพื่อให้คุณตรวจทานการเปลี่ยนแปลงก่อนแตะต้องไฟล์จริง โดยเริ่มต้นจากการเป็นแอปพลิเคชันสำหรับ Mac และในเวอร์ชัน 0.2.0 นี้ได้เพิ่มการรองรับการสร้างบน Windows สำหรับสถาปัตยกรรม x64 และ arm64 โดยใช้ Docker Desktop หรือ Podman เป็นแซนด์บ็อกซ์
การพัฒนา Swift บน Windows ทำงานได้ดีกว่าที่คาดการณ์ไว้ โดยโค้ดส่วนใหญ่สามารถคอมไพล์ได้ทันทีหลังจากแยกส่วนที่เฉพาะเจาะจงกับแพลตฟอร์มออก แต่สิ่งที่ต้องใช้เวลาคือองค์ประกอบรอบตัวคอมไพเลอร์ ไม่ว่าจะเป็นการลิงก์ ซ็อกเก็ต ระบบไฟล์ PowerShell และ CI ซึ่งมีรายละเอียดปัญหาที่เกิดขึ้นสำหรับผู้ที่ต้องการทำตามแนวทางเดียวกัน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การสร้างบิวด์แรกเกิดความล้มเหลวก่อนที่จะคอมไพล์ไฟล์ Swift แม้แต่ไฟล์เดียว เนื่องจาก Swift 6.2 มาพร้อมกับ Clang 19 ขณะที่ Visual Studio 2026 C++ headers บน GitHub ของ Windows runners ปฏิเสธการทำงานร่วมกับเวอร์ชันที่เก่ากว่า Clang 20 ทีมงานจึงต้องใช้แฟล็กข้อยกเว้นในทุกคำสั่งบิวด์ของ Windows บน CI และในคู่มือ README สำหรับผู้ที่ต้องการคอมไพล์จากซอร์สโค้ด
บนลินุกซ์คุณสามารถใช้คำสั่งเพื่อรวมเป็นไบนารีเดียวได้ แต่บน Windows การทำเช่นนั้นไฟล์ .exe ยังคงต้องเรียกใช้ swiftCore.dll และไฟล์อื่นๆ เนื่องจาก Windows SDK ไม่มีไลบรารีสแตติกของ Swift ทำให้ไฟล์ซิปรุ่นรีลีสมีขนาดราว 29 MB และสคริปต์การแพ็กเกจจะใช้การรันคำสั่งตรวจสอบไฟล์พึ่งพาจนครบ 15 DLLs บนทั้งสองสถาปัตยกรรม
การพอร์ตภาษาโปรแกรมสมัยใหม่ไปยัง Windows มักพบความท้าทายเรื่องเครื่องมือรอบข้าง (Toolchain) เสมอ แม้ตัวภาษาหลักจะข้ามแพลตฟอร์มได้ดี แต่การจัดการไลบรารีแบบไดนามิก การจัดการข้อผิดพลาดของเครือข่ายระหว่าง Winsock กับ C runtime รวมถึงพฤติกรรมเฉพาะตัวของ PowerShell ถือเป็นบทเรียนสำคัญสำหรับนักพัฒนาซอฟต์แวร์ที่ต้องการขยายฐานผู้ใช้ไปยังระบบปฏิบัติการอื่น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในด้านเครือข่าย บน macOS และ Linux ซ็อกเก็ตคือตัวอธิบายไฟล์ที่ปิดได้ด้วยฟังก์ชันปกติ แต่บน Windows ซ็อกเก็ตคือแฮนดิล SOCKET จาก Winsock ซึ่งทำให้กระบวนการแครชหากส่งไปยังฟังก์ชันปิดของ C runtime นอกจากนี้ พร็อกซีเครือข่ายของ Mudroom ยังถูกปรับปรุงการจัดการการเชื่อมต่อเกินขีดจำกัด โดยทำการปิดฝั่งส่งแล้วอ่านคำสั่งที่เหลือค้างไว้เป็นเวลาสูงสุด 250 มิลลิวินาที เพื่อให้ไคลเอนต์ได้รับรหัสข้อผิดพลาด 503 ท่ามกลางสถานการณ์ที่การเชื่อมต่อถูกตัด
สำหรับการจัดการสถานะเซสชันและการใช้คำสั่งผ่าน PowerShell ทีมงานได้แก้ไขปัญหาการขัดแย้งในการเข้าถึงไฟล์โดยเพิ่มการหน่วงเวลาและลองใหม่ รวมถึงการส่งผ่านอาร์กิวเมนต์ในรูปแบบอาร์เรย์เพื่อป้องกันไม่ให้เครื่องหมาย -- ถูกตัดทอนโดย PowerShell พร้อมทั้งเปิดใช้งานคอนเทนเนอร์บน GitHub runners ผ่านระบบเนสต์เวอร์ชวลไลเซชันสำเร็จ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น