I tried to build from sources (changeset 784) and got an error compiling testSys. Since the compiler pods where created just before, I think my environment is OK now :) The error is on the line 102 of UnitTest.fan:
Since testSys is the first pod compiled with the new compiler I suspect something wrong with it...
Side notes:
Is there a Bug report system somewhere?
Do you usually build/use only the .NET compiler, or always both (when micro testing)?
brianFri 9 Jan 2009
Is there a Bug report system somewhere?
For right now just submit bugs here (the eventual plan is they will still come in as discussion items, then get "tagged" as issues similar to how the blogs work).
Do you usually build/use only the .NET compiler, or always both (when micro testing)?
I typically do a "buildall full test" before/after a sync with the repo which fully builds everything include .NET, but only runs test suite on Java (Andy does the .NET stuff). If you aren't on Windows, then "buildall full" skips the .NET stuff.
During development I typically just rebuild/test the individual pod I'm working on such as "build foo compile test".
The error is on the line 102 of UnitTest.fan:
That error would indicate that sys::Unit isn't being recognized as a type name. Since I've added that class since the last full build, I would suspect that sys.pod isn't being correctly compiled.
to the build.fan solved the issue, but of course the next build fails. Did not find a way to set dependsDir globally :(
So, now that I know it's my environment, I will continue to investigate... Thanks.
brianSat 10 Jan 2009
to the build.fan solved the issue, but of course the next build fails. Did not find a way to set dependsDir globally
No you don't need to set that - to do a full bootstrap build doesn't require changing anything "lib/sys.props" and an environment variable for Mac/Linux.
Bootstrap building still seems to be an issue, so we still have some work to do to make it easier.
tompalmerSat 10 Jan 2009
Bootstrap should only require referencing a prebuilt compiler (and full Fan system) to use when building the new one. Just referencing the command elsewhere should be enough. My own 2 cents.
brianSat 10 Jan 2009
Just referencing the command elsewhere should be enough.
The core of the issue is that Fan scripts run the build. But you can only set one fan launcher in your path at a time (you can have more, but first one in the path always wins). You need the released Fan runtime to build sys, compiler, and build. But then you want to switch to your development environment to compile the rest (so that they use the new sys, compiler, and build).
So the problem isn't really characterized as selecting a compiler, it is really best characterized as selecting a runtime for a given script. On Unix this what the FAN_SUBSTITUTE env var does, and on Windows's we do it sys.props.
If someone can suggest an easier way to set it up, I always love to make things simpler. I do have an idea I'm going to try out this morning for debugging.
freddy33Sat 10 Jan 2009
Yep, that's my issue. The fansubstitute should stop, and it does not. Keep using sys from previous release :( I'm going to see what I can do, but I have a couple of questions:
The build does not fail when dependencies declared in build.fan are not resolved. Is it true? Can it be done?
What is the reason (need/feature) for the dependsDir variable?
Keeping you updated on what happen for me.
brianSat 10 Jan 2009
The build does not fail when dependencies declared in build.fan are not resolved. Is it true? Can it be done?
The build will fail if a dependency cannot be met, you will see something like this:
build.fan: Cannot resolve depend: pod 'foo' not found
The issue here sounds like testSys is resolving its dependency against the released installation, not the one you pulled from hg. Which is why you don't see sys::Unit (since it was added since the last build).
What is the reason (need/feature) for the dependsDir variable?
It is only used by the build and compiler build scripts so that they compile against the development version of sys (versus the environment being used to run the compiler). As a general rule don't ever touch that - I will add a note in the fandoc.
freddy33Sat 10 Jan 2009
Thanks to the new "dumpenv" target provided by Brian, I found out that the environment switch between buildboot.fan and buildpods.fan works when executed separately but not when using buildall.fan.
So, for info:
FAN_HOME is less important than which "fan/bin" folder is in your path.
Running "./buildall.fan clean && ./buildboot.fan full test && ./buildpods.fan full test" works for me.
Looking at the way the fansubstitute shebang is executed I don't see how to solve the issue :(
Hope it helps.
PS: Still got 3 tests failures for web, but not too worry about this :)
brianSun 11 Jan 2009
It has been about a month, so I'll probably do a build shortly with the new "dumpenv" build script target.
The test failures are in the new WebClient API - I am using google as a test site, and I think the tests fail outside the US due to redirects. I added support to automatically follow redirects in those tests, so hopefully they will work outside the US now.
freddy33 Fri 9 Jan 2009
Hi, First Bravo for the amazing Job!
I tried to build from sources (changeset 784) and got an error compiling testSys. Since the compiler pods where created just before, I think my environment is OK now :) The error is on the line 102 of UnitTest.fan:
Error Log:
clean [testSys] compile [testSys] Compile [testSys] FindSourceFiles [53 files] /work/fan/fan/src/testSys/fan/UnitTest.fan(102,29): Expected expression, not ']' BUILD FAILED [1728ms]! Error: Exec failed [/work/fan/fan/bin/fan /work/fan/fan/src/buildpods.fan full] BUILD FAILED [17112ms]!Since testSys is the first pod compiled with the new compiler I suspect something wrong with it...
Side notes:
brian Fri 9 Jan 2009
For right now just submit bugs here (the eventual plan is they will still come in as discussion items, then get "tagged" as issues similar to how the blogs work).
I typically do a "buildall full test" before/after a sync with the repo which fully builds everything include .NET, but only runs test suite on Java (Andy does the .NET stuff). If you aren't on Windows, then "buildall full" skips the .NET stuff.
During development I typically just rebuild/test the individual pod I'm working on such as "build foo compile test".
That error would indicate that
sys::Unitisn't being recognized as a type name. Since I've added that class since the last full build, I would suspect that sys.pod isn't being correctly compiled.freddy33 Fri 9 Jan 2009
I'm building on Mac with JDK 1.6.
I saw that the compiler had:
and the testSys not! So adding:
to the build.fan solved the issue, but of course the next build fails. Did not find a way to set dependsDir globally :(
So, now that I know it's my environment, I will continue to investigate... Thanks.
brian Sat 10 Jan 2009
No you don't need to set that - to do a full bootstrap build doesn't require changing anything "lib/sys.props" and an environment variable for Mac/Linux.
Are you following the instructions in docTools::Bootstrap?
Bootstrap building still seems to be an issue, so we still have some work to do to make it easier.
tompalmer Sat 10 Jan 2009
Bootstrap should only require referencing a prebuilt compiler (and full Fan system) to use when building the new one. Just referencing the command elsewhere should be enough. My own 2 cents.
brian Sat 10 Jan 2009
The core of the issue is that Fan scripts run the build. But you can only set one fan launcher in your path at a time (you can have more, but first one in the path always wins). You need the released Fan runtime to build sys, compiler, and build. But then you want to switch to your development environment to compile the rest (so that they use the new sys, compiler, and build).
So the problem isn't really characterized as selecting a compiler, it is really best characterized as selecting a runtime for a given script. On Unix this what the FAN_SUBSTITUTE env var does, and on Windows's we do it sys.props.
If someone can suggest an easier way to set it up, I always love to make things simpler. I do have an idea I'm going to try out this morning for debugging.
freddy33 Sat 10 Jan 2009
Yep, that's my issue. The fansubstitute should stop, and it does not. Keep using sys from previous release :( I'm going to see what I can do, but I have a couple of questions:
Keeping you updated on what happen for me.
brian Sat 10 Jan 2009
The build will fail if a dependency cannot be met, you will see something like this:
The issue here sounds like testSys is resolving its dependency against the released installation, not the one you pulled from hg. Which is why you don't see sys::Unit (since it was added since the last build).
It is only used by the build and compiler build scripts so that they compile against the development version of sys (versus the environment being used to run the compiler). As a general rule don't ever touch that - I will add a note in the fandoc.
freddy33 Sat 10 Jan 2009
Thanks to the new "dumpenv" target provided by Brian, I found out that the environment switch between buildboot.fan and buildpods.fan works when executed separately but not when using buildall.fan.
So, for info:
Looking at the way the fansubstitute shebang is executed I don't see how to solve the issue :(
Hope it helps.
PS: Still got 3 tests failures for web, but not too worry about this :)
brian Sun 11 Jan 2009
It has been about a month, so I'll probably do a build shortly with the new "dumpenv" build script target.
The test failures are in the new WebClient API - I am using google as a test site, and I think the tests fail outside the US due to redirects. I added support to automatically follow redirects in those tests, so hopefully they will work outside the US now.