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] |
Andy, All, On Thursday 03 March 2011 20:34:29 ANDY KENNEDY wrote: > > From: Yann E. MORIN [mailto:yann.morin.1998@anciens.enib.fr] > > 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. OK, I was not clear either. Sorry for the confusion... When I noticed (due to an error) that some packages were extracting RO files, the easiest solution that came to mind at the time was to run a chmod just after extracting the tarball. Then, I thought that I did not know in advance what packages would ship RO files, so I thought that to avoid any issue in the future, it would be necessary to systematically run the chmod, on every packages. But on the other hand, I also thought that manually inserting a chmod in every packages was stupid, when I could use the CT_Extract helper function to do it, as all packages call it to extract their tarballs. So, the place where to run the chmod was found: the CT_Extract helper. Then came the issue with tarballs which names are not always tied to the name of the directory they extract, and the CWD where it should be extracted. Let's take my previous table again, and lets add CWD in there (remember, I explain what is *currently* happening): For gcc 4.3.2: tarball basename : gcc-4.3.2 CWD : ${CT_SRC_DIR}/ extracted dir : ${CT_SRC_DIR}/gcc-4.3.2/ For Cloog/PPL 0.15.3: tarball basename : cloog-ppl-0.15.3 CWD : ${CT_SRC_DIR}/ extracted dir : ${CT_SRC_DIR}/cloog-ppl/ So, looking at those two packages, we see we can't deduce the directory name by just looking at the tarball basename. So, the solution to force the directory name, and then strip components is OK. We can have sane, canonical directory names. But I did not think of that at the time. Too bad... But lets take a second look... For glibc 2.9: tarball basename : glibc-2.9 CWD : ${CT_SRC_DIR}/ extracted dir : ${CT_SRC_DIR}/glibc-2.9/ For glibc 2.9 ports add-on: tarball basename : glibc-ports-2.9 CWD : ${CT_SRC_DIR}/ extracted dir : ${CT_SRC_DIR}/glibc-ports-2.9/ or (depends on version) : ${CT_SRC_DIR}/ports/ But for glibc to find and use them, the add-ons shall be below the glibc directory, either one of (missing one symlinked to existing one): ${CT_SRC_DIR}/glibc-2.9/glibc-ports-2.9/ ${CT_SRC_DIR}/glibc-2.9/ports/ That also applies to other glibc add-ons, and to other C libraries add-ons also. So we can't cd ${CT_SRC_DIR} before extracting add-ons. Detecting that we are extracting add-ons in the helper function is doomed to fail (it would have to _know_ about the add-ons stuff, and so would not be generic). Instead, we rely on the caller to tell CT_Extract that the CWD is already set to the proper place to extract the tarball. So what actually happens is: For glibc 2.9 ports add-on: tarball basename : glibc-ports-2.9 CWD : ${CT_SRC_DIR}/glibc-2.9/ (untouched by helper) extracted dir : ${CT_SRC_DIR}/glibc-2.9/glibc-ports-2.9/ or (depends on version) : ${CT_SRC_DIR}/glibc-2.9/ports/ Here, we can see that we do not know what directory we should chmod, either. Then, once a package is extracted, we may have to apply patches. Some packages even re-run autoreconf et al. Crosstool-NG patches a package right after it has been extracted: extract package foo patch package foo extract package bar patch package bar autoreconf package bar and so on... So we have to ensure that between extract and patch, the files are RW. What options were left, then? We have to find a place that, when recursively chmoded, would effectively chmod all the package's extracted files, without having the adverse effect of also chmoding other files (if the user did chmod u-w on his #{HOME}, who the heck are we to change that back?). The only place we know for sure that contains our extracted directories is of course our top-level source dir ${CT_SRC_DIR}. Doing the chmod in there would ensure that all extracted files would be chmoded. The adverse effect being that even pre-chmoded files would be chmoded again and again until all packages were extracted. At the time, this option seemed more than reasonable to me. You proved that I was wrong. That's not a problem. :-) Now, assuming that the chmod has to be done for _every_ packages turns out to be totally over-kill, even if only chmoding the current package's files. We only have 5 offending packages, lets have them cleanup their mess... Of course, if we wanted to do it unconditionnally, then a solution like your proposal would be nice to have (see below). > > > 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. So did I! :-) > > 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} Ah, but that would not work. As you can build more than one toolchain from the same working direcotry, and each toolchain might use different versions of, say, gcc, you'd mess up. But then, doing smthg like: if nochdir; then pushd . # For symetry! else mkdir "${CT_SRC_DIR}/${basename}" pushd "${CT_SRC_DIR}/${basename}" fi tar x --strip-components=1 -j -f "${tarball}" chmod -R u+w . popd would most probably do the trick with a few adjustements, I think. > Though, if that seems foreign to you and you don't like it (and this is > ultimately your project) you have the final say. Hmmm. I like being chalenged. I can't test in every conditions, and something that works for me, and which I did not think would be a serious issue, could turn to be a nightmare for someone. Sometime, it turns out the way I choose was the best one, sometime it turns out a better way is found (best and better, as when balancing pros and cons, simplicity vs. efficacity, pragmatism vs. ideology...) And although I am maintaining the stuff, it would not be good that I would reject the opinion of the users. If there is an issue, and it is a real issue (ie. poor performance, bad behavior, stupid code...), then I'd like the case to be solved. At least with an explanation of the case, at best with a fix (code and/or doc). Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- 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] |