This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> -----Original Message----- > From: Yann E. MORIN [mailto:yann.morin.1998@anciens.enib.fr] > Sent: Thursday, March 03, 2011 12:53 PM > To: crossgcc@sourceware.org > Cc: ANDY KENNEDY > Subject: Re: chmod -R u+w .build/src EACH TIME????? > > Andy, All, > > On Thursday 03 March 2011 19:27:39 ANDY KENNEDY wrote: > > You didn't understand the point of the one minute offset. This was so > > that > > all directories in the CWD would hold the same time as an arbitrary > > known unmodified point. To set the touch one minute in the past assures > > that when we recheck to see if anything has changed, only directories > > that > > have been modified will have a variant of the timestamp by at least one > > minute. > > OK, my bad, sorry... I see the point, now. > > Anyway, instead of trying to cover all cases, and coming up with complex, > flawed heuristics, I decided to reap this big chmod away, and have > offending packages cleanup the mess behind them. The culprits are: > - autoconf-2.65 > - automake-1.11.1 > - libtool-2.2.6b > - make-3.81 > - ncurses-5.7, all files > > Onlt five of them. It took only a few minutes to do a chmod in all > 5 of them, so no big deal... I'm confused. I must really be misreading what you wrote. I thought that it was an issue of the unpacks unpack into other directories besides their own? Like autoconf-2.65 unpacks into automake a subdirectory/files to identify autoconf-2.65. I must really have read into what you wrote. > > > See, we take the Doc's Delorean, hit 88MPH and go back in time > > precisely one minute. > > Hehe... 88MPH.. Hehe! :-) Sorry, I really enjoyed the 80s. > > > I don't really understand why you are not allowed to extract into known > > source directories? If it is due to the fact that some tarballs you > > extract are overwriting dirs that are expected to be in CWD, could you > > not contain all of the offending dirs into a single dir -- yes, you > > would > > have to reach out a bit deeper to get to the offending Makefile(s) but > > you could then control the names of the extract directories. All in > > all, > > it would make the scripts easier to write (I would think). > > > > This is, in fact, what I'm doing in BuildRoot for proprietary code that > > we are getting from our code repo. I make the offensive (usually third > > party) code be one level deep and I supply a Makefile that preps the > > build another level deep. > > OK, so you mean every tarball should be extracted into its own intermediary > directory, so we'd get: > ${CT_SRC_DIR}/glibc/glibc-2.9/{all,glibc,files,here} > /gcc/gcc-4.3.2/{all,gcc,files,here} No, it would be: ${CT_SRC_DIR}/glibc/{all,glibc,files,here} /gcc/{all,gcc,files,here} for these cases as the --strip-components n removes n number of leading parent dirs. I think you can do just --strip-components <no arg> and only get one dir stripped. Though, if you have offensive tarballs as the ones I originally thought you were talking about, then yes, you'd have an additional level of directories. > > and we then would 'just' have to chmod the intermediary directory. Why not. > > But the per-package chmod is far easier to handle, so far! > You would 'just' have to do a chmod of the package after the unpack: chmod -R u+w ${CT_SRC_DIR}/${pkg_name} where in our above examples would be: chmod -R u+w ${CT_SRC_DIR}/gcc chmod -R u+w ${CT_SRC_DIR}/glibc etc. Which seems much less complicated to me. No need to poll the FS just to find the name of the package dir either. . . Though, if that seems foreign to you and you don't like it (and this is ultimately your project) you have the final say. Andy -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |