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, [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 >
Give me a few more days - been busy for the last couple of weeks and I am catching up. Allan
