通常,當我們開發Linux程序時有兩種方案:
雖然我自己是在Linux環境上直接進行開發的,但也有許多的人是在Windows環境上從事開發工作的,如果離開自己熟悉的系統到陌生的環境上也許會影響到工作效率。
因此今天我們就來看下如何在Windows上使用Visual Studio 2019進行Linux遠程開發以及如何避免常見的陷阱。
Visual Studio的跨平臺開發功能簡介
從Visual Studio 2017開始微軟推出了VS的跨平臺開發功能,你可以在VS中編輯代碼,隨後進行跨平臺編譯和遠程調試,將原先我們需要手動完成的工作進行了自動化,大幅減輕了我們的負擔。其中支持的平臺包括Android和Linux,也就是我們今天要重點介紹的主角。
也許你會好奇,VS究竟是怎樣進行遠程開發的,雖然你不用了解這些知識也可以進行開發,但我還是希望能用兩分鐘做個簡短的解釋。
VS進行遠程開發分為兩步:
經過上述步驟之後你就可以在vs裡調試自己編寫的跨平臺程序了。
使用 VS 2019進行Linux遠程開發
簡介到此結束了,下面我們來看看在VS 2019進行Linux開發的圖文教程。在我們開始之前,首先要做點準備工作:
做好準備後我們就該進入正題了。
創建項目
安裝好C++ for Linux功能後我們會在創建新項目的面板中看到Linux的選項,如圖:
這裡我們選擇了使用傳統的vs項目解決方案構建的空白控制臺程序,後續的文章中你還可以看到如何創建cmake項目,這裡暫且不提。
下面沒什麼要說的,選擇項目的存儲位置,注意是本地的位置,遠程機器的位置在後面會進行配置:
點擊創建,我們的遠程開發項目就創建成功了。
配置遠程項目
VS不能編輯空項目的配置,所以我們先在項目中創建一個main.cpp,然後點擊頂部菜單:項目->屬性,你就能看到項目的配置界面了:
遠程計算機是在調試中的遠程連接管理器中添加的。這裡一般不需要改動,除非你需要改變項目的類型或編譯結果的存放位置。如果有多個遠程環境時,也可以在這裡進行選擇。
調試部分提供了gdb和gdbserver,前者是讓VS在Linux上啟動一個console,然後在其中運行gdb並返回輸出,如果你的Linux上的終端配置了彩色輸出,那麼和遺憾vs並不認識他們,會顯示成原始的字符串;
使用gdbserver時會在遠程啟用gdbserver 本地VS解析回傳的數據不會出現雜音。
這裡我們選擇了gdbserver,如果你發現無法打斷點,那麼參考微軟的建議,換回gdb方案:
接著是配置的重點,首先是配置需要同步的遠程環境的頭文件,有了這些文件vs才能對你的代碼進行自動補全和提示:
默認複製的路徑通常已經包含了Linux上大部分的頭文件,通常我們也不需要做更改。頭文件的同步發生在***次構建項目成功後或添加遠程連接後手動同步。
接著是C/C++編譯器的選擇,也就是對gcc和g++編譯參數的配置,講解這些參數超出了我們的討論範圍,我們這裡只需要選擇合適的C++標準版本:
這裡我們選擇了c++17。其他設置與在Windows上進行開發時一樣,vs可以自動轉換成g++的參數,這裡就不再贅述。
添加遠程環境
有了遠程環境我們才能同步頭文件或者進行調試運行。
在***次編譯或調試你的項目時vs會自動讓你連接遠程環境,當然,我們推薦在調試->選項->跨平臺->連接管理器中進行設置:
填入你的遠程ip/域名,埠ssh默認為22,安全起見你需要修改成其他埠,這裡方便演示使用了默認配置,密碼同上,你應該考慮使用更安全的ssh私鑰登錄。
登錄成功後這個連接就添加完成了,我們看到管理器下面還有一個遠程標頭管理器的設置項,這就是用來同步頭文件的:
點擊更新按鈕就會開始同步頭文件,這些文件會被緩存在本地,因為要從遠程一次性複製大量文件,所以可能會花費較長的時間。
這樣遠程環境就添加好了,可以開始寫代碼了。
本地編寫和遠程調試
至此你已經可以在VS中編寫面向Linux平臺的代碼了,自動補全可以正常工作:
可以看到Linux中的頭文件和結構體都已經可以識別了。如果你發現無法自動補全(通常發生在剛添加遠程連接或是項目設置發生了變化後),先試試關閉vs重新打開,如果沒用請嘗試刷新intellisense或重新同步頭文件。
在編輯結束後我們就能點擊調試按鈕運行我們的程序了:
注意,構建的體系架構必須是和遠程環境一致的,比如遠程環境是x64,這裡可以選擇x64或x86,但是不能選擇arm,否則會報錯。
這是測試代碼,它將輸出當前Linux系統內核的版本:
點擊調試->Linux 控制臺,會顯示一個可以交互的console,你可以在其中輸入內容或是看到程序的輸出:
程序運行成功。
避免踩坑
遠程編譯順利完成後,我們就可以接著利用vs debugger設置斷點,在斷點處查看變量,甚至對運行中的Linux進行動態性能分析了。
不過在此之前,還有一些坑需要提前踩掉。
中文亂碼
編碼問題帶來的麻煩永遠會被放在***位,畢竟當人們看到預想的輸出實際上是一堆亂碼時總會不可避免得緊張起來。
眾所周知,編碼問題一直是老大難,特別是Windows上中文環境通常是GB18030或GBK,而Linux上統一為utf8時。
下面看個實際例子,通常我們的程序裡只包含ASCII字符的話不容易產生問題,所以我們加上一點中文字符:
對於上面的測試程序,我們添加了一點中文輸出信息,現在打開控制臺進行調試:
可以看到中文輸出變成了亂碼,我們輸入一些信息進去,這是運行結果:
可以看到,程序內寫入的中文發生了亂碼,而我們的輸入沒有。原因很簡單,輸入時實在linux的控制臺環境下,編碼默認是utf8的,所以我們的輸入被正確編碼,而源文件中的內容是GB18030的,所以在Linux控制臺(默認以utf8解碼數據並顯示)中會發生亂碼。
錯誤的原因知道了解決起來也就很簡單了,把源文件的編碼改成utf8就行,我們選擇最簡單的方法,在高級保存選項中修改編碼(這個菜單選項默認被隱藏,網上有很多介紹如何顯示它的方法的資料):
設置好後保存文件,現在文件的編碼已經被改為了utf8了。
現在運行修改後的程序:
運行結果也是正常的:
使用數學函數和第三方庫
在Linux上使用標準庫提供的數學函數也是一個老生常談的問題,根據你使用cpp還是C會有如下幾個情況:
使用cpp時,libstdc++依賴於libm,所以使用g++編譯你的程序時會自動連結數學函數庫;
使用c時,如果是sqrt(4)這樣的形式,較新的gcc提供了替換措施,不需要顯示連結libm;
接上一條,如果你的參數是個變量,那麼編譯器可能會選擇需要你連結libm。
通常在Windows上我們無需操心這點,但在Linux上使用c語言時就很難忽略這個問題了。
因此保險起見,如果你正在編寫一個使用了數學函數的c程序,那麼總是指定連接libm是沒錯的。(具體可以參考http://www.linuxforums.org/forum/programming-scripting/125526-c-gcc-math-h-lm.html)
另外當你使用例如boost這類第三方庫時,也需要注意。在Windows上我們通常指定好附加包含目錄和附加庫目錄即可正常編譯,但是Linux上必須明確指定連結庫的名字,因此我們在項目屬性中進行設置。
在Linux上我們可以使用pkg-config來減輕上述的重複勞動,而在vs中我們不能直接利用這一工具,當你的項目使用了大量第三方庫時就會成為不小的麻煩,如果想要解決這一問題,可以參考後續文章裡我會介紹的vs+cmake構建項目。
下面我們給例子加上一點boost chrono的功能測試,在Linux上需要指定-lboost_chrono,這是設置:
下面是完整的代碼:
點擊運行按鈕,程序就能正常調試了,否則會報錯:
【編輯推薦】
【責任編輯:
武曉燕TEL:(010)68476606】