Re: splitting ocaml-native-compilers
On Thu, Jan 17, 2002 at 04:45:21PM +0100, Judicaël Courant wrote:
>
> >
> > Ok,first argument is the lazyness of debian packagers.
>
> Right. This is possibly an ennoying fact, but this is a *real* fact (you
> can also add the ignorance of debian packagers --- there are two many
> possible things to know all of them). Disregarding facts about human
> nature in software engeenering leads to failure IMHO.
But then, most maintainer using the .opt compilers should know what it means.
Anyway, for the forseeable future it is only yuou and coq who are implied
here. And then it is a balance between my own lazyness and yours, ...
> > > ocaml-native-compilers, but also I will have to take some time to make a
> > > new release of my package if my package is arch-dependent. People will
> > > benefit on this new arch only when both have been done. By contrast, if
> > > my package is arch-independent, they will benefit from the new arch as
> > > soon as it is added to ocaml-native-compilers.
> >
> > Mmm, maybe a conditional build depend would be nice.
>
> What do you mean by conditional build depend?
Well, a build depend that is only fullfileled if the package exists for a
given arch.
Or maybe a build depends that get the list of supported arches from the ocaml
package.
Like said, maybe providing ocaml.opt as a virtual package in ocaml for the
arches that don't support the ocaml.opt package could be the better idea, than
an empty package. I will have to check that it is possible though.
It still is not elegant.
> > > 3) this will be less work for you: make ocaml-native-compilers available
> > > on any platform. Just do an "make opt.opt || true". Then if the arch is
> > > not supported, the package will just contain no binary. This way, you do
> > > not even need to know precisely which arch are supported: when there is
> > > a new upstream release, just make it available, if a new arch is
> > > supported, the binary will be available to the user.
> >
> > No, it will be more work for me. The current implementation is easier.
> >
>
> I do not understand why?
i move the files with dh_movefiles in to the new package. To do otherwise i
would have to test the build and do the dh_movefiles only if the files get
build, not that difficult, but more work than just producing the package as i
do now for supported arches.
But again, my main objection, is that an empty package is _not_ the right
thing to do ... At least i feel such for now.
> > > On the other hand, I see two potential problems with this
> > > 1) make opt.opt might fail on a supposedly supported arch. If you
> > > silently ignore the error, you will not detect the problem immediately.
> > \
> > YEs, like the ia64 case right now.
> >
>
> Right. However, I forgot to mention that this can also be seen as an
> advantage: the package will still be available (otherwise it is
> unavailable until the problem is fixed). Consider for instance the case
> of termination of support for m68k.
Mmm, then you build the bytecode version, what is the problem with that ?
Remember, i was advocating the build of both byte and native code versions for
all packages, in separate binary packages, but you don't liked it ...
But again, here the problem is different, notice i don't splitted ocamlopt,
only ocaml*.opt, so you should always build the native code version with
ocamlopt, if available. The only thing that changes is the compile time on the
boxes where the .opt compilers are present, which would not make any
difference for the faster arches that support native code anyway. For arm it
may be a big boon though.
This is somethingthat can be enabled by hand though.
The main reason not to do such is that a rebuild can be heavy for the slower
arches (m68k and arm mostly) especially if they are not affected by it.
For that we weould have to check if the arch specific build version works and
supports some small changes to the source file, which i am not sure it does.
> > Anyway, i guess there will, in the forseable future, only be coq with such
> > problems,
>
> Why? From my experience, Coq is a very good bench for discovering what
> the next problems of the caml users will be (we had several times some
> problems with Caml we were the only one to have, then some months later
> it appeared that others also had the same problem --- we had only a
> slight advance...).
Because, it only makes a difference for very huge applications, and i only
know of coq that meets this criteria in debian. Even Xavier said so, (well he
said also something like there are ever people with very slow boxes around),
and then there is the issue of load time (native code is often slower to load)
versus optimized compiler gain.
And again, only the autobuilder will benefit from it, since you will build the
native code version with ocamlopt if ocamlopt.opt is not available.
> > and anyway, most probably therte will be a new release of coq when
> > there is a new release of ocaml wityh new arches.
>
> Yes there is often a new release of Coq when there is a new release of
> OCaml but
>
> 1) this is not always the case (no Coq release for 3.02 unless I am
> wrong, and none for 3.03alpha).
Well, there was also no new supported arch for 3.02, and 3.03alpha was a alpha
release, so the new coq release is the one for 3.04.
> 2) you miss the point that the list of supported architectures changes
> over time: I want my Coq package to work with as much ocaml versions as
well, it has not changed since a long time.
> possible. In testing, ocaml is 3.02 for the moment. As I wanted Coq to
> enter testing as soon as possible, I take care not to make it depend on
> ocaml-3.04 (I do not know when ocaml-3.04 will be in testing). So I will
Your error, i don't know coq, but i would not recomment it at all.
It is also against the recomendation of the ocaml team.
But then, it is you who will suffer from the consequences.
> not take the risk to put a dependency over a specific architecture
> unless this is really needed. So if I cannot take advantage of
> ocamlopt.opt without mentionning specific architectures, well I regret I
> will not take advantage of it...
Mmm, why not ?
Is this just an emotional decision, or would it be possible to convince you
otherwise ?
Let's discuss this further, as even myself am not so sure about what is the
best thing to do here.
That said, even if you are right in this, the pseudo package my not be the
best solution to this.
Friendly,
Sven Luther
Reply to: