增量編譯和

㈠ 絕對編程和增量編程有何不同

樓主指的是增量編譯吧，就是只編譯修改過的文件，根據文件的時間判斷。這樣在工程很大時可以節省編譯時間，不用在修改一個文件後重新編譯所有的文件。

㈡ powerbuilder9如何編譯程序

首先選擇「project」在彈出的對話框中選擇『new』（新建一個編譯程序的目錄），選定要編譯的程序，在彈出的界面的第一個框中選擇編譯的路徑（就是生成可執行文件的保存路徑），選擇變異類型（全編譯和增量編譯，全編譯慢，但是很完整，增量編譯只對之前編譯過的程序的修改部分進行編譯很快，但不一定完整），選擇相應的PBL，單擊「builde」，就開始編譯了

㈢ vs2010下C# WinForm 解決方案裡面生成的文件都是什麼作用干什麼的

Bin 目錄用來存放編譯的結果，bin是二進制binrary的英文縮寫，因為最初C編譯的程序文件都是二進制文件，它有Debug和Release兩個版本，分別對應的文件夾為bin/Debug和bin/Release，這個文件夾是默認的輸出路徑，我們可以通過：項目屬性—>配置屬性—>輸出路徑來修改。
obj是object的縮寫，用於存放編譯過程中生成的中間臨時文件。其中都有debug和release兩個子目錄，分別對應調試版本和發行版本，在.NET中，編譯是分模塊進行的，編譯整個完成後會合並為一個.DLL或.EXE保存到bin目錄下。因為每次編譯時默認都是採用增量編譯，即只重新編譯改變了的模塊，obj保存每個模塊的編譯結果，用來加快編譯速度。是否採用增量編譯，可以通過：項目屬性—>配置屬性—>高級—>增量編譯來設置。
Properties文件夾 定義你程序集的屬性 項目屬性文件夾 一般只有一個 AssemblyInfo.cs 類文件，用於保存程序集的信息，如名稱，版本等，這些信息一般與項目屬性面板中的數據對應，不需要手動編寫。
.cs 類文件。源代碼都寫在這里，主要就看這里的代碼。
.resx 資源文件，一些資源存放在這里，一般不需要看。
.csproj C#項目文件，用VS打開這個文件就可以直接打開這個項目，自動生成，不需要看。
.csproj.user 是一個配置文件，自動生成的，會記錄項目生成路徑、項目啟動程序等信息。也不需要看。
.Designer.cs 設計文件，自動生成，不需要看。
.aspx 是網頁文件，HTML代碼寫在這裡面。
sln:在開發環境中使用的解決方案文件。它將一個或多個項目的所有元素組織到單個的解決方案中。此文件存儲在父項目目錄中.解決方案文件，他是一個或多個.proj（項目）的集合
*.sln：(Visual Studio.Solution) 通過為環境提供對項目、項目項和解決方案項在磁碟上位置的引用,可將它們組織到解決方案中。
比如是生成Debug模式,還是Release模式,是通用CPU還是專用的等
編譯和運行直接按F5，至於調試按F9插入斷電，F10整行執行，F5，F9，F10配合使用
整個項目後綴文件的說明！

㈣ Compile，Make和Build的區別

Compile，Make和Build的區別具體如下：
1、compile 英 [kəmˈpaɪl] 美 [kəmˈpaɪl]
vt.編譯;編制;匯編;編輯
例句：
The book took 10 years to compile
編這本書花了10年時間。
2、make英 [meɪk] 美 [mek]
vt.做，製造;生產，制定;使成為;使產生
vi.開始;嘗試;行進;增大
n.製造;生產量;性格;形狀，樣式
例句：
Mary made as if to protest, then hesitated
瑪麗好像要抗議，卻又猶豫了。
3、build英 [bɪld] 美 [bɪld]
vt.建立;建造，構築;開發;為…建立基礎
vi.建造，營造;擴大，擴展;發展，達到
n.體格，構造;〈俚〉優美的體型，肉體美
例句：
We will then have a firmer foundation of fact on which to build theories
那樣我們將會獲得一個建立理論所需的更為牢固的事實基礎。

㈤ Intellij idea為什麼沒有增量編譯和自動編譯

用 JRebel 插件吧，debug的時候改幾行代碼make一下就熱更新了，非常爽，不足的是不支持新增類，新增方法。
想想可以邊調試邊修改，就應該把持不住了吧～

㈥ 從 Webpack 到 Snowpack, 編譯速度提升十倍以上——TRPG Engine遷移小記

原文地址: http://moonrailgun.com/posts/74598ef5/

TRPG Engine 經過長久以來的迭代，項目已經顯得非常臃腫了。數分鍾的全量編譯, 每次按下保存都會觸發一次 10s 到 1m 不等的增量編譯讓我苦不堪言, 龐大的依賴使其每一次編譯都會涉及很多文件和很多包，長時的編譯時間大大降低了開發效率與迭代速度。

