Super, iti multumesc! În dum., 17 mai 2020 la 18:28, Razvan Crainea <razvan.crai...@gmail.com> a scris:
> 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
