Thanks to the amazing efforts of the developers the CVS is changing almost daily. Now I wonder what is the best and least time-consuming procedure to rebuild a YADD.
Currently I do:
cd $HOME/tuxbox-cvs
cvs -z3 up -dP
cd cdk
./autogen.sh
./configure .........
make all
This frequently leads to build errors, then I do a make distclean or if that doesn't help even a complete removal of both $HOME/dbox2 and $HOME/tuxbox-cvs.
I have the feeling that there are better methods to keep up-to-date. Can one of you clear me up?
Thx, JockyW
What is the best procedure to keep YADD up to date?
-
JOCKYW2001
- Einsteiger
- Beiträge: 358
- Registriert: Montag 21. Juli 2003, 23:52
-
Homar
- Senior Member
- Beiträge: 1278
- Registriert: Mittwoch 5. September 2001, 00:00
at first, i used cvs -z9 update -dP, but sometimes it makes unlogically errors.
The next try with cvs update -dPA works much finer, but on change youre source manually, sometimes you have to edit your source after an update.
If you havent local modified Source, you can use cvs update -dPAC.
It makes allways a clear CVS-Structure.
The next try with cvs update -dPA works much finer, but on change youre source manually, sometimes you have to edit your source after an update.
If you havent local modified Source, you can use cvs update -dPAC.
It makes allways a clear CVS-Structure.
-
obi
- Senior Member
- Beiträge: 1282
- Registriert: Montag 12. November 2001, 00:00
sorry, but
there is absolutely nothing wrong in the way he uses cvs.
@JOCKYW2001:
one method to keep your build up to date is to follow the cvs commit mailing list or cvs update command output and to remove the corresponding dot-files in the cdk directory for source files from outside the cdk directory (i.e. apps, hostapps, driver). there is no reliable way to track changes to apps from the cdk makefile.
e.g. if apps/tuxbox/enigma/src/foobar.cpp changed, then do "rm .enigma ; make .engima".
as an alternative you might want to chdir to apps/tuxbox/enigma, add the compiler's directory to your path variable and type "make && make install". that's what I do.
if you encounter build errors after a distclean then either your local copy or the cvs contents are screwed up. sometimes libraries get changed which results in source and/or binary incompatibility. you have to build and install those libs before the applications which are using them (i.e. make .misc_libs before make .neutrino).
-z3 should be preferred because -z9 creates more load on the server and client side while it does not have any noticeable effect on download speed and bandwith if you're not behind a 9.6k modem.Homar hat geschrieben:at first, i used cvs -z9 update -dP, but sometimes it makes unlogically errors.
-A does nothing at all if you are using the main trunk. if you aren't, then you will be using it afterwards.The next try with cvs update -dPA works much finer, but on change youre source manually, sometimes you have to edit your source after an update.
...and if you have not modified anything, then there is no need for -C either.If you havent local modified Source, you can use cvs update -dPAC.
It makes allways a clear CVS-Structure.
there is absolutely nothing wrong in the way he uses cvs.
@JOCKYW2001:
one method to keep your build up to date is to follow the cvs commit mailing list or cvs update command output and to remove the corresponding dot-files in the cdk directory for source files from outside the cdk directory (i.e. apps, hostapps, driver). there is no reliable way to track changes to apps from the cdk makefile.
e.g. if apps/tuxbox/enigma/src/foobar.cpp changed, then do "rm .enigma ; make .engima".
as an alternative you might want to chdir to apps/tuxbox/enigma, add the compiler's directory to your path variable and type "make && make install". that's what I do.
if you encounter build errors after a distclean then either your local copy or the cvs contents are screwed up. sometimes libraries get changed which results in source and/or binary incompatibility. you have to build and install those libs before the applications which are using them (i.e. make .misc_libs before make .neutrino).