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@awhetter.co.uk wrote:
From: Ashley Whetter <ashley@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