Derleme komut dosyalarının avantajları nelerdir?


97

Programlama kariyerimin çoğunda, çalıştırılabilir bir program oluşturmak için birlikte çalıştığım IDE'de "build / compile / run" komutunu kullandım. Bu tek tuş, oldukça kolay. Farklı diller ve çerçeveler hakkında daha fazla şey öğrendiğim halde, bir projenin yürütülmesini sağlamak için "derleme komut dosyaları" (ANT, Maven, Gradle, vb.) Hakkında daha fazla konuşma görüyorum. Bunları anlamam, yapılandırma detaylarını belirten derleyici / linker / büyülü-program-yapıcıya talimatlar olduğudur - minutiae.

Makefilo'ları okula geri yazdığımı hatırlıyorum, fakat o zaman özel bir avantaj görmedim (bunları yalnızca kullanışlı "derleme" düğmesine sahip bir IDE'nin bulunmadığı bir Unix terminalinde yazarken kullandık). Bunun ötesinde, burada, betiğin programlarınızı oluşturmaktan daha fazlasını nasıl yapabileceğini tartışan başka sorular gördüm - ana makineden bağımsız olarak birim testlerini ve güvenli kaynakları çalıştırabilirler .

İnşa etme komut dosyaları geliştirici olarak anlamak için önemli olduğu hissini sallayamıyorum, ancak anlamlı bir açıklama istiyorum; neden derleme komut dosyaları kullanmalı / yazmalıyım?

Build Script ve Build Server'ın sorumlulukları daha geniş bir kapsamda oynadığı rolü tartışır. Bir derleme betiği tarafından bir IDE'nin "derleme / çalıştırma" komutuna veya benzer şekilde basit yöntemlere göre sunulan belirli avantajları arıyorum.


18
Buradaki cevaplar her şeyi oldukça iyi bir şekilde ele aldı, ancak IDE'nizdeki "run" düğmesine tıkladığınızda, IDE'nizin oluşturduğu bir derleme betiğini (neredeyse değişmez şekilde) yürüttüğünü söylemek istedim. Kendi derleme betiğinizi yazmanız işlem üzerinde daha fazla denetim sahibi olmanızı sağlar.
Woodrow Barlow

6
Kendi derleme betiğinizi yazıp paylaşmanız, başka biri farklı bir IDE kullanıyor olsa bile, herkesin işleminizle aynı olan bir işlemle oluşturabileceği anlamına gelir. bu tutarlılık ile yardımcı olur.
Woodrow Barlow


1
Derleme komut dosyaları genellikle important to understand as a developerher zaman olmasa da , sık sık . Derleme komut dosyalarının pratik gereksinimler olduğu ortamlarda bile, birçok "geliştirici" en ufak bir şekilde onları umursamaz. Ancak senaryolar daha sonra geliştiriciler için değil, “inşaatçılar” için önemlidir. En son çalıştığım yerler, çoğu geliştiricinin komut dosyaları oluşturmak için neredeyse sıfır bağlantısı vardı.
user2338816

3
"build" tuşu ile IDE kullanan herkes değil
Vladimir Starkov

Yanıtlar:


112

Otomasyon.

Geliştirme aşamasında, yalnızca en basit projelerde varsayılan "derleme" düğmesi yapmanız gereken her şeyi yapar; WS’ler dışında API’ler oluşturmanız, belgeler oluşturmanız, dış kaynaklarla bağlantı kurmanız, değişiklikleri bir sunucuya dağıtmanız vb. yapmanız gerekebilir. derleme betiğinizi IDE ürünleri aracılığıyla oluşturabilirsiniz.

