[so] Intrebari legate de depunctari
Vlad Lungu
vlad.lsc2008 at gmail.com
Sun May 17 17:30:31 EEST 2020
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20200517/24c8ea06/attachment.html>
More information about the so
mailing list