oasis

oasis

[Anastasia Gornostaeva]

Hello.

How can I substitute in setup.ml (not in _oasis file) values for
CCOpt and CCLib fields? I think it is better to substitute them from 
setup.data, if I could to put proper values to setup.data.
For example:
  CCOpt: $freetype_ccopt
and put to setup.data output of `freetype-config --clib` for field 
freetype_ccopt.

The expected alternative way:
  $ocaml setup.ml -build --override 'library("library-name").CCOpt' `freetype-config --clib`
does not work, too.

I need a way to substitute paths.

ermine

Re: oasis

[Sylvain Le Gall]

Hi,

On 26-11-2010, Anastasia Gornostaeva <ermine@ermine.pp.ru> wrote:
> Hello.
>
> How can I substitute in setup.ml (not in _oasis file) values for
> CCOpt and CCLib fields? I think it is better to substitute them from 
> setup.data, if I could to put proper values to setup.data.
> For example:
>   CCOpt: $freetype_ccopt
> and put to setup.data output of `freetype-config --clib` for field 
> freetype_ccopt.

As I answer you in private: there will be pkg-config support in 0.3.0.
This will solve this issue, at least.

(e.g. you will be able to define:
BuildDepends: freetype2 (pkg-config), oUnit, ...)

>
> The expected alternative way:
>   $ocaml setup.ml -build --override 'library("library-name").CCOpt' `freetype-config --clib`
> does not work, too.

The override stuff only works for defined runtime variables (ocamlc,
ocamlopt...). 

>
> I need a way to substitute paths.
>

A last solution, you can apply right now, is to override this call:
let () = setup ();;
(last line of setup.ml)

by 

let f pkg = 
  (* Call freetype-config and add flags where 
     needed in pkg
   *)
  ...

let () = BaseSetup.setup (f setup_t);;

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: oasis

[Anastasia Gornostaeva]

On Sat, Nov 27, 2010 at 10:20:38AM +0000, Sylvain Le Gall wrote:
> Hi,
> 
> On 26-11-2010, Anastasia Gornostaeva <ermine@ermine.pp.ru> wrote:
> > Hello.
> >
> > How can I substitute in setup.ml (not in _oasis file) values for
> > CCOpt and CCLib fields? I think it is better to substitute them from 
> > setup.data, if I could to put proper values to setup.data.
> > For example:
> >   CCOpt: $freetype_ccopt
> > and put to setup.data output of `freetype-config --clib` for field 
> > freetype_ccopt.
> 
> As I answer you in private: there will be pkg-config support in 0.3.0.
> This will solve this issue, at least.
> (e.g. you will be able to define:
> BuildDepends: freetype2 (pkg-config), oUnit, ...)

Sorry, but i didnt receive your mail..
And pkg-config probably is not best solution on bsd and macosx systems because
it does not guarante nothing.
The best (and common) solution is CFLAGS and LIBS env variables. :-)
Or this pkg-config will allow custom paths for those C librares that do not
depend on pkg-config at concrete systems?

[...]

> > I need a way to substitute paths.
> >
> 
> A last solution, you can apply right now, is to override this call:
> let () = setup ();;
> (last line of setup.ml)
> 
> by 
> 
> let f pkg = 
>   (* Call freetype-config and add flags where 
>      needed in pkg
>    *)
>   ...
> 
> let () = BaseSetup.setup (f setup_t);;

Interesting way. Thanks, I'll ckeck it right how.

Thanks.

ermine

Re: oasis

[Sylvain Le Gall]

