| Summary: | Usage of $($(PKG)_DIR_PREFIX) is an issue with linux package | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Ryan Barnett <ryan.barnett> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | buildroot |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
|
Description
Ryan Barnett
2013-12-04 20:32:35 UTC
I have a patch series in the queue (new version to be sent) that should address this issue... Thomas D - has this patch been sent? If so, can you provide a link? See http://patchwork.ozlabs.org/patch/290253/ http://patchwork.ozlabs.org/patch/290254/ As said, there needs to be some changes on the second patch (see the discussion there, I thought it was mainly the naming of the DIR_PREFIX variable). You did also see this committed patch, right? http://git.buildroot.net/buildroot/commit/?id=9e7e9b215017ee91c9369f01476bb4b4fc5f2484 Are you saying that this could be causing the issue? I don't have time to figure out if it really does. All I was doing was playing around with trying to add the ability to specify multiple BR2_GLOBAL_PATCH_DIR for performing builds and I accidentally ran across when I was printing out PATCH_BASE_DIRS in the patching step and noticed that /linux was being printed out. Thomas Petazzoni was next to me and told me to submit a bug for it since I wasn't really intending (more so don't have time) to fix this issue. I hope I made it clear that this is in no way an issue for me but rather something I noticed when doing some development. Ryan, can you confirm to Thomas DS which Buildroot version you were using? I believe you were using the latest master, i.e a Buildroot version that does include the http://git.buildroot.net/buildroot/commit/?id=9e7e9b215017ee91c9369f01476bb4b4fc5f2484 commit that Thomas DS pointed out. So I believe the issue that Ryan is reporting still exists in the current Buildroot master. As I stated in the original message of this bug report - I was using commit 931b73e5eae4a3ba6b2e37db526fd7243a139e64 as my head which is from 29 Nov 2013. This means that the patch that Thomas D mention above was included in my testing. Thus I believe that this is still an issue even with the patch Thomas D mentioned. The tree that I was using was this - http://git.buildroot.net/buildroot/tree/?id=931b73e5eae4a3ba6b2e37db526fd7243a139e64. Thanks Ryan. If I understand the problem correctly, then it will be fixed with my additional patches. In the current code, if you print out PATCH_BASE_DIRS for busybox and linux, you get: >>> busybox 1.21.1 Patching PATCH_BASE_DIRS='package//busybox /busybox' >>> linux 3.10.2 Patching PATCH_BASE_DIRS='/linux /linux' with PATCH_BASE_DIRS calculated as: PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX)/$(RAWNAME) $(call qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME) and with my modified code, it becomes: >>> busybox 1.21.1 Patching PATCH_BASE_DIRS='package/busybox/ /busybox' >>> linux 3.10.4 Patching PATCH_BASE_DIRS='linux/ /linux' with PATCH_BASE_DIRS calculated as: PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX) $(call qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME) Ryan, can you confirm that what I describe above is the problem you have seen, and that the 'fixed' output is indeed what you expect? (In reply to comment #8) > Thanks Ryan. > > If I understand the problem correctly, then it will be fixed with my additional > patches. In the current code, if you print out PATCH_BASE_DIRS for busybox and > linux, you get: > > >>> busybox 1.21.1 Patching PATCH_BASE_DIRS='package//busybox /busybox' > >>> linux 3.10.2 Patching PATCH_BASE_DIRS='/linux /linux' ^^^^^^ Yes this is the problem I'm was trying to communicate. The first instance of /linux is incorrect. Sorry for the confusion. > with PATCH_BASE_DIRS calculated as: > PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX)/$(RAWNAME) $(call > qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME) > > > and with my modified code, it becomes: > >>> busybox 1.21.1 Patching PATCH_BASE_DIRS='package/busybox/ /busybox' > >>> linux 3.10.4 Patching PATCH_BASE_DIRS='linux/ /linux' > > with PATCH_BASE_DIRS calculated as: > PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX) $(call > qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME) > > > Ryan, can you confirm that what I describe above is the problem you have seen, > and that the 'fixed' output is indeed what you expect? Yes this is my problem and your patchset fixes it! Too much email traffic to keep up on this stuff. This brings up another interesting point. Should we make the $(call qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME) conditional on BR2_GLOBAL_PATCH_DIR being defined? Are you going submit a new version of your patches soon? I'm working on trying to make BR2_GLOBAL_PATCH have the ability to have multiple directories specified. (In reply to comment #9) > (In reply to comment #8) > This brings up another interesting point. Should we make the $(call > qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME) conditional on BR2_GLOBAL_PATCH_DIR > being defined? That sounds like a good idea to me... > > Are you going submit a new version of your patches soon? I'm working on trying > to make BR2_GLOBAL_PATCH have the ability to have multiple directories > specified. 'soon' is relative :-) In the mail thread of this patch, Arnout mentioned that ThomasP had a patchset introducing a split SRC / BUILDDIR definition, which is partially related to my patch. Just this week I asked Thomas what the status of this patch was. I'm willing to adopt that patchset (but I haven't found it yet). (In reply to comment #10) > (In reply to comment #9) > > Are you going submit a new version of your patches soon? I'm working on trying > > to make BR2_GLOBAL_PATCH have the ability to have multiple directories > > specified. > > 'soon' is relative :-) > In the mail thread of this patch, Arnout mentioned that ThomasP had a patchset > introducing a split SRC / BUILDDIR definition, which is partially related to my > patch. Just this week I asked Thomas what the status of this patch was. > I'm willing to adopt that patchset (but I haven't found it yet). As I mentioned, I'm working on BR2_GLOBAL_PATCH_DIR have the ability to have multiple directories which will conflict with the patches you mentioned earlier. I will see if I can poke Thomas P on your behalf so we can figure out a way to coordinate my changes with yours since they will be conflicting. Here is an early preview of what I've been working on. https://github.com/rjbarnet/buildroot/compare/master...multiple-patch-dir Hi Ryan, Just to make sure I understand you correctly: when you write "... which will conflict with the patches you mentioned earlier" you are talking about the fact that one of us will have to rebase his patch on top of the other one's, right? From a functional point of view, there should be no conflict. Thanks, Thomas This problem is solved in 2014.02. |