On 31 May 2011 22:34, Vladimir Savic <vladimir.firefly.savic at gmail.com>wrote:
> On Tue, 2011-05-31 at 07:32 -0400, Gregory Pittman wrote: > > On 05/31/2011 05:44 AM, Owen wrote: > > > On Mon, 30 May 2011 19:29:30 -0400 > > > Gregory Pittman<gregp_ky at yahoo.com> wrote: > > > Ok, so run make install as root, then that kind of changes all the > > > permissions in the build directory. Maybe no big deal, but my > > > preference is to have user files owned by the user. > > > > > Ah, yes, forgot about that since I'm always putting svn versions into my > > /home directory... > > > > Greg > > It is indeed wise to run make as regular user because of system security > reasons. But there is another one (I might be wrong on this - in which > case feel free to correct me, please). > Spot on. > Make install will dive into folder next in list and do making followed > immediately by install. OK. > > I think I can see the problem in this scenario: > Say you already have some application installed from svn/bzr/git (any > revision control mechanism) and that you pull/update to latest > regularly. And imagine that application isn't "monolithic" (single > binary), but consists of many dynamic libraries/modules called during > run time from main app instead. > This is true for all installable parts of the application. Icons, header files and other static stuff gets immediately installed too. > > Doing "make" alone will terminate on first appearance of error, but your > older installation will not be compromised. But, doing "make install" > will build while it's possible AND install while "make"-ing is possible, > leaving you with part of installation updated and with other part, > currently unbuildable one, obsolete. Wouldn't that (possibly) leave you > unable to run your beloved application? > You are right. If something blows up during compilation you almost always get an unclean target directory and your application will most likely not run. > > Vlada > > Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.scribus.net/pipermail/scribus/attachments/20110531/8225cf96/attachment.html>