經過一段時間的考察，我選擇了 Snowpack 作為解決方案。與 Webpack 不同的是，除了第一次的全量編譯以外， Snowpack 的增量編譯不會涉及到龐大的 node_moles 文件夾, 准確來說只會編譯變更文件本身。甚至於如果沒有對依賴進行變更，下次的全量編譯會直接動用之前編譯的文件緩存，不需要花時間等待 node_moles 的編譯。

為什麼會這么快？這是由於 Snowpack 本身的實現與設計哲學有關的。相比 Webpack , Snowpack 利用了現代瀏覽器的本身的 mole 系統，跳過復雜的模型之間的組織編譯過程而只關注於變更文件本身的編譯，這樣當然快了。

拿 Snowpack 官方的一張圖來說:

snowpack 的最我譯單位是文件，而 webpack 的最我譯單位為 chunk , 而 chunk 還需要額外的計算, 不論是編譯部分還是編譯後的組裝部分。snowpack的設計邏輯天生決定了她的速度。

優化前(使用 webpack ):

全量編譯:

增量編譯:

全量請求用時:

優化後(使用 snowpack ):

全量編譯:

增量編譯:

(看不到編譯用時，但是體感在1s內. 而且該效果在電腦運行其他應用時更加顯著)

全量請求用時:

以上測試是保證電腦在空閑時間，且保存與操作內容為同一文件

該用時已經是平時操作的最快時間，為此我的MBR重啟了一次強制清空了swap空間, 實際表現會更加顯著

因為文件依賴於瀏覽器的耗時，而瀏覽器需要串列請求依賴，因此耗時會更加長

但實際使用中使用snowpack會更加優秀。因為其相比webpack會大大節約電腦資源。在webpack編譯時會佔用大量的電腦資源，會影響到其他操作

TRPG Engine 算是非常經典的 Webpack 應用了, 使用了各種Loader。光通用配置就有250+行，各種優化配置，各種 alias。等等長時間迭代積攢下來的配置，因此毫不意外的會遇到很多問題與坑。

以下是我遇到的問題與解決方案:

Snowpack雖然作為一個新興的打包工具，目前尚不是非常完善, 功能也沒有webpack這樣豐富與齊全。但是它的新的打包設計對於有一定規模的前端應用還是非常優秀的。能極大提升開發效率。不失為一種好的解決方案。當然最後輸出還是需要使用webpack對其進行一定的優化，畢竟原生的mole支持目前瀏覽器的支持度還沒有達到覆蓋一個理想的地步 https://caniuse.com/es6-mole

最後這是我最後提交的 pr

㈦ C#項目中的bin目錄和obj目錄的區別

項目中bin目錄和obj目錄區別宏派瞎如下：
1）bin目錄下存放編譯結果。根據項目中設置不同，在這個目錄下又分別有兩個文件夾Debug和Release，分別存放Debug設置編譯結果羨沖和Release編譯結果。
2）obj文件夾存放編譯中間結果。蔽空編譯中間結果用作「增量編譯」。所謂「增量編譯」是一種高效編譯方法：當你執行一次編譯時，只編譯被你修改的源代碼部分，沒有修改的則不編譯。編譯中間結果就是用來跟蹤哪些源代碼被修改、哪些源代碼沒有改變。

㈧ 20分(不知道者勿擾)－－什麼是增量編譯

只需編譯被改變的代碼以及依賴於被改變代碼的代碼，可以加快編譯的速度。
對於一個大的系統來說編譯一次是要消耗很長時間的。

㈨ PowerBuilder命令行編譯詳解[1]

公司的系統是使用PB + SQLServer 開發的 採用Visual Source safe 進行版本控制 由於項目客戶化需求的影響 系統經常要進行更新和編譯 每次的工作流程就是 先在負責編譯的機器上打開VSS 下載需要更新的PBL到本地 然後找到源程序所在目錄 將目錄及其所有子文件的 只讀 屬性去掉（因為在VSS上Get Last Version時會自動將文件設置成只讀 PB就無法編譯了） 接著打開PB開神並始編譯 編譯完成後 由於各個PBL是按模塊放在不同的目錄中的 所以生成的PBD也不在一個文件夾中 這時我游談跡還需要通過搜索的形式找出所有PBD來復制到發布目錄 這樣的重復性工作干幾次就讓人煩了 最終我考慮通過批處理的形式來減少重復勞動

