Switching to split repos

[Mohaned Y Qunaibit]

Works great now
Thank you

Best,
Mohaned Qunaibit

On Wed, Jul 29, 2015 at 8:45 AM, Gilles Duboscq <gilles.m.duboscq at oracle.com
> wrote:

> Yes, those urls should be fixed soon (commit should be there in today's
> batch)
>
>  Gilles
>
> On 29/07/15 17:15, Christian Wimmer wrote:
> > The repository URLs on lafo start with "http", not "https".
> >
> > -Christian
> >
> >
> > On 07/29/2015 01:39 AM, Mohaned Y Qunaibit wrote:
> >> Hi,
> >>
> >> I tried to clone the new graal but both dependencies in
> mx.graal/suite.py
> >> (JVMCI and Truffle) repos require authentication:
> >> https://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-8
> >> https://lafo.ssw.uni-linz.ac.at/hg/truffle-mx2
> >>
> >> Also, if I choose binaries, I get a message that they do not exist
> >>
> >> Should I get back to an early revision of graal-compiler?
> >>
> >> Best,
> >> Mohaned Qunaibit
> >>
> >> On Fri, Jul 24, 2015 at 7:27 AM, Doug Simon <doug.simon at oracle.com>
> >> wrote:
> >>
> >>> To better reflect the different technologies within the Graal stack, we
> >>> will soon be switching to disjoint repositories. This will allow one to
> >>> focus on a smaller code base and treat other parts of the stack as
> >>> external
> >>> dependencies.
> >>>
> >>> The new repositories replacing http://hg.openjdk.java.net/graal/graal
> >>> (“old graal") are:
> >>>
> >>> http://hg.openjdk.java.net/graal/graal-jvmci-8  (JVMCI and HotSpot
> code
> >>> from old graal based on JDK8)
> >>> http://hg.openjdk.java.net/graal/graal-jvmci-9  (JVMCI and HotSpot
> code
> >>> from old graal based on JDK9)
> >>> http://hg.openjdk.java.net/graal/graal-compiler (old graal minus
> >>> graal-jvmci-8)
> >>> https://bitbucket.org/allr/mx                   (updated, standalone
> mx
> >>> that works with split repos)
> >>>
> >>> The http://hg.openjdk.java.net/graal/graal has already been removed
> but
> >>> its mirror at https://github.com/OracleLabs/GraalVM <
> >>> https://github.com/OracleLabs/GraalVM is still live.
> >>>
> >>> While there is already content mirrored at these repos, do not pull
> from
> >>> them (unless you want untested changes that may not yet work). A
> >>> follow-up
> >>> email will be sent (within the next week) once you can pull from them.
> >>>
> >>> The first step in switching to the split repos is to pull mx:
> >>>
> >>> $ hg clone https://bitbucket.org/allr/mx
> >>>
> >>> Since mx is now a standalone tool, it locates the ‘primary’ suite (i.e.
> >>> the repo you are primarily working on) based on the current working
> >>> directory instead of the location of mx. If you are within a repo
> >>> directory
> >>> hierarchy, that repo is the primary suite. Otherwise, you will need
> >>> to use
> >>> the —primary-suite-path or -p option.
> >>>
> >>> By default, mx will pull dependent repos and place them as siblings of
> >>> your primary repo so it’s highly recommended to start in an empty
> >>> directory. For example:
> >>>
> >>> $ mkdir graal-compiler-workspace
> >>> $ cd graal-compiler-workspace
> >>> $ mx sclone http://hg.openjdk.java.net/graal/graal-compiler graal
> >>> $ ls -1
> >>> graal
> >>> jvmci
> >>>
> >>> Note the directory names are determined by the information in
> >>> suite.py for
> >>> each suite, not by the URL it was pulled from (except for the primary
> >>> suite
> >>> where the name or URL given to the sclone command is used).
> >>>
> >>> Mx has some new commands that simplify working with split repos.
> >>> These are
> >>> briefly described below in terms of changes to standard workflows. More
> >>> extensive documentation is at
> >>> https://bitbucket.org/allr/mxtool2/wiki/Home
> >>> .
> >>>
> >>> 1. Update to the newest version
> >>>
> >>> old:
> >>> $ hg pull
> >>> new:
> >>> $ mx spull
> >>>
> >>> 2. Make a cross-repo change
> >>>
> >>> in the jvmci repo:
> >>> do the changes
> >>> $ hg commit -m "..."
> >>> in the graal repo:
> >>> $ mx scheckimports
> >>> do the merge fixes (if any)
> >>> $ hg commit -m "update imports"
> >>>
> >>> Mx also imposes some changes on suite.py files
> >>>
> >>> 1. There is an “imports” section (which should be mostly self
> >>> explanatory)
> >>> for specifying the suite dependencies.
> >>> 2. Inter-suite references can now only be to distributions and
> libraries
> >>> and must be prefixed with the suite name (e.g., “jvmci:JVMCI_API”).
> >>> 3. Annotation processors (APs) must now be distributions (see 2.).
> >>> 4. A distribution must explicitly declare all of the distributions it
> >>> depends on in its “distDependencies” attribute.
> >>>
> >>> These constraints make suite.py files more intuitive. Some of them are
> >>> also necessary to support importing suites as binaries. Binary suites
> >>> allow
> >>> one to use pre-built binary versions of the dependencies of a
> >>> repository.
> >>> This can be useful when only read access to the sources is required.
> >>>
> >>> Currently, importing source suites is the default. Using binary
> >>> dependencies instead can be enabled using the MX_BINARY_SUITES
> >>> environment
> >>> variable (which can be persisted in mx.<primary suite name>/env).
> >>> This is a
> >>> comma-separated list of the suites for which binaries should be used.
> >>> For
> >>> example:
> >>>
> >>> MX_BINARY_SUITES=jvmci
> >>>
> >>> One other change is that mx no longer looks for ecj.jar in the mx dir
> of
> >>> the primary suite. It needs to be explicitly supplied with the --jdt
> >>> option
> >>> to the build command or with the JDT environment variable.
> >>>
> >>> While we will try to ensure everything is working on the switch over
> >>> date,
> >>> there’s bound to be a few bumps in during this transition. The best
> >>> way to
> >>> get issues resolved is to ask on this list (graal-dev at openjdk.java.net
> ).
> >>>
> >>> -Doug
>