tech-pkg archive

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

Re: Adding kerTeX; but needs avoiding configure etc. writes:

> KerTeX uses my own building framework: R.I.S.K. doing all including lib
> dance and being designed natively with cross-compilation in mind.
> I hence have to add two things:
> - R.I.S.K. related mk files
> - and kerTeX using the previous files (that is kerTeX_M for compilation
> tools on the Matrix and kerTeX_T for compilation for the Target).
> How can one add a framework to mk machinery and, before all, avoid like
> the plague any autoconf/config/automake/libtool intervention?

Hard to say without digging in, but pkgsrc does not require autotools.
It merely has support for running them, and has support for running
various other things.

Support for a build system can be:

  in files under mk/, such that you don't need to .include anything, and
  you just set variables.  We do this for autoconf, and maybe cmake.

  in a file under mk/, where you have to .include it

  in a package, so you ".include ../../devel/RISK/" and then set
  variables, in packages that are built using the framework, after
  having installed devel/RISK to put whatever scripts/host tools are
  needed in place (more or less, without reading)

Given that this system appears to be used only in kerTeX, I'd suggest
thethird option.

  BTW, since there is a TeXlive discussion going on, kerTeX solves
  the problem at a different level: kerTeX is a hosted system; TeX
  related packages are its problem not the problem of the host. There
  is a packaging system for kerTeX allowing to add LaTeX and etc. to
  the core, "kernel" system (hence the name with a word play between
  ker(nel) and "care"). So there is only one (in fact two for
  cross-compilation) package for TeX the additions being handled by the
  TeX hosted system.

This is not the pkgsrc way; we package things in python and perl instead
of letting e.g. pip install them.  So you should think about where the
stuff that's installed by the installed kerTeX package is going to go,
and basically it should not go in the noraml prefix dirs as those are
owned by pkgsrc.  But if you have a /usr/pkg/?/kerTeX that they go in,
that doesn't seem problematic from a pkgsrc viewpoint.  (You'll need to
think about if a user installs these for themselves, without privs, or
if root has to, and if the packages are system-wide or per-user, etc.  A
lot of that can be avoided in a personal install.)

You should feel entirely free to start in pkgsrc-wip, where it's ok to
add packages that don't work, break norms, etc., without any review.   I
tend to do that myself until I get something working.

Home | Main Index | Thread Index | Old Index