On 27-11-2010, Anastasia Gornostaeva <ermine@ermine.pp.ru> wrote:
> On Sat, Nov 27, 2010 at 10:20:38AM +0000, Sylvain Le Gall wrote:
>> Hi,
>> 
>> On 26-11-2010, Anastasia Gornostaeva <ermine@ermine.pp.ru> wrote:
>> > Hello.
>> >
>> > How can I substitute in setup.ml (not in _oasis file) values for
>> > CCOpt and CCLib fields? I think it is better to substitute them from 
>> > setup.data, if I could to put proper values to setup.data.
>> > For example:
>> >   CCOpt: $freetype_ccopt
>> > and put to setup.data output of `freetype-config --clib` for field 
>> > freetype_ccopt.
>> 
>> As I answer you in private: there will be pkg-config support in 0.3.0.
>> This will solve this issue, at least.
>> (e.g. you will be able to define:
>> BuildDepends: freetype2 (pkg-config), oUnit, ...)
>
> Sorry, but i didnt receive your mail..

I resent it, but it doesn't contains the ultimate solution, just what I
said here.

> And pkg-config probably is not best solution on bsd and macosx systems because
> it does not guarante nothing.
> The best (and common) solution is CFLAGS and LIBS env variables. :-)
> Or this pkg-config will allow custom paths for those C librares that do not
> depend on pkg-config at concrete systems?
>
> [...]

My current state about this solution is:
- defines BuildDepends: freetype2 (pkg-config), to make clear that there
  is a C build-depends
- allow to override the defined variable freetype2_cflags and
  freetype2_libs. If they are both defined by user, don't even call
  pkg-config for this package

>
>> > I need a way to substitute paths.
>> >
>> 
>> A last solution, you can apply right now, is to override this call:
>> let () = setup ();;
>> (last line of setup.ml)
>> 
>> by 
>> 
>> let f pkg = 
>>   (* Call freetype-config and add flags where 
>>      needed in pkg
>>    *)
>>   ...
>> 
>> let () = BaseSetup.setup (f setup_t);;
>
> Interesting way. Thanks, I'll ckeck it right how.
>

As you state privately, this indeed has also problem because you also
need to do it in myocamlbuild.ml.

Here is a new proposal about this:
- use a PostConfigureCommand to invoke a shell script freetype2.sh
- in freetype2.sh invoke freetype-config and output flags in setup.data
  using "echo 'freetype2_cflags = "$output"' >> setup.data' and
  "echo 'freetype2_libs = "$output"' >> setup.data' 
- add in _tags a "src/toto.cma: pkg_config_freetype2" 
- add in myocamlbuild.ml a "tag [pkg_config_freetyp2; compile; ocaml] &
  [... (* load the content of freetyp2_cflags *) ... ]"

This is not simple but this is probably what I will do for the support
of C libraries in 0.3.0.

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: oasis

[Anastasia Gornostaeva]

On Sun, Nov 28, 2010 at 05:17:35PM +0000, Sylvain Le Gall wrote:

> My current state about this solution is:
> - defines BuildDepends: freetype2 (pkg-config), to make clear that there
>   is a C build-depends
> - allow to override the defined variable freetype2_cflags and
>   freetype2_libs. If they are both defined by user, don't even call
>   pkg-config for this package

There should be three variants: pkg-config, OS-based userspace policy 
(/usr/include vs. /usr/local/include) and user-defined one.

> Here is a new proposal about this:
> - use a PostConfigureCommand to invoke a shell script freetype2.sh
> - in freetype2.sh invoke freetype-config and output flags in setup.data
>   using "echo 'freetype2_cflags = "$output"' >> setup.data' and
>   "echo 'freetype2_libs = "$output"' >> setup.data' 
> - add in _tags a "src/toto.cma: pkg_config_freetype2" 
> - add in myocamlbuild.ml a "tag [pkg_config_freetyp2; compile; ocaml] &
>   [... (* load the content of freetyp2_cflags *) ... ]"
> 
> This is not simple but this is probably what I will do for the support
> of C libraries in 0.3.0.

But it is the best solution now and partially works for me.
And please make the functions that loads setup.data and var_get data from it 
to be public. Right now I attempt to play with your code in myocamlbuild.ml 
and re-use it in my piece at bottom of the file.
I'm always ready to test/use oasis from darcs when you put there something new.

