[Nix-dev] Documentation about different language support?

[Marc Weber]

> Yes.  Or maybe there should be a separate Nixpkgs manual.  In the meantime it
> can also go into nixpkgs/maintainers/docs/.

Thanks. 
If you feel comfortable with this nix-language-specific-implementation.txt
draft file you can add it there. There are still many gaps.
Romeve stuff you don't like/ feel beeing inappropriate.

Marc

=============  =======================================================
# This file is a draft. Move / edit if you feel uncomfortable.
# It serves as a small reference how dependencies are actually passed
# when compiling differenc languages

quote Eelco Dolstra:
" Nix itself doesn't have any support for specific languages, so builders are
  completely free to use any layout they want under $out.  Fortunately, most Unix
  packages have a more-or-less standard layout - "./configure --prefix $out &&
  make && make install" gives pretty predictable results "


C/C++:
=====
  Someone else should fill this gap (niksnut ? ;)
  TODO
  I think some default locations $out/.../includes
  andh $out/.../lib are used. But I would have to look it up.

Haskell:
========
  Ghc
  ---
    A ghc library consists of 
      * interfac files (.hi)
      * static libraries (.a)
      * optionally shared libraries (made from .a) used by the ghci interpreter
    Where ghc/ ghci do find those files is saved in package database files
    (usually package.conf). An empty package.conf file can be generated by writing
    "[]" (empty list) to the file

    The implementation Marc is working on is using the following scheme:
      pkg_conf=$out/nix-support/package-conf
      $out/<default location of installer>/*.hi *.a etc

      ghc-pkg with a pkg.conf file containing the locations is used to register a
      new library.

      By default ghc[i] looks in a system wide and a user library configuration
      file. Additional package configurations can be passed by the environment
      variable GHC_PACKAGE_PATH.

      The package ghcPkgUtil defines exportGHC_PACKAGE_PATH for globbing all
      $buildInputs for package databases.

      Thus 
        source $ghcPkgUtil/nix-support/ghcPkgUtil.sh
        exportGHC_PACKAGE_PATH
      is enough ta make GHC[i] work the dependencies.


      Would you put the hi files into $out/nix-support to not make many
      symlinks? The user hardly ever has to look at them.. And if so he/she
      still can access them within the store.

    Hugs
    ----
      Does nix has already any support ?
      (use cabal ?)

    NHC
    ----
      Does nix has already any support ?
      (use cabal ?)

    JHC
    ----
      Does nix has already any support ?

Perl:
=====
  Someone else should fill this gap (niksnut ? ;)
  TODO

Pascal:
=======
fpc:
----
  Does nix has already any support ?
  TODO
  (When implementing this have a look at how Lazarus manages pluigins)


Java:
=====
  TODO!
  quote from Eelco Dolstra:
  " But for other kinds of
    packages such as Ant-based Java packages there is no standard, and the Java
    packages in Nixpkgs are a bit of a miss in this respect: the JAR files are
    copied to pretty ad-hoc locations.  We should definitely pick some standard
    locations. "
  If you have an proposal write it down here

  Basically dependencies are passed using the CLASSPATH env variable.
  It contains either directories to look for .class files or .jar files which
  are compressed directories with some meta information.

  AFAIK Java is backward compatibility. Thus you can use Java 1.4 (= Version 4)
  libraries with 1.5 (=5). But not the other way.

  I think many Java developers like /have to have multiple versions installed
  simultaniously. 

  Thus I'd propose putting libraries either into
    $out/lib/jar/<compiler version/<library name>

  or beeing more classification.txt and cabal compliant (sort by
  purpose):
    $out/lib/<library name>/<compiler version>/...

  It's getting a little bit more complicated as gcj is able to compile jars/
  class files etc. (But AFAIK they are somewhat behind the current
  developement state of Java).. But it's possible to compile Eclipse .. 
  (Though it did'nt pay off much the last time I have tried this)...

  ...
=============  =======================================================