All about makepkg and splitpkg .conf files
Today I was looking into ICC (Intel’s C/C++ Compiler) after someone in #x264 mentioned it. I was wondering if it was possible to not only customise a pkgbuild, but also the entire build environment as well. Obviously it’s possible if anyone takes the time to read makepkg.conf, however it got me thinking on some other things. Makepkg, for those who aren’t aware, is like a lot of the other Arch tools: simple shell script. The same goes for abs, and various other daemon and startup related things Arch does.
Customised compiler usage, or “I want to use ICC on everything”
To configure makepkg or splitpkg for ICC, simply open the required conf file, skim down to the ‘Architecture, Compile Flags’ block (for cleanliness rather than necessity,) and add in CC=icc and CXX=icpc. That’s it. As makepkg is a shellscript, it automatically loads the correct info into the build environment when running your pkgbuild. For an individual pkgbuild once off or whatever, add those variables to your build block pre-make.
Package differences and binary patching
I only noticed this feature earlier today, but makepkg actually has an xdelta module. One could add in the xdelta flag (read the source, too much :EFFORT: for me) and generate binary patches of previous patches, allowing relatively small changes to HUEG packages to not raep the connections of Indonesian, Brazillian, and Australian users. You could also stick Options=(xdelta) in your pkgbuild I guess. You’d need to have your previous package on hand however.
What the shit is splitpkg?
Chakra and KDEmod users, FLOCK! Splitpkg is the build system Chakra and KDEmod development uses. It’s an exact copy of makepkg and makepkg.conf, only the config is edited to allow for building regular packages as well as KDEmod packages. Splitpkg automatically outputs the built packages in the directory of choice, as well as a few other things.
I also run Quadpkg on my machine, another variation that compiles for -j5, outputs .tar.xz packages, and does some other handy optimisations for quadcores. My quadpkg is also configured for ICC now, which hopefully gives it more oomf.
There are other things one could try, for laziness, like distpkg, which is identical to makepkg, only setup to always use DistCC. Some things are better off not being done over distcc, but really it’s as simple as editan the pkgbuild for this, however, :EFFORT:
Now to figure out why nVidia is still broken, and then do some ICC builds of x264, ffmpeg, and mplayer. Ophion is sorely in need of repository updates on these as well as Aegisub, and quadcore optimisations could be interesting, although not too big a difference is for sure.
Ordered Chapters and You
One of the most interesting features of the Matroska container is Ordered Chapters. Admitedly until recently I wasn’t such a big fan of it, due to lack of support for them in linux, or anything other than Haali’s splitter really. I understood the point and found them to be clever and useful (although after using them I disabled it due to not wanting to have to watch the OP of a series at the time) however I never really thought much about how good they are. Recently Kovensky and elenril patched the mplayer PKGBUILD for Ophion, it now has support for ordered chapters.
Ordered chapters are a function of matroska that allows segments of a file to be externally linked. Think of the video file as a php web page for example. Obviously the site looks like 1 big page, but on the server end its a series of php includes to ‘mux’ a bigger file out of. With ordered chapters, segments are linked to allow clips from other files to be included in the main file without it being seen by the viewer. Take for example the DVD rip of Shigofumi I am watching at the moment. The episodes themselves contain the opening scene, the main episode, the ending, and the next episode preview, but no opening theme song. The OP is a separate file, but with ordered chapters in my mplayer, smplayer reads it like one file, along with timestamps and subtitles.
It took a bit of tweaking to get subtitles using the ssa/ass library to work (-correct-pts in mplayer options will fix it) however I’m pretty happy with it now. I haven’t commited the new package to the repository yet, considering making a testing repository, but it all seems fairly solid and stable so far. If anyone would like to try it out, the package can ge found here.
For more information, read what TheFluff has written over on Walls of TL;DR
#Ophion
[09:23:50] <rofflwaffls> mkfifo + wget + mplayer = instant streaming :D
[09:26:09] <Kovensky> uhh…
[09:26:15] <Kovensky> why not just mplayer? :V
[09:26:22] <Kovensky> mplayer can open http:// and ftp://
[09:26:32] <rofflwaffls> uhhh
[09:26:36] * rofflwaffls facepalms
[09:26:43] <rofflwaffls> how did i not think of that
That’s my lulz for today. In other news we moved Ophion to git, I split the 64-bit repo into stable and sandpit on the actual repository, and added a few things, like sx264, a nice little Qt based x264 GUI. 32-bit is not yet updated, so keep that in mind. For 64-bit users, the new syntax is as follows:
[ophion-stable]
Server = http://emess.developersatlarge.com/packages/x86_64/stable[ophion-sandpit]
Server = http://emess.developersatlarge.com/packages/x86_64/sandpit
This should really go on the Ophion development blog but currently it’s not active. Any complaints about gitweb being down can go to rofflwaffls as well, as I didn’t break it.