Re: ocaml && cdbs

[Sylvain Le Gall <gildor@debian.org>]

Hello,

On 12-10-2006, Stefano Zacchiroli <zack@debian.org> wrote:
> On Wed, Oct 11, 2006 at 10:06:42PM +0000, Sylvain Le Gall wrote:
>> - is it possible to add an OCAML_TEAM substitution in control.in (just 
>>   as GNOME_TEAM), it will help us keep the team list complete for every
>>   team package,
>
> Done in the cdbs class on svn (not tested though, please do so and check
> if I put all the names in OCAML_TEAM :-)).
>

Very well... But how do you define which is part of OCaml team (all
members of pkg-ocaml-maint on alioth, all maintainer of an ocaml
package...).

I think we should begin by the list you give, and add people who ask for
it...

>> - is it possible to make the ocamlinit target a little more general. For 
>>   some of my package, i need to do some more substitutions (like in unison),
>
> Hard to say if you don't explain as which additional kind of
> substitution you need :-)
>

Well, in unison package you will replace :
          sed -e "\
          s/@VERSION@/$(VERSION)/g; \
          s/@PACKAGE_VERSION@/$(PACKAGE_VERSION)/g; \
          s/@PRIORITY@/$(PRIORITY)/g; \
          s/@UNISON@/$(UNISON)/g; \
          s/@UNISON_MAJ@/$(UNISON_MAJ)/g; \
          s/@UNISON_PACKAGE@/$(UNISON_PACKAGE)/g; \
          s/@UNISON_ALTERNATIVE@/$(UNISON_ALTERNATIVE)/g; \
          s/@UNISON_GTK@/$(UNISON_GTK)/g; \
          s/@UNISON_GTK_PACKAGE@/$(UNISON_GTK_PACKAGE)/g; \
          s/@UNISON_GTK_ALTERNATIVE@/$(UNISON_GTK_ALTERNATIVE)/g;" 

So it should be nice, to be able to have some kind of :
IN_SUBST += s/@VERSION@/$(VERSION)/g;
IN_SUBST += s/@PRIORITY@/$(PRIORITY)/g;

sed -e $(IN_SUBST) ...

>> - is it possible to add OCAML_STDLIB_DIR to ocamlinit,
>
> Assuming you mean "is it possible to make ocamlinit substitute
> OCAML_STDLIB_DIR as well as OCAML_ABI" ..., then my answer would be:
> yes, it is possible, but why you need that? After all OCAML_STDLIB_DIR
> is always the same besides the content of OCAML_ABI. Maybe you're trying
> to support packages which in the future will be installed in different
> OCAML_STDLIB_DIRs (and that would be good!) ... Could you please expand
> on the topic?
>

Well i will return you the question. Since OCAML_STDLIB_DIR could be
deduce from OCAML_ABI, why do you define the variable OCAML_STDLIB_DIR ?
;-) 

Speaking on a more serious matter, i think OCAML_STBLIB_DIR is at least
the more commonly used variable and could be a very useful substitution.
(I remember last year to have converted my package to dynamically create
directory using this variable, using a substituion will really simplify
all this).

Regards,
Sylvain Le Gall