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

[Ashley Whetter]

On 2013-09-07 11:34, Ashley Whetter wrote:
> 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

Does anyone have any comments on this? It's going to be difficult for me 
to do much work on it until we at least agree on a resolution to the 
check_build_status problem, if not the layout of the library files as 
well.

Ashley