Salut, Vlad! Vom retrage depunctarea, întrucât este doar pentru partea de bonus. Legat de feedback, am notat intern.
Numai bine, Răzvan On Sun, May 17, 2020 at 5:30 PM Vlad Lungu <vlad.lsc2...@gmail.com> wrote: > > Salut, Razvan! > > Acum am vazut, multumesc! Acea regula este, insa, de la bonus. Se rasfrange > asupra intregii teme? > > Cat despre feedback, l-am completat deja inainte sa apară aceste note și nu > mai pot adăuga. De aceea am pus aici. > > În dum., 17 mai 2020 la 17:24, Razvan Crainea <razvan.crai...@gmail.com> a > scris: >> >> Salut, Vlad! >> >> Unul din colegii tăi a reparcat o problemă legată de depunctările >> pentru regulile de clean, pe care noi am confirmat-o mai devreme. >> Drept urmare, am corijat depunctările pentru cei care au avut false >> positives, iar tu ești unul dintre ei. >> Depunctarea la tema 4 vine de la regula următoare: >> >> config_params: config_params.c >> $(CC) -Wall -o config_params config_params.c so_sched_initializer.c >> >> În această regulă compilezi mai multe (două) fișiere sursă .c >> Legat de feedback, te rugăm să notezi asta în feedback-ul completat pe >> cs.curs.pub.ro - în felul ăsta ne este mai ușor să-l integrăm anul >> viitor. >> >> Numai bine, >> Răzvan >> >> On Sun, May 17, 2020 at 5:00 PM Vlad Lungu via so <so@cursuri.cs.pub.ro> >> wrote: >> > >> > Multumesc mult de lamurire! >> > >> > Problema mea legata de "mai mult fisiere sursa" e ca fiecare regula >> > compileaza un singur fisier sursa, iar cea de construire a bibliotecii are >> > toate dependentele cu fisiere .o. Nu am doua gcc asa cum a zis teodor >> > nicaieri. In contextul asta, de la ce apare depunctarea aceea? (am regula >> > de bonus care duce la alte doua reguli care creeaza fiecare cate un >> > executabil. Sa fie de la asta?) >> > >> > Cat despre clean, tocmai am numarat fisierele dinainte de make, am dat >> > make, make clean si dupa am numarat din nou si da la fel. De aceeea intreb >> > daca se poate verifica. >> > >> > De asemenea, ca feeedback pentru la anul, cred ca ar fi util daca in lista >> > de depunctari, la categoria build, s-ar adauga mai explicit aceste >> > depunctari legate de makefile. >> > >> > În dum., 17 mai 2020 la 16:37, Paul Olaru <olarupaulstelia...@gmail.com> a >> > scris: >> >> >> >> Există niște reguli generale pentru makefile-uri, dar cea mai importantă >> >> regulă în opinia mea este ca dacă dai "make build" din nou fișierele deja >> >> compilate nu vor fi compilate din nou. >> >> >> >> Pe viitor, pentru a evita problema cu mai multe fișiere sursă, >> >> folosește-te de regulile template (nu sunt sigur că ăsta e numele corect) >> >> și folosește fișiere .o în loc de .c în dependențe. Pentru a obține >> >> fișierele .o poți face o singură regulă de tipul: >> >> >> >> %.o: %.c file1.h file2.h ... >> >> <tab>gcc -c $< -o $@ -Wall -pedantic >> >> >> >> (Ajustând desigur flagurile de compilare în această regulă generală). Nu >> >> e nevoie să faci manual câte o regulă pentru fiecare fișier .o dacă ai >> >> una de tipul ăsta generală. Și apoi la fișierul final, să zicem mylib.so, >> >> ai regula simplă: >> >> >> >> mylib.so: init.o loader.o elf.o >> >> <tab>gcc $^ -o $@ -dynamic >> >> >> >> (Ajustezi corespunzător comanda). >> >> >> >> În final, trebuie să ai o regulă de build care să nu recompileze fișierul >> >> de fiecare dată când faci rebuild. O regulă simplă ar fi: >> >> >> >> build: mylib.so >> >> .PHONY: build >> >> >> >> (Regula .PHONY e opționala dar e utilă pentru a ignora fișierele cu >> >> numele "build" dacă se vor crea) >> >> >> >> Toate aceste reguli ar fi trebuit să te obișnuiești încă din anul I cu >> >> ele, dar nu e târziu nici acum. >> >> >> >> La plângerea cu regula clean, dacă faci make build urmat de make clean >> >> ești 100% sigur că rămân exact fișierele tale din arhivă? *Orice* fișier >> >> în plus poate duce la acel warning. >> >> >> >> Dacă este relevantă opinia mea (nu garantez), aș zice că depunctarea >> >> pentru regula cu numele "tema2" e meritată (faci rebuild degeaba la unele >> >> fișiere), cea pentru regula clean e discutabilă (nu am de unde ști dacă >> >> chiar ți se șterg toate fișierele sau nu) iar depunctarea pentru unused >> >> variabile... Poate ar putea fi redusă la 0.1 (dar să îți fie învățătură >> >> de minte, în proiectele mari cu 50 de warninguri create fix pe ideologia >> >> de "it's fine" nu vrem încă unul). >> >> >> >> On Sun, May 17, 2020, 15:56 Vlad Lungu via so <so@cursuri.cs.pub.ro> >> >> wrote: >> >>> >> >>> Salut! >> >>> >> >>> M-am uitat pe vmchecker la depunctarile pe care le-am primit. La tema 2, >> >>> la ambele teme, am primit depunctare pentru numele regulii de build, >> >>> desi nu era specificat vreundeva acest detaliu. La mine se numeste >> >>> tema2, trebuia libsoloader.so. Trebuia sa facem asta?. La tema 4 pe >> >>> linux am o singura variabila neutilizata, care duce la un warning de >> >>> "unused variable". Se justifica o depunctare de 0.2 pentru "warninguri >> >>> de compilare" in acest caz? Tot la tema 4 imi primesc o depunctare >> >>> pentru ca regula clean nu sterge toate fisierele create, dar tocmai am >> >>> testat si chiar le sterge pe toate. Care este cauza? In plus, tot la >> >>> tema4, am depunctare pentru "compilarea a mai multe surse in aceeasi >> >>> regula", lucru pe care nu l-am gasit in lista de depunctari si care nu >> >>> sunt sigur la ce se refera. >> >>> >> >>> As aprecia foarte mult niste explicatii suplimentare! >> >>> >> >>> Numai bine, >> >>> Lungu-Stan Vlad-Constantin, >> >>> 334CB >> >>> _______________________________________________ >> >>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> > >> > _______________________________________________ >> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> >> >> >> -- >> Răzvan Crainea -- Răzvan Crainea _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
