Hier noch die Antwort von Josh:
Personally, I like to have the git commit that *generated* the STARR in the history. I get nervous with what Eugene does because sometimes intermediate STARRs have no source they can be generated from in the event of emergency. SO, I'd like to two-fer this pull. First you submit a bootstrapping commit, then we make a new star from that and remove the bad implementation for a dummy one.
- Josh
- Dominik
From: Gruntz Dominik
Sent: Donnerstag, 5. Juli 2012 19:20
To: 'Lukas Rytz'
Subject: RE: new starr
here it is:
1) I made a new build and thereby created the jar-files for the compiler and the library
2) Replace the jar files in lib/ with the new jar files
3) make sure that the ant-script does not download the jar files (uncomment that part in the init.jars target of build.xml)
4) recompile the system with the new compiler (in order to run the tests)
5) upload the new jar-files with push-binary-libs.sh (pw required => Josh)
6) The script will upload all modified jars to the typesafe repositories (it takes a while)
7) After the script succeeds, it will update the *.sha files next to the modified jars.
8) Commit the updated *.sha files along with the code.
9) You're done, (re)submit a pull request
Dominik
From: Lukas Rytz [mailto:lukas...@epfl.ch]
Sent: Donnerstag, 5. Juli 2012 19:06
To: Gruntz Dominik
Subject: Re: new starr
ich könnte die erklärung gerade brauchen im moment :)
2012/7/5 Gruntz Dominik <dominik...@fhnw.ch>
ok. Eugene hat es mir erklärt, aber ich habs noch nicht gemacht.
Liebe Grüsse
Dominik
From: Lukas Rytz [mailto:lukas...@epfl.ch]
Sent: Donnerstag, 5. Juli 2012 18:44
To: Gruntz Dominik
Subject: new starr
wenn du herausgefunden hast wie man einen neuen starr baut und veröffentlicht,
wäre es gut das mit einem mail an scala-internals zu dokumentieren - adriaan weiss
zum beispiel auch nicht wie es funktioniert :)
danke
in the meantime I have adjusted my provisional list of tasks necessary to build/upload a new starr to contain the step "ant replacestarr" to build the jar files (instead of simply copying them over)
I agree, when a commit has a new starr, there should be a parent revision that is the source of the starr(not sure if that's always possible, but when it is, it should be done). the commit message should refer tothat parent ("new starr based on abc123").
another thing is that in the past, there used to be a difference between "scala-library/scala-compiler" jarfiles from "pack" and the ones in "starr". not sure what that difference was. to build a new starr, one wassupposed to use the "newstarr" ant target. as far as i'm concerned, we can just use the jars in "pack".
pack contains msil/fjbg and some other minor classes. starr doesn't.On 07/06/2012 11:42 AM, Lukas Rytz wrote:
I agree, when a commit has a new starr, there should be a parent revision that is the source of the starr(not sure if that's always possible, but when it is, it should be done). the commit message should refer tothat parent ("new starr based on abc123").
another thing is that in the past, there used to be a difference between "scala-library/scala-compiler" jarfiles from "pack" and the ones in "starr". not sure what that difference was. to build a new starr, one wassupposed to use the "newstarr" ant target. as far as i'm concerned, we can just use the jars in "pack".
On Fri, Jul 6, 2012 at 11:50 AM, Hubert Plociniczak <hubert.pl...@epfl.ch> wrote:
pack contains msil/fjbg and some other minor classes. starr doesn't.On 07/06/2012 11:42 AM, Lukas Rytz wrote:
I agree, when a commit has a new starr, there should be a parent revision that is the source of the starr(not sure if that's always possible, but when it is, it should be done). the commit message should refer tothat parent ("new starr based on abc123").
another thing is that in the past, there used to be a difference between "scala-library/scala-compiler" jarfiles from "pack" and the ones in "starr". not sure what that difference was. to build a new starr, one wassupposed to use the "newstarr" ant target. as far as i'm concerned, we can just use the jars in "pack".
do you know what's the advantage of keeping them separate?
Size? Not everyone needs msil.jar I guess?On 07/06/2012 11:51 AM, Lukas Rytz wrote:
On Fri, Jul 6, 2012 at 11:50 AM, Hubert Plociniczak <hubert.pl...@epfl.ch> wrote:
pack contains msil/fjbg and some other minor classes. starr doesn't.On 07/06/2012 11:42 AM, Lukas Rytz wrote:
I agree, when a commit has a new starr, there should be a parent revision that is the source of the starr(not sure if that's always possible, but when it is, it should be done). the commit message should refer tothat parent ("new starr based on abc123").
another thing is that in the past, there used to be a difference between "scala-library/scala-compiler" jarfiles from "pack" and the ones in "starr". not sure what that difference was. to build a new starr, one wassupposed to use the "newstarr" ant target. as far as i'm concerned, we can just use the jars in "pack".
do you know what's the advantage of keeping them separate?
Really? How can we call it the "stable reference" if we don't even have stable commits for them? I think not having a commit with Starr sources is a very bad habit we must break. Either that or invest time in regenerating Starr from deployed sources. However, I know Starr doesn't include reflect or compiler src artifacts.
As for newstarr and fjbg, etc. As you may have noticed, these are now always built. I was waiting for a new Starr To remove these jars. As far as the ide is concerned, I think we can fix them up.
I'm slowly cleaning up our process, and we need to be more rigorous about starr.
Historical reasons for not rebuilding was speed. However nit rebuilding in Jenkins was a big issue that's been corrected.
I'm in a situation right now that needs a new starr, but I can't just build the sourcesI need to move the annotation class "scala.cloneable" to "scala.annotation.cloneable".In Definitions.scala, we havelazy val CloneableAttr = requiredClass[scala.cloneable]No matter in which order I do changes, I can't have a set of sources that passes the normalbuild process.- If I move the annotation class, the starr compiler will crash (not find the class)- If I change the compiler source to requiredClass[scala.annotation.cloneable], the lockercompiler will crashI could hack the compiler to search in both places, but we don't want that code to becommitted either.So what I need to do is1. build locker with the modified compiler2. move the annotation class3. build quick, pack, and make a new starr4. push the starr and get the .desired.sha1
I could hack the compiler to search in both places, but we don't want that code to becommitted either.
probably i'm a bit lazy here, but why is it so important to have the starr build reproducible?every revision comes with a "some scala compiler" that is able to build the sources in the repo, and from there you can rebuild everything, includiong a new starr.
Yes. Or we can let them Hang out for a bit and do less frequent Starr releases. That can help reduce the disk space we use for these and help those without Starr repo access get stuff done.
the new compiler sources dorequiredClass[scala.annotation.cloneable]if we have the old library sources (from src/locker/library) on the classpath while buildingthe compiler sources, that new class is not there, so it would not even compile.
You have to leave the old class in place during transition.