[so] Intrebari legate de depunctari

[Vlad Lungu]

Super, iti multumesc!

În dum., 17 mai 2020 la 18:28, Razvan Crainea <razvan.crainea at 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.lsc2008 at 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.crainea at 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 at 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 <
> olarupaulstelian97 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20200517/0dc169b8/attachment.html>