[pacman-dev] libmakepkg layout - Was: [PATCH v2 0/4] Splitting up makepkg into libmakepkg

[Ashley Whetter]

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 
>> libmakepkg/download/*.sh).
>> 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 
>> reduced
>> 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:
> https://wiki.archlinux.org/index.php/User:Allan/Makepkg_Split
> 
> Allan

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 
dependency somehow?".

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 
utilities.


Ashley