Ancak bir sistem geliştirmek sadece kod yazmak değildir. Dahil olan birçok adım var. Bir IDE bağımsız komut dosyası otomatik olarak çalıştırılabilir, bu şu anlama gelir:

  • Sürüm kontrolünde bir değişiklik yaptığınızda, sunucu tarafından otomatik olarak yeni bir derleme başlatılabilir. Yapım için gereken hiçbir şeyi yapmayı unutmadığınızdan emin olacaktır.

  • Benzer şekilde, derleme tamamlandıktan sonra, bir şeyleri kırıp kırmadığınızı görmek için testler otomatik olarak çalıştırılabilir.

  • Şimdi kuruluşun geri kalanı (QA, sysadmins) inşa edilmiş bir ürün var.

    a) sadece kontrol versiyonundan kusursuz bir şekilde yeniden üretilebilir.

    b) hepsi için ortaktır.

Tek kişilik bir takım olarak çalışırken bile senaryolar kullandım; Düzeltmeyi geliştirdiğimde, SVN’yi taahhüt edeceğim, SVN’yi başka bir dizine geri aktarın ve çözümü oluşturmak için derleme betiğini kullanın; bu daha sonra Hazırlık sistemlerine ve daha sonra Üretim’e gider. Birkaç hafta sonra (yerel kod tabanım zaten değiştiyse) birisi bir hatadan şikâyet ettiğinde, sistemi düzgün şekilde hata ayıklamak için hangi SVN revizyonunu kontrol edeceğimi tam olarak bilirdim.


4
Bu en iyi cevap IMHO. Herkes kendi fikri ile haklı, ama bu gerçekten neden senaryolar oluşturmak istediğinizi gösteriyor. Çünkü siz genişledikçe ilerleyen otomasyonu destekliyorlar, size zaman kazandıracak.
Alexus

16
@Alexus Sadece zaman değil, aptal hatalar da. ;) "Tekrarlama can sıkıntısına neden olur. Can sıkıntısı dehşet verici hatalara yol açar. Dehşet verici hatalar 'Keşke hala sıkıldım.' "(Zamanla aptal hataları da ölçebilirsin, ama bunun birkaç nedenden dolayı zaman kazandırdığını fark etmek önemlidir.)
jpmc26

@ jpmc26 orada olmak - D
Alexus

2
Tek kişilik projeler için bile, "ayrı bir dizinde derleme" işlemini otomatikleştirmek için yerel bir Jenkins sunucusu çalıştırmak yardımcı olabilir. Windows altında çapraz derlemelerin de onaylanmasına ihtiyaç duyduğum bir şey üzerinde çalışıyorum, bu nedenle Jenkins'in testler yapması ve testler yapması, ardından çapraz derlenmiş sürümü oluşturması gerektiğinde beni daha güvenli (ve verimli, elbette!) Yapar hata düzeltmeleri yayınlayın.
Ken YN,

4
@ JonasGröger Otomasyon en büyük değişkenlerden birini seçiyor: insanlar.
CurtisHx

34

Kod gibi, bir derleme betiği bilgisayar tarafından yürütülür. Bilgisayarlar bir dizi talimatı takip etmede son derece iyidir . Aslında, (kendi kendini değiştiren kodun dışında), bilgisayarlar aynı komut dizisini, aynı girdi verildiğinde tamamen aynı şekilde yürütürler. Bu, yalnızca bir bilgisayarın eşleştirebileceği bir tutarlılık düzeyi sağlar.

Buna karşılık, su dolu et torbaları bize aşağıdaki adımlara gelince aşağılık düşüyorlar. Bu sinir bozucu analitik beynin karşılaştığı her şeyi sorgulamaya meyillidir. "Ah ... Buna ihtiyacım yok" ya da "Bu bayrağı gerçekten kullanmalı mıyım? Eh ... Sadece görmezden geleceğim." Ayrıca şikayet alma eğilimimiz var. Birkaç kez bir şey yaptıktan sonra, talimatları bildiğimize ve talimat sayfasına bakmanıza gerek olmadığına inanmaya başlarız.

"Pragmatik Programcı" dan:

