Opened 10 years ago

Closed 10 years ago

Last modified 4 years ago

#3225 closed enhancement (worksforme)

suggestion for buildroot enhancement

Reported by: battlehawk Owned by: agb
Priority: normal Milestone: Barrier Breaker 14.07
Component: toolchain Version:
Keywords: buildroot Cc:


First of all I consider the Kamikaze buildroot system as the easiest and most intuitive build system I saw up to now.

Nevertheless I made some slightly changes to circumvent some inconveniences.

Since I am compiling for some platforms in parallel I have a lot of build-, toolchain_build- and staging-directories lingering around. And since my development machine runs in VMWare I have underestimated the needed disk space for compilation so my needed VM disks are (as usual) to small.

With the following fixes I now can link my build output directories to other (bigger) disk images and seperate even by architectures. Further the packages are not all mixed up in one directory anymore but seperated into architecture dirs.

The following changes I applied to

---	(revision 10581)
+++	(working copy)
@@ -25,13 +25,13 @@

Now i can:

  • ln -s build, toolchain_build, staging_dir and bin to other directories or even disks
  • ln -s for the architectures in build, toolchain_build, ... directories to separate the archs onto different disks
  • sort the images and packages by architectures

I would appreciate when this solution is taken into consideration for future releases since it adds a lot more flexibility to the build_root.

I would be thankful for feedback in the case I oversaw something in build_root that does not work with that change, but as far as I tested, all works well for me.



Attachments (0)

Change History (5)

comment:1 Changed 10 years ago by anonymous

Isn't that what 'Build suffix to append to the BUILD_DIR variable' in Advanced configuration options (for developers) > Build Options is for?

comment:2 Changed 10 years ago by agb

  • Milestone set to Kamikaze
  • Owner changed from developers to agb
  • Status changed from new to assigned

The build/staging dir changes were already performed in trunk, [8362] (August 2007)
The BIN_DIR change seems a bit unnecessary as it is not recommended to build multiple architectures from the same TOPDIR without a make dirclean in between. This change would add an extra directory to traverse.

I'm going to accept the ticket and leave it open for discussion, but I consider first bit resolved and the second bit invalid.

Sorting packages manually isn't too difficult if you still want the functionality...

mv bin/packages/*mipsel.ipk bin/mipsel/

comment:3 Changed 10 years ago by battlehawk

The BUILD_DIR option does not exist (at least under kamikaze 7.09, rev 10592).

About the appropriate changes in the trunk I didn't know yet, but maybe that can also be backported into the kamikaze branch? According to the description at least for the toolchain-$(ARCH) directory you still have all archs parallel in one directory (but since now in the build_dir subdirectory, I could live with that).

Moving the packages would mean a manual extra step to perform for each arc, for sure that can also be automated. But with the way mentioned above one doesn't need to take care for that and it allows me to serve each platform with an own URL easily. But of course that is a matter of taste.

I never did a dirclean when switching arch and all runs well. What side effects has omitting the dirclean? I guess, since the build output directories are seperated, there should be no conflict? And about traversing? Isn't dirclean recursive?

Thanks for comments



comment:4 Changed 10 years ago by nbd

  • Resolution set to worksforme
  • Status changed from assigned to closed

looks like the important suggestions were implemented, closing ticket.

comment:5 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.