Am Dienstag, 18.03.03 um 02:54 Uhr schrieb Adam Skwersky:
Hi,That depends on the package. If I update a package to a new version, if it had no patch I usually first try it the "naive" way, that is just building it w/o a patch, and often that works. If it had a patch, I check if the patch is still needed, then test the build.
That's not what I want. I just want to be able to recompile everything and
then install everything in one step. That would make the development cycle
much easier. Mathias pretty much understood what I wanted to do (skip the
unpacking & patching steps).
I am beginning to wonder if I am misunderstanding the whole model of porting
and developing unix packages using fink. How does everyone else do the
change->compile->test->change->compile->test->release cycle with fink??
If I run into problems, I follow different approaches depending on the package (and I guess others will use yet another ways). Often I go to /tmp, then extract the tarball there (giving me foo-1.0 dir), then make a copy of that (foo-1.0-patched), in which I edit files to fix the problems. Then I run "diff -ru" on the two dirs to create a fink patch. Then I build the package. That works fine for small to medium packages.
Of course for biggies like evolution or KDE etc. this is not good (though in the end you have to do full build if you want reliable test results). In these cases I usually setup a terminal with a fink-like environment (CPPFLAGS, PATH, LDFLAGS etc. set like fink sets them) and then perform a manual build. I fix build problems as I run into them. From this I then in the end I derive a patch.
Max
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
