Bună, Corina! În cazul tău, Makefile-ul submis pe vmchecker nu șterge finierul thread_lists.o. Legat de tema 2, faptul că nu ai nicio regulă cu numele so_stdio.dll sau libso_stdio.so face ca makefile să încerce să linkeze de fiecare dată[1]. Același lucru se întâmplă și pe linux, și pe windows. Pentru alte detalii sau nelămuriri despre corectarea temelor, vă rugăm să urmăriți pașii de aici[2]. Astfel putem centraliza și noi discuțiile, și nici nu spamăm restul participanților de pe listă.
[1] https://gitlab.cs.pub.ro/snippets/40 [2] https://ocw.cs.pub.ro/courses/so/teme/contestatii Numai bine, Răzvan On Sun, May 17, 2020 at 7:10 PM Mihaila Corina <mihailacorin...@yahoo.ro> wrote: > > Salut! > > La tema4 pe linux am primit si eu depunctare pentru regula clean, desi la > mine, local, se sterg toate fisierele generate pe parcurs. > La tema2, pe ambele platforme, nu inteleg depunctarea pentru "nu exista > regula de compilare pentru so_stdio.dll". Testand local, nu mi se > recompileaza fisierele deja compilate. > > Numele meu de utilizator este corina.mihaila > > Mutumesc anticipat! > > > > Pe duminică, 17 mai 2020, 18:33:09 EEST, Vlad Lungu via so > <so@cursuri.cs.pub.ro> a scris: > > > > > > 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 -- Răzvan Crainea _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
