Date: Wed, 21 Feb 2018 09:44:26 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 226087] GH_SUBDIR fails with nested submodules Message-ID: <bug-226087-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226087 Bug ID: 226087 Summary: GH_SUBDIR fails with nested submodules Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: freebsd-ports-bugs@FreeBSD.org Reporter: FreeBSD@ShaneWare.Biz Created attachment 190852 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D190852&action= =3Dedit Example port Makefile with nested submodules I was experimenting with a new port and found a limitation of the use github subdir feature. It would seem that sub-sub-modules fail. Starting with the base project, some submodules are needed to build it and these work fine. To make the project useful I also need some of the plugins, each of which a= re sepearate github projects and need to be placed within the base projects so= urce tree to compile. One of these also has a submodule that also has submodules, the first one c= an be in place correctly, but when the sub-sub-modules are included, things are not put in the right place. The first submodule installs into plugins/AudibleInstruments and the sub-sub-module should go into plugins/AudibleInstruments/eurorack. What app= ears to happen is the avrlib submodule is first put into place which creates the AudibleInstruments/eurorack folder to position it, then as the AudibleInstruments folder exists, the first submodule gets installed into plugins/AudibleInstruments/AudibleInstruments-v0.5.0 and the eurorack module gets placed into plugins/AudibleInstruments/eurorack/eurorack-916d9620b538, which means the submodules are not placed inside the parent project were th= ey need to be. I can remove the subdir settings for these and manually move them into posi= tion in the post-extract stage and things work as wanted. Expected dir layout - plugins/AudibleInstruments plugins/AudibleInstruments/eurorack plugins/AudibleInstruments/eurorack/avr_audio_bootloader plugins/AudibleInstruments/eurorack/avrlib plugins/AudibleInstruments/eurorack/avrlibx plugins/AudibleInstruments/eurorack/stm_audio_bootloader plugins/AudibleInstruments/eurorack/stmlib Layout achieved using nested GH_SUBDIR - plugins/AudibleInstruments plugins/AudibleInstruments/AudibleInstruments-0.5.0 plugins/AudibleInstruments/eurorack plugins/AudibleInstruments/eurorack/eurorack-916d9620b538 plugins/AudibleInstruments/eurorack/avrlib plugins/AudibleInstruments/eurorack/avrlibx plugins/AudibleInstruments/eurorack/stm_audio_bootloader plugins/AudibleInstruments/eurorack/stmlib To me this appears to be a variation in the order that submodules are processed, I expect the fix would be to sort submodules by path and process them in that order so that parent submodules are always in place before any sub-sub-modules are extracted. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-226087-13>