On 2013-09-07 11:34, Ashley Whetter wrote:
On 2013-09-07 07:40, Allan McRae wrote:
On 06/09/13 08:13, [email protected] wrote:
From: Ashley Whetter <[email protected]>
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