Ayrıca, projede tutarlılığı ve tekrarlanabilirliği sağlamak istiyoruz. Manuel prosedürler değişime kadar tutarlılık bırakır; Tekrarlanabilirlik, özellikle prosedürün farklı kişilerin yorumlarına açık olması durumunda garanti edilmez.

Ayrıca, talimatların yerine getirilmesinde HILARIOUSLY oldukça durgun (bir bilgisayarla karşılaştırıldığında). Büyük bir projede, yüzlerce dosya ve yapılandırma ile, bir derleme sürecindeki tüm adımları manuel olarak yürütmek yıllar alacaktır.

Size gerçek bir dünya örneği vereceğim. Kodun çoğunun birkaç farklı donanım platformunda paylaşıldığı bazı gömülü yazılımlar üzerinde çalışıyordum. Her platform farklı bir donanıma sahipti, ancak yazılımın çoğu aynıydı. Ancak her donanıma özgü küçük parçalar vardı. İdeal olarak, ortak parçalar bir kütüphaneye yerleştirilir ve her versiyona bağlanır. Ancak, ortak eserler ortak bir kütüphanede derlenemedi. Her farklı konfigürasyonda derlenmesi gerekiyordu.

İlk başta, her yapılandırmayı el ile derledim. Konfigürasyonlar arasında geçiş yapmak sadece birkaç saniye sürdü ve bu büyük bir acı değildi. Projenin sonuna doğru, bir cihazın esas olarak iletişim veriyolunu devralacağı kodun paylaşılan bölümünde kritik bir hata bulundu. Bu kötüdü! Gerçekten kötü. Hata kodunu buldum, düzelttim ve her sürümü yeniden derledim. Biri hariç. İnşa işlemi sırasında dikkatim dağıldı ve birini unuttum. İkili dosyalar serbest bırakıldı, makine yapıldı ve bir gün sonra makinenin yanıt vermeyi bıraktığını söyleyen bir telefon aldım. Kontrol ettim ve bir cihazın otobüsü kilitlediğini keşfettim. "Ama ben bu hatayı düzelttim!"

Düzeltmiş olabilirim, ama o bir tahtaya asla yolunu bulamadı. Neden? Çünkü her tıklama ile 1 tıklama ile otomatikleştirilmiş bir oluşturma işlemim olmadı.


2
Senaryoyu çalıştırırken kahve içebilirsin!
Peter Mortensen

15