首先 VSS的GetLastVersion現在我是找不到可以批處理的方法的 去除只讀屬性也可以在命令行模式下用Attrib命令來解決 對於已生成的PBD復制到同一目錄 我寫了一個批處理文件 專門把那些固定模塊目錄下的PBD復制到發布目錄 無非是一些Copy命令而已 沒什麼可說的 問題的關鍵就在於 要控制PB自動打開程序 編譯 完成後自動進入打開負責復制PBD的批處理文件 早些時間由於抽不出空 也沒用過PB的命令行模式 所以一直遲遲沒寫好這個文件 現在經過摸索侍虧 結合CSDN上一些大俠們的指導 終於試驗成功 現寫出其過程供各位斧正

對於命令行編譯 PB的幫助中是這樣描述的

From a mand line

When you deploy or build a workspace from a mand line PowerBuilder starts pletes the build and exits as soon as the operation is pleted To retain a log file for the session you can send the contents of the Output window to a file Table shows mand line options for building and deploying targets and workspaces

As with other mand line options you need only use the initial letter or letters of the option name as long as the option is uniquely identified The deploy fullbuild and incrementalbuild options can be used only with the workspace option You need to create projects and specify build and deploy options for the workspace in PowerBuilder before you start a build from the mand line Deploy builds the projects in the target in the order listed on the Deploy page of the target s properties dialog box

Example

This example assumes that the location of the PowerBuilder executable file is in your system path It opens the workspace called CDShop builds and deploys the targets in the workspace according to your specifications in the workspace and target properties records the content of the Output window in the file D:/tmp/cdshop out and exits PowerBuilder:

pb /w D:/CDShop/CDShop pbw /d /ou D:/tmp/cdshop out

其實上文說了一堆 意思無非就是 我們可以在命令行模式下執行PB 通過一些參數 可以控制PB自己編譯指定的工作區 然後自動退出 這也確實是我需要的功能 我馬上開始在命令行模式下測試 有的機器並不能直接打PB exe來執行 這需要設置系統的環境變數 將PB 所在目錄放入Path路徑中 具體方法就不介紹了 或者你直接按PB 完整的路徑輸入也行 至於後面的參數 /w後面掛指定的工作區名稱 然後是//deploy或者/fullbuild /incrementalbuild 這三個參數的意思分別是執行發布 完全編譯或增量編譯 任選其一即可 但是需要注意的是 這里我們要用/deploy參數 為什麼呢 如果你用的是fullbuild或者是increamentbuild參數 PB只會 編譯 而不會生成PBD或者DLL 以前自己在PB中進行編譯的時候 一直以為Deploy就是Build 因為在Deploy Project的時候會有一個參數是完全編譯或者增量編譯 所以一直搞不清楚Deploy和Build的區別 在網上見其它兄弟也有這樣的疑問 這次我通過試驗 發現確實二者是有區別的 如果你不用Deploy而直接Build完了 復制到用戶那裡程序還是舊的就不好辦了 那麼我們掛上參數後 PB怎麼知道是執行哪一個Project的Deploy呢 設置如下

在工作區下的子結點是Target 右鍵單擊該Target 在彈出的菜單中選擇Proterties 也就是屬性 並在彈出的屬性窗口中選擇Deploy頁 如下圖

㈩ gcc編譯鏈接文件耗時

GCC 編譯鏈接文件耗時可能受多種因素影響，以下是一些可能的原因和解決方法：

大規模代碼庫：如果您的代碼庫很殲蔽大，例如包含大量源文件、頭文件和庫文件，那神改森么編譯鏈接時需要的時間就會更長。您可以考慮使用增量編譯，只編譯發生更改的文件，以縮短編譯鏈接時間。

編譯器選項：某些編譯器選項可能會影響編譯鏈接的時間。例如，啟用優化選項可能會使編譯鏈接時間更長。您可以嘗試調整編譯器選項來優化編譯鏈接時間。例如，可以使用 -O0 選項關閉優化。但是，請注意，關閉優化可能會影響代碼的性能和效率。

硬體配置：編譯鏈接時間也可能受到硬體配置的影響。如果您的計算機配置較低，例如 CPU、內存和硬碟空間較小，那麼編譯鏈接時間可能會更長。您可以嘗試升級硬游畝件配置，例如增加內存和更換更快的硬碟。

多線程編譯：GCC 支持多線程編譯，可以同時編譯多個源文件，從而加快編譯鏈接時間。您可以使用 -j 選項指定要使用的線程數。例如，使用 -j4 選項將使用 4 個線程編譯鏈接。

使用預編譯頭文件：如果您的代碼庫包含大量公共頭文件，可以使用預編譯頭文件來加快編譯鏈接時間。預編譯頭文件包含公共頭文件的預編譯版本，可以在編譯鏈接時重用，從而減少編譯鏈接時間。
總之，GCC 編譯鏈接時間受多種因素影響，您可以嘗試使用上述方法來優化編譯鏈接時間。