Re: [so] Intrebari legate de depunctari
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 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 > a scris: > > > > > > Super, iti multumesc! > > În dum., 17 mai 2020 la 18:28, Razvan Crainea 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 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 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 > >>> 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 > >>> > 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 ... > >>> >> 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 > >>> >> 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ă
Re: [so] Intrebari legate de depunctari
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 a scris: Super, iti multumesc! În dum., 17 mai 2020 la 18:28, Razvan Crainea 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 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 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 >>> 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 >>> > 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 ... >>> >> 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 >>> >> 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
Re: [so] Intrebari legate de depunctari
Super, iti multumesc! În dum., 17 mai 2020 la 18:28, Razvan Crainea 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 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 > 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 > 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 ... > >> >> 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 > >> >> 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 > 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
Re: [so] Intrebari legate de depunctari
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 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 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 >> 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 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 ... >> >> 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 >> >> 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 >> >> 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
Re: [so] Intrebari legate de depunctari
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 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 > 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 > 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 ... > >> 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 > >> 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 > 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 > >>>
Re: [so] Intrebari legate de depunctari
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 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 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 ... >> 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 >> 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 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
Re: [so] Intrebari legate de depunctari
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 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 ... > 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 > 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 > 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
Re: [so] Intrebari legate de depunctari
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 ... 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 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 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
Re: [so] Intrebari legate de depunctari
Salut, S-ar putea ca depunctarea depunctarea -0.1: makefile incorect: compilarea mai multor surse în aceași regulă sa fie pentru ca ai ceva de forma asta? regula: gcc ... gcc ... In rest, depunctarile mi se par de bun simt: sa n-ai warninguri, ca numele regulilor sa fie fisierele pe care le creeaza etc. Intrebarea mai buna e de ce scrie "aceași" acolo. Teodor Dutu On Sun, May 17, 2020 at 3:56 PM Vlad Lungu via so 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
[so] Intrebari legate de depunctari
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