Yapmak istediğiniz tek şeyse <compiler> **/*.<extension>, derleme komut dosyaları çok az amaca hizmet eder (bir Makefileprojede bir tane görürseniz onu birlikte yapabileceğinizi söyleyebiliriz make). Önemli olan - önemsiz olmayan projeler genellikle bundan fazlasını gerektirir - en azından, genellikle kitaplıklar eklemeniz ve (proje olgunlaştıkça) derleme parametrelerini yapılandırmanız gerekir.

IDE'ler genellikle en azından konfigüre edilebilir - ancak şimdi derleme işlemi IDE'ye özgü seçeneklere dayanıyor. Eclipse kullanıyorsanız , Alice NetBeans'ı tercih ediyor ve Bob IntelliJ IDEA'yı kullanmak istiyorsa, yapılandırmayı paylaşamazsınız ve biriniz kaynak kontrolünde bir değişiklik yaptığında, IDE tarafından oluşturulan yapılandırmayı el ile düzenlemeleri gerekir. diğer geliştiricilerin dosyalarını, veya diğer geliştiricilere bildirerek kendi başlarına yapacaklarını söyler (bu, IDE yapılandırmasının bazı IDE'ler için yanlış olduğu durumlarda taahhütte bulunacağı anlamına gelir ...).

Ayrıca, ekibin kullandığı IDE'lerin her birinde ve her birinde bu değişikliğin nasıl yapılacağını bulmanız gerekiyor ve eğer bir tanesi bu özel ortamı desteklemiyorsa ...

Şimdi, bu sorun kültüre bağlıdır - geliştiricileriniz IDE seçimi yapmamayı kabul edilebilir bulabilir. Ancak bir IDE ile deneyime sahip olan geliştiriciler, kullandıklarında genellikle hem daha mutlu hem de daha verimlidirler ve metin editörü kullanıcıları, en sevdikleri araçlar konusunda dini olarak gayret gösterme eğilimindedir, bu nedenle geliştiricilere özgürlük vermek istediğiniz yerlerden biridir. - ve derleme sistemleri bunu yapmanıza izin verir. Bazı insanlar sistem kurma tercihine sahip olabilir, ancak IDE / editör tercihleri ​​kadar fanatik değil.

Tüm geliştiricilerin aynı IDE'yi kullanmalarını sağlasanız bile - derleme sunucusunu kullanmaya ikna etmede iyi şanslar ...

Şimdi, bu basit inşa süreci özelleştirmeleri için, IDE'lerin güzel GUI sağlama eğilimi göstermesidir. Daha karmaşık şeyler istiyorsanız - derlemeden önce ön işleme / otomatik üretim kaynak dosyaları gibi - genellikle IDE'nin yapılandırmasının içindeki bazı temel metin alanlarına bir derleme öncesi komut dosyası yazmanız gerekir. Hangi yapı sistemlerini hala bu bölümü kodlamak zorunda kalacaksınız, ancak kodu yazdığınız asıl editörde yapabilirsiniz ve daha da önemlisi: yapı sisteminin çerçevesi genellikle bu komut dosyalarını düzenlemek için destek sağlar.

Son olarak - inşa sistemleri, projeyi oluşturmaktan daha fazlası için iyidir - ekipteki herkesin gerçekleştirmesi gerekebilecek diğer işleri yapmak için programlayabilirsiniz. Örneğin Ruby on Rails'de , veritabanı geçişlerini yürütmek, geçici dosyaları temizlemek vb. İçin derleme sistemi görevleri vardır. Bu görevleri derleme sistemine koymak, ekipteki herkesin bunları tutarlı bir şekilde yapabilmesini sağlar.


2
Bu sadece farklı IDE'lerin meselesi değil. Bazı geliştiriciler her türlü IDE'den nefret eder ve nefret eder.
David Hammen

2
@DavidHammen Ben bu geliştiricilerden biriyim (Vim'imi o kadar zor bir şekilde IDE'ye çevirmiş olabileceğimi mümkün olsa da ...) ve bu paragrafı yazarken otomatik olarak "editörler" yazıyordum ve IDE’ye sabitleyin, çünkü IDE’ler üzerindeki fikstür cevabımın önemli bir parçası. Soru sahibi açıkça IDE dünyasından geliyor ve soru IDE'siz geliştirme hakkında konuşuyor; uygun IDE olmadığında yapmak zorunda kaldığınız bir şey. Bu cevabın amacı, tamamen IDE kullanıcılarından oluşan ekipler için de derleme sistemlerinin nasıl faydalı olduğunu göstermektir.
Idan Arye

Ben de bu geliştiricilerden biriyim. Parmaklarımın klavyeden çıkmasını istemiyorum. Bunu yapmak düşünce süreçlerimi bozuyor.
David Hammen,

1
Katılmıyorum. IDE'leri tercih ederim. İsimler, kolay aramalar, yeniden düzenleme, hoş kullanıcı arayüzü ile ilgilenmeme izin vermiyorlar. Yani, eğer bir IDE benim için başka bir şey yapacağım gibi yapabileceğim bir şey yapabilirse, onu kullanırım.
ps95

Mesele şu ki, derleme komutları ile ekipteki her geliştirici istediklerini kullanabilir, IDE'nin derleme işlevi sayesinde herkesi yalnızca bir IDE kullanmaya değil, aynı zamanda proje için yapılandırılmış çok spesifik IDE'yi kullanmaya zorlarsınız. Birden fazla IDE için yapılandırılmış ve bunu eşzamanlı olarak iyi şanslar ...)
Idan Arye

13

Pek çok IDE basitçe bir şey inşa etmek için kullanılan komutları toplar ve ardından bir komut dosyası oluşturur ve onu çağırır!

Örneğin, Visual Studio'da 'komut satırı' kutusunda bir C ++ derlemesi için komut satırı parametrelerini görebilirsiniz. Derleme çıktısına yakından bakarsanız, derlemeyi çalıştırmak için kullanılan derleme komut dosyasını içeren geçici dosyayı görürsünüz.

Bugünlerde hepsi MSBuild , ama bu hala IDE tarafından yönetiliyor.

Bu yüzden komut satırını kullanmanızın nedeni doğrudan kaynağa gidip ortadaki adamı atlamak, belki güncellenmemiş ya da sadece başsız bir sunucuda istemediğiniz veya ihtiyaç duymadığınız bir bağımlılık yığını gerektiren bir aracıdır. sürekli entegrasyon (CI) sunucunuz olarak işlev görür .

Ek olarak, komut dosyalarınız, tasarlandıkları geliştirici odaklı adımlardan daha fazlasını yapar. Örneğin, bir derlemeden sonra, ikili dosyalarınızın özel bir yere paketlenip kopyalanmasını veya oluşturulmuş bir yükleyici paketini veya üzerinde çalışan bir belge aracını isteyebilirsiniz. Bir çok farklı görev, bir geliştirici makinede anlamsız bir CI sunucusu tarafından gerçekleştirilir, bu nedenle tüm bu adımları uygulayan bir IDE projesi oluşturabiliyorsanız, bunlardan ikisini de sürdürmek zorunda kalırsınız - geliştiriciler için bir proje ve inşaatlar için başka bir proje. Bazı derleme görevleri (örneğin statik analiz), geliştirici projeleri için istemediğiniz uzun zaman alabilir.

Kısacası, sadece daha kolay - istediğiniz her şeyi yapmak için bir komut dosyası oluşturun ve komut satırında veya bir yapı sunucusu yapılandırmasında bunu başlatmak hızlı ve kolaydır.


9
make

hatırlamak ve yazmak çok daha kolay

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

Projelerin çok karmaşık derleme komutları olabilir. Bir derleme betiği de yalnızca değişen şeyleri yeniden derleme yeteneğine sahiptir. Temiz bir yapı oluşturmak istiyorsanız,

make clean

Bir ara dosyanın üretilmiş olduğu her yeri hatırlamaya çalışmak yerine uygun bir şekilde kurulduktan sonra daha kolay ve daha güvenilirdir.

Tabii ki, eğer bir IDE kullanıyorsanız, bir derleme veya temizleme düğmesine tıklayarak da kolay. Bununla birlikte, imleci ekran üzerinde belirli bir yere hareket ettirmeyi otomatikleştirmek, özellikle pencere hareket ederse o yer hareket ederse, basit bir metin komutunu otomatikleştirmekten çok daha zordur.


4

Başka nasıl yaparsın? Diğer tek yol, bir uzun komut satırı komutu belirtmektir.

Bir başka neden de makefile'lerin derleme süresini çok hızlandıran artımlı derlemeye izin vermesidir.

Makefiles ayrıca bir inşa süreci çapraz platform da yapabilir. CMake, platforma dayalı farklı derleme komut dosyaları oluşturur.

Düzenle:

Bir IDE ile, bir şeyler yapmanın belirli bir yoluna bağlısınızdır. Birçok kişi IDE benzeri özelliklere sahip olmasa da vim veya emacs kullanıyor. Bunu yaparlar çünkü bu editörlerin sağladığı gücü isterler. IDE kullanmayanlar için derleme komut dosyaları gereklidir.

IDE kullananlar için bile, neler olup bittiğini gerçekten bilmek isteyebilirsiniz, bu nedenle derleme betiği size bir GUI yaklaşımının sahip olmadığı düşük uygulama detaylarını sunar.

IDE'lerin kendileri de sıklıkla dahili olarak komut dosyaları oluşturur; Çalıştır düğmesi make komutunu çalıştırmanın başka bir yoludur.


4

Yukarıdaki cevaplar birçok iyi temeli kapsamaktadır, ancak eklemek istediğim (karma olmadığından yorum olarak ekleyemiyorum) eklemek istediğim gerçek dünyadan bir örnek Android programcılığındandır.

Ben profesyonel bir Android / iOS / Windows Phone geliştiricisiyim ve Google hizmetleri API'lerini (çoğunlukla Google Maps) çok kullanıyorum .

Android'de, bu hizmetler bir geliştirici konsoluna bir anahtar deposu veya Google’a benim olduğum kişi olduğumu söyleyen bir tür geliştirici kimliği dosyası eklememi gerektiriyor . Uygulamam farklı bir anahtar deposuyla derlendiyse, uygulamanın Google Haritalar bölümü çalışmaz.

Geliştirici konsoluna yalnızca bir tanesi uygulamayı güncellemek için gerçekten kullanılabilecek bir düzine anahtar istasyonu eklemek ve yönetmek yerine, bu anahtar deposunu güvenli repo'muza ekledim ve Android Studio'yu tam olarak hangi anahtar deposunu oluşturmak için kullanacağını söylemek için Gradle kullanın "debug" veya "release". Şimdi, Google geliştirici konsoluma yalnızca bir tane "hata ayıklama" ve bir tane "yayınlama" için iki anahtarlayıcı eklemem gerekiyor ve tüm ekip üyelerim depoya klonlama yapabiliyor ve geliştirme ekibine girmeden geliştirme hakkını elde edebiliyorlar. konsol ve daha da kötüsü kendi özel anahtar deposunun SHA karmasını ekleyebilir veya bana onları yönetmek yapma. Bu, her ekip üyesine imza anahtar deposunun bir kopyasını verme avantajına sahiptir, bu da ofisten çıkmadığım ve bir güncelleme planlandığı takdirde, bir ekip üyesinin yalnızca kısa bir talimat listesini takip etmesi gerektiği anlamına gelir. Güncelleme.

Bunun gibi bir otomasyon inşa etmek, istikrarlı bir yapı oluşturur ve yeni bir geliştirici, yeni bir makine elde ettiğimizde veya bir makineyi yeniden görüntülememiz gerektiğinde kurulum süresini kısaltarak teknik borcu azaltır.


1

Komut dosyası avantajları oluşturun:

  • değişiklikler, bir iletişim kutusundaki farklı işaretli seçenekler gibi değil, koda (örneğin, git diff komutunda) benziyor

  • basit bir yapıdan daha fazla çıktı oluşturmak

Önceki projelerimden bazılarında derleme komut dosyalarını kullandım:

  • Proje dokümantasyonunu hazırlar (doxygen tabanlı)
  • inşa etmek
  • ünite testleri
  • birim test kapsamı raporları oluşturmak
  • ikili dosyaları bir sürüm arşivine paketleyin
  • dahili sürüm notları üret ("git log" mesajlarına dayanarak)
  • otomatik test

0

Genellikle "build" düğmesini otomatik olarak çağırabilirsiniz (Visual Studio, örneğin komut satırı argümanlarını kabul eder). İnsanlar derleme düğmesinin sağlayamadığı bir şeye ihtiyaç duyduklarında derleme komut dosyaları yazarlar.

Örneğin, çoğu IDE bir seferde yalnızca bir platform oluşturmanıza izin verecektir. Veya bir seferde sadece bir dil . Öyleyse yerleşik çıktılarla yaptığınız şeyler var: IDE'niz hepsini bir yükleme paketine götürebilir mi?

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.