Jak automatycznie wprowadzać numery wersji do kodu AVRGCC dla różnych procesorów?

Fri Mar 26, 2004 5:33 am   

Uczę się AVRGCC. Czy jest jakiś mechanizm aby w kodzie wynikowym umieścić
automatycznie zmieniany kolejny numer kompilacji ? Urządzenie będzie się
składać z kilku kawałków. Jak się przestanie panować która wersja jest
wpisana do którego procka, to może być klops.

JS

--
_N_O_S_P_A_M_bsj@poczta.onet.pl
(usuń _N_O_S_P_A_M_ z adresu)

Fri Mar 26, 2004 6:57 am   

JS wrote:


Automatycznie dosc latwo w kazdym C mozna wpisac date i czas kompilacji:
__DATE__ __TIME__.

Krzysiek Rudnik

Sat Mar 27, 2004 4:05 am   

Użytkownik "Krzysztof Rudnik" <rudnik@kki.net.pl> napisał w wiadomości
news:c3vo1d$609$1@news.atman.pl...

się da upchać w jednym bajcie.

Pozdrawiam
JS



--
_N_O_S_P_A_M_bsj@poczta.onet.pl
(usuń _N_O_S_P_A_M_ z adresu)

Sun Mar 28, 2004 7:34 pm   

JS wrote:


Jakie banalne i skuteczne w swej prostocie. :-)

Ale lepiej chyba zatrudnić komendę "eval" i w pliku number.inc trzymać
konkretny numer, a nie sekwencję "+1\n+1\n+1\n+1\n+1\n..." - bez
kompilacji patrząc tylko w źródła nie ma szans stwierdzić, co z tego
wyjdzie. :)

--
Adam Dybkowski
adybkows@amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/

Sun Mar 28, 2004 8:14 pm   

W artykule <c3vj67$2h7$1@mamut.aster.pl>
autorem którego mieni się JS, napisano:


Zakładam, że masz automatyczną generację zależności (było niedawno na liście).

W makefile'u:

# Kompilacja 'z odliczaniem'
all: next work

# Kompilacja zwykła.
work: $(TARGETS)

# Liczenie wywołań
..PHONY : next

next:
echo +1>>number.inc

# Tyle.

Plik version.c:

const int sys_version = 0
#include "number.inc"
;

Plik version.h

extern const int sys_version;

Jeśli w którymś pliku trzeba wersji, to jest ona dostępna jako
stała sys_version. W programie musi być linkowany (i uwzględniony
w zależnościach) plik version.o

Jeśli uruchomi się 'make all', to najpierw zostanie zbudowany target next,
czyli wykona się 'echo +1>>number.inc'. W pliku number.inc (który
początkowo powinien być pusty) będą się akumulować napisy "+1" -
po jednym na każde wywołanie. Włączone do version.c utworzą one
wyrażenie inicjujące stałą sys_version.

Oczywiście można inaczej - np. prosty program, który wczyta numer z pliku
version.inc, zinkrementuje (lub przetworzy w inny sposób) i zapisze.

make all zawsze spowoduje kompilacje (co najmniej version.c) i linkowanie,
nawet jeśli inne składniki projektu nie zostały zmienione (sys_version
się zmienia). Aby tego uniknąć można wywołać make work.

Mam nadzieję, że na bazie powyższych wykombinujesz coś użytecznego.

Pozdrawiam
Jarosław Szynal

Mon Mar 29, 2004 6:12 am   

On Sun, 28 Mar 2004 22:34:42 +0200, Adam Dybkowski <adybkows@amwaw.edu.pl> wrote:
[.....]


Poza tym nie widzę specjalnie sensu aby wykorzystywać gdzieś w sofcie
numer kompilacji. Zakładając że oznaczamy wersje softu jako X.Y.Z, to
dla mnie każda mała zmiana w sofcie (np. jakiś bugfix) jest powódem do
zwiększenia Z o 1. Można to zrobić ręcznie. Dla dużych zmian
(np. dodanie jakiej nowej funkcjonalności) zwiększamy X i/lub Y. A do
kontoli wersji poszczególnych plików źródłowych projektu to są takie
narzędzia jak np. CVS lub SubVersion (oba bezpłatne). Jakakolwiek
zmiana któregoś z plików źródłowych implikuje zmianę X i/lub Y i/lub Z.

Regards,
/J.D.
--
Jan Dubiec, jdx@slackware.pl, mobile: +48 602 101787

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

Mon Mar 29, 2004 12:16 pm   

W artykule <c47cn4$8ll$3@mamut.aster.pl>
autorem którego mieni się Adam Dybkowski, napisano:


Minimum środków ;)


Fakt. Choć można policzyć wiersze.

Pozdrawiam
Jarosław Szynal

Mon Mar 29, 2004 3:31 pm   

ciach..

No chociażby sytuacja, gdy tester musi obsłużyć moduły z różnymi wersjami
softu. I wiele, wiele innych przypadków.

W każdym razie dzięki za porady. Teraz coś z tego skleję.

Pozdrawiam
JS


--
_N_O_S_P_A_M_bsj@poczta.onet.pl
(usuń _N_O_S_P_A_M_ z adresu)

Mon Mar 29, 2004 4:51 pm   

JS wrote:

(z dokładnością do makr __DATE__ i __TIME__ jeśli są używane). Dlatego
używanie numeru kompilacji IMO nie ma sensu. Natomiast różne wersje softu
oznaczają dla mnie różne źródła, t.j. różniące się co najmniej jednym
plikiem. A to IMO jest już powód do podwyższenia numeru wersji softu.

Regards,
/J.D.

Mon Mar 29, 2004 6:32 pm   

Jan Dubiec napisal(a):


Zgadzam sie z ta wypowiedzia przedpiscy i poprzednia.
Ja robie na przyklad tak, ze w w kazdym projekcie prowadze plik
'XXX_revision_history.txt' gdzie sa opisane szczegolowo kolejne wersje
programow / plytek / rysunkow / itd. Po skompilowaniu program jest
umieszczany w folderze /Manu i tylko stamtad mozna go wziac do
programowania kosci. W nazwie jest zakodowany numer wersji. Kiedys
kodowalem w programie numer wersji, ale w koncu zrezygnowalem ztego,
bo nie przydawalo mi sie do niczego. Wygodniej jak dla mnie jest robic
opis na kosci / przy kosci z numerem wersji.

--
Pozdrowienia, Marcin E. Hamerla

"Every day I make the world a little bit worse."

Mon Mar 29, 2004 7:39 pm   

Masz rację (do bólu ). To co jest mi potrzebne to rzeczywiście mógłby być
numer wersji. Natomiast zależy mi na tym aby generować go automatycznie.
Dlatego najprościej ponumerować kompilacje. Do CVS lub SubVersion pewnie
kiedyś dojrzeję. Na tą chwilę wystarczy mi zapamiętanie numeru, kiedy
uzyskam zakładaną funkcjonalność urządzenia. Głównie chodzi o to aby nie
włożyć do urządzenia dwóch modułów z różnymi wersjami softu. W takim
przypadku urządzenie powinno odmówić działania. Poza tym tester, odczytując
wersję softu z modułu, może przyjąć odpowiedni zestaw parametrów.

W każdym razie pomysł, który podrzuciliście, już działa. Dzięki.

JS
--
_N_O_S_P_A_M_bsj@poczta.onet.pl
(usuń _N_O_S_P_A_M_ z adresu)