On 25 March 2012 16:03, c. <carlo.defa...@gmail.com> wrote: > On 25 Mar 2012, at 16:56, Juan Pablo Carbajal wrote: >> 2012/3/25 c. <carlo.defa...@gmail.com>: >>> >>>>> 1 - change the PKG_ADD in the packages >>>>> >>>>> 2 - patch pkg.m to handle subdirectories in a better way >>>>> >>>>> 3 - forbid the use of subdirectorues in packages >>> >>> On 25 Mar 2012, at 14:43, Carnë Draug wrote: >>>> The idea of having this subdirectories is a matter of organization for >>>> the package developers right? (Since upon package installation, the >>>> user can only load either all or none of the package anyway). If >>>> that's the case, I'll suggest a 4th option (maybe only temporary while >>>> we can't anything better) that is to have all the subpackages in a >>>> inst/ directory. >>>> The source tree can differ from the tree of the >>>> actual release, I believe that is acceptable. >>> >>> I don't exactly understand your suggestion. >>> If you suggest that pkg.m should install all >>> subdirectories of /inst, that is already the case, >>> but adding them to path is not done automatically yet, >>> option 2 was to patch pkg in order to do this. >>> >>> If you suggest that files be all copied in the same >>> directory upo install, that is essentially option 3. >>> >>> which one would you like better? >>> >> >> Hi >> Carlo, what Carnë suggest is not as forbidding as option 3. He >> basically says that for development you can keep the subfolder >> structure, but at the install time you destroy that tree and add >> everything under /inst. So, multipackages are allowed, but the >> installed version looks just as any other package; everything merge >> together. >> Geometry and Mechanics were like that not long ago, but the installed >> version looks really ugly... > > I see, this soultion is very simple but requires more work from the maintainer > when a package is released. maybe that work coud be done automatically by > adding some > extra logic in the pre_install script?
That's what I meant. But I don't think such situation would demand much more from the package mantainer, a perl script could be easily cooked that would deal with the mutiple inst/ files. The only problem would be with mutiple src/ and but unless the package has complex Makefile, it shouldn't be much more work to adjust it at release time. Carnë ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
