[pacman-dev] libmakepkg layout - Was: [PATCH v2 0/4] Splitting up makepkg into libmakepkg
ashley at awhetter.co.uk
Sat Sep 7 06:34:18 EDT 2013
On 2013-09-07 07:40, Allan McRae wrote:
> On 06/09/13 08:13, ashley at awhetter.co.uk wrote:
>> From: Ashley Whetter <ashley at awhetter.co.uk>
>> This time around I've split up amekpkg as per Allan's recommendation,
>> and put
>> each function into it's own file.
>> There's a file at the base of each libmakepkg directory that imports
>> that part
>> of the library. (eg libmakepkg/download.sh imports
>> Instead creating a file that imports every part of the library, I've
>> instead put
>> the for loop straight into makepkg.sh.in.
>> Each libmakepkg file has it's own inclusion guard.
>> Each libmakepkg copyright notice was deduced from the full set,
>> dependent on
>> what years git blame said that each line of a function had been
>> written in.
>> I feel like the scripts Makefile is getting a bit cluttered.
>> Even the number of .sh.in files is getting a bit big. This could be
>> by not using LIBRARY in every libmakepkg file and using relative
>> imports instead,
>> but this seems like even less of a good idea.
>> I'm not really sure if/how we want to get rid of this issue.
> OK - definitely too much splitting...
I mentioned this on IRC while I was doing it and I totally agree.
> I wanted the download_foo functions to be in individual files are they
> are fairly substantial functions. But thinks like the message
> functions that are four lines do not need split.
> So lets work on a layout before we go further. Here is a start:
I disagree with util/source.sh going into util. The source array is part
of a PKGBUILD so I think it might be worth having a separate
libmakepkg/pkgbuild folder, and putting source.sh and pkgbuild.sh in it.
I definitely agree with grouping the download and extract functions
together. It makes more sense, and adding a new VCS target will mean
creating only one new file.
To move out the extraction functions we'll also need to address
extract_sources calling the check_build_status function. I originally
grouped check_build_status into a makepkg specific part of the library.
We could put check_build_status into libmakepkg/makepkg.sh (or is this
what libmakepkg/packaging.sh is for?). I don't think makepkg.sh should
go into the util folder because it's not a "generally useful" function,
but specific to the functionality of makepkg.
Also to quote something I said in my original grouping proposal
"extract_sources to check_build_status is the only dependency between
'sources' and 'makepkg'. I feel like it's worth getting rid of this
check_build_status also depends on get_full_version. "I think
get_full_version is a PKGBUILD specific function, but run_function (in
utils) depends on it to create the log file. Maybe logging stuff could
be split into another [part of the] library?".
check_build_status also depends on install_package. I originally put
install_package in makepkg.sh/packaging.sh because although it was
calling pacman, it was generating the location of the generated package
file (something which is specific to makepkg) to pass onto pacman. So I
didn't think it made sense to put it into dependencies.sh unless we
passed it a list of package files to install.
install_package depends on run_pacman. I still think it makes sense to
put this into libmakepkg/util/dependencies.sh.
Minor side note: Are we calling util "utils" or "util"? I keep writing
utils then correcting myself, but it should be plural as it's a set of
More information about the pacman-dev