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

Reply via email to