[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Build-Recommends

On Sun, Jun 12, 2005 at 03:21:54PM +0200, Adeodato Simó wrote:
>   [People from debian-ocaml-mail, please keep -mentors CC'ed.]
> * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]:
> > I could use a 'build-recommends' dependency, 
> > but  I understand 'recommends'
> > is only available for the binary package, not the source.
> > Is this correct?
> > The situation: the packaging machine requires 'ocaml'
> > to make binaries from my source package, but if 
> > 'ocaml-native-compilers' is also installed it will
> > do so faster, however that package is not available
> > on all architectures.
> > This isn't an essential feature, but here is a case,
> > possibly isolated, where it could be useful.
>   Normally, one resolves this and similar situations like this:
>     Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], 
>                    ocaml [m68k mips mipsel s390]

>From a subsequent posting on the list I got the impression that you
have misunderstood the description of the ocaml-native-compilers
package. In fact there are two dimensions to consider when you talk
about "native code compiler":

- does the compiler produce byte code or native code?
- is the compiler itself a byte code executable or a native code

The package "ocaml-native-compilers" provides ocaml compilers
(both to byte code and native code) which are themselves 
machine code executables. Their advantage over byte code
executables is that they are faster, their disadvantage is
that they may take longer to load. 

If you want to say in your package control file to depend
on the fastest available compiler on any architecture then
your should depend on "ocaml-best-compilers" which is a virtual
package provided by "ocaml-best-compilers" on architectures
where it exists, and provided by ocaml on the other architectures.
If you want to use this then the makefile should be able to
call the *.opt executables when they are present on the system.

However, if you want to have a finer control over the *target* of the
compilation (byte code or machine code) then I guess the only way 
is to patch the makefile, or do an appropriate test in the 
debian/rules file.


Reply to: