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

[Allan McRae]

On 16/09/13 20:58, Ashley Whetter wrote:
> 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
> 

Give me a few more days - been busy for the last couple of weeks and I
am catching up.

Allan