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
_______________________________________________
http://ocw.cs.pub.ro/courses/so/info/lista-discutii
