Hi Max, Thanks for the tips. However one important step is missing. How do you do the "install" after a successful build in your /tmp/<finkproject> directory? A number of fink packages have a specific set of steps for doing the install?
The nice thing about FinkCommander is it lets you rebuild/install in one easy step. So I like to use that. (I'm a novice when it comes to the fink command line options, so I use the GUI for now). Here is what I've tried (and it seems to be ok). I motified the Engine.pm to NOT re-extract the archive if a certain env variable is set to "1". I also tell fink not to delete the src archive after building. So I build the package for the first time and have it extract the original archive and build and install it. Then I cp the /sw/src/<project>/<project-ver> to <project-ver>.old. Then I mv that same folder someplace (like in my /User/adam/sandbox/ folder), and put a link called <project-ver> to that local copy of the src package. Then I set the EV to "1" so Fink no longer re-extracts packages. I can now tell fink to rebuild and install without worrying about losing my work. This makes the rebuild/reinstall step much easier, and the change/test cycle is faster. If I ever forget to set the EV, fink deletes only the link and the original src package, but not my changed version. What do you think of that? Am I setting myself up for failure later on? Adam Skwersky > > Am Dienstag, 18.03.03 um 02:54 Uhr schrieb Adam Skwersky: > > > Hi, > > > > 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?? > > > 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. > > 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