ermine

> 
> Regards,
> Sylvain Le Gall
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Re: oasis

[Sylvain Le Gall]

Hello,

On Mon, Nov 29, 2010 at 10:46:22PM +0300, Anastasia Gornostaeva wrote:
> On Sun, Nov 28, 2010 at 05:17:35PM +0000, Sylvain Le Gall wrote:
> 
> > My current state about this solution is:
> > - defines BuildDepends: freetype2 (pkg-config), to make clear that there
> >   is a C build-depends
> > - allow to override the defined variable freetype2_cflags and
> >   freetype2_libs. If they are both defined by user, don't even call
> >   pkg-config for this package
> 
> There should be three variants: pkg-config, OS-based userspace policy 
> (/usr/include vs. /usr/local/include) and user-defined one.
> 

I think the pkg-config is the starting point, it also defines the prefix
of the setup.data variable that we will use.

For you OS-based detection, I can propose a header(XXX), lib(XXX). This
will be cumulative (i.e. you can define several header and lib).

Example:
BuildDepends: 
  freetype2(pkg-config, header(freetype/freetype.h), lib(freetype), >= 2.0.4),
  oUnit

The headers and libs fields are extra methods. If you define
them, we will try to find a set of -Idirs that help to find the
matching headers or a -Ldirs to find the matching libs. 

We will only do a detection using Sys.file_exists (i.e. don't try to
link or anything similar). 

The detection method start with pkg-config and if it fails goes to
headers/libs.

> > Here is a new proposal about this:
> > - use a PostConfigureCommand to invoke a shell script freetype2.sh
> > - in freetype2.sh invoke freetype-config and output flags in setup.data
> >   using "echo 'freetype2_cflags = "$output"' >> setup.data' and
> >   "echo 'freetype2_libs = "$output"' >> setup.data' 
> > - add in _tags a "src/toto.cma: pkg_config_freetype2" 
> > - add in myocamlbuild.ml a "tag [pkg_config_freetyp2; compile; ocaml] &
> >   [... (* load the content of freetyp2_cflags *) ... ]"
> > 
> > This is not simple but this is probably what I will do for the support
> > of C libraries in 0.3.0.
> 
> But it is the best solution now and partially works for me.
> And please make the functions that loads setup.data and var_get data from it 
> to be public. Right now I attempt to play with your code in myocamlbuild.ml 
> and re-use it in my piece at bottom of the file.
> I'm always ready to test/use oasis from darcs when you put there something new.
> 

I not that down, I'll ping you ASAP.

Cheers
Sylvain Le Gall

Re: [Caml-list] Re: oasis

[Anastasia Gornostaeva]

On Mon, Nov 29, 2010 at 09:52:20PM +0100, Sylvain Le Gall wrote:

> > There should be three variants: pkg-config, OS-based userspace policy 
> > (/usr/include vs. /usr/local/include) and user-defined one.
> > 
> 
> I think the pkg-config is the starting point, it also defines the prefix
> of the setup.data variable that we will use.

> For you OS-based detection, I can propose a header(XXX), lib(XXX). This
> will be cumulative (i.e. you can define several header and lib).
> 
> Example:
> BuildDepends: 
>   freetype2(pkg-config, header(freetype/freetype.h), lib(freetype), >= 2.0.4),
>   oUnit
> 
> The headers and libs fields are extra methods. If you define
> them, we will try to find a set of -Idirs that help to find the
> matching headers or a -Ldirs to find the matching libs. 
> 
> We will only do a detection using Sys.file_exists (i.e. don't try to
> link or anything similar). 
> 
> The detection method start with pkg-config and if it fails goes to
> headers/libs.

Excellent. I agree. I hope that default dirs for searching using 
Filename.exists will be defined somewhere not especaiily deeply.

[..]

ermine