- Goals
- User guide
- Classlib developers guide
- Developer guide
- Tester guide
- Porting guide
- Blogs
- Project development
- Glossary
- Proposals
- FAQ
- Papers & presentations
- References
- Research
Build process
The build process of JNode consists of the following steps.
- Compilation - Compiles all java source to class files.
- Assembling - Combines all class files into a jar file.
- Boot image building - Preloads the core object into a bootable image.
- Boot disk building - Creates a bootable disk image.
- CD-ROM creation (optional) - Creates a bootable CD-ROM (iso) image
Boot image building
When JNode boots, the Grub bootload is used to load a Multiboot compliant kernel image and boot that image. It is the task of the BootImageBuilder to generate that kernel image.
The BootImageBuilder first loads java classes that are required to start JNode into there internal Class structures. These classes are resolved and the most important classes are compiled into native code.
The object-tree that results from this loading & compilation process is then written to an image in exactly the same layout as an object in memory is. This means that the the necessary heap headers, object headers and instance variables are all written in the correct sequence and byte-ordering.
The memory image of all of these objects is linked with the bootstrapper code containing the microkernel. Together they form a kernel image loaded & booted by Grub.
Boot disk building
To run JNode, in a test environment or create a bootable CD-ROM, a bootable disk image is needed. It is the task of the BootDiskBuilder to create such an image.
The bootable disk image is a 16Mb large disk image containing a bootsector, a partition table and a single partion. This single partition contains a FAT16 filesystem with the kernel image and the Grub stage2 and configuration files.
- Printer-friendly version
- Login to post comments
build directory path
A recurring problem with people trying to build under windoze is that if the directory path where the sources are contains spaces, nasm will fail to compile. So don't use "Documents and settings"...
steve : delete that comment ?
As said here, that should be fixed because the issue is marked as closed. But I can't find the fix in all/build.xml. So, I assume I am not searching for the right thing / in the right place ... unless the fix has been removed for some reason.
Fabien
my blog : en français, in english or both
Book page update not needed here.
The Build & development environment page already warns you not to put spaces in the sandbox directory name on Windows. I don't think we need to repeat the warning on this page as well.
The missing fix.
The fix went into all/build.xml in revision 4045, and then disappeared in revision 5179 with no explanation in the svn log.
http://jnode.svn.sourceforge.net/viewvc/jnode/trunk/all/build.xml?r1=506...
If Levente has no objection (he committed 5179) we should reapply the fix.
Either way, I'll add a note to the Book page to say that spaces in the pathname are a bad idea. Then we can purge these comments.
The section removed from the
The section removed from the build.xml checks the presence of spaces in the pathname. Since as far as I could see only mkisofs was affected by this problem and we don't use it any more by default there is no need to make the build fail when the pathname contains spaces. So the patch was deprecated and it's needles to reapply it.
I think we should reapply the patch because ...
... (until JNasm will be fully working) we are still using nasm(w).exe and I guess the problem will still happen.
Can someone confirm that's still a problem under Windows ?
Fabien
my blog : en français, in english or both
IMO, reapply it.
I think the patch should be reapplied as a defensive measure, and stay there whether or not we are (currently) using any native apps in the Windows build. The chances are that we will use a native app at some point in the future, and then some new user will run into the spaces-in-pathname problem yet again.
If a Windows user really needs to use pathnames with spaces in them, it should be a simple matter for them to comment out the check.
The patch is definetly
The patch is definetly harmful if it doesn't report a real problem. It should be avoided that the build could work normally but the patch with the extra check doesn't allow it to work. If a tool makes the build fail then it will fail anyway and that won't be a 'false positive'. I think most programs under windows should cope with pathnames having spaces in them, unilike mkisofs which was initially created for unix and ported over to windows.
Does nasmw really fail at a path with spaces on windows?
We need a testcase for this.
"Definitely harmful" overstates the case
The patch is definitely harmful if it doesn't report a real problem.
IMO, definitely harmful overstates the case. It is not that bad to unnecessarily tell the user to not put spaces in the build pathname. 99% of the time it will cost the user almost nothing to rename or move the build directory. And in the remaining 1%, the user will probably need to get an administrator to install nasmw!
We are really talking about a trade-off between a small inconvenience for the user if the warning is unnecessary, versus considerable frustration and delay for the user if it turns out that the warning was necessary.
But either way, can we just decide quickly and move onto something more important?
let stop the discussion **now**
Levente, steve : I will check it myself. until that, no need to argue for or against restoring the patch.
Fabien
my blog : en français, in english or both
bug still there : I reapplied the patch
The build fail in the initjars task. So, I re-applied the patch (after a slight modification to use the Os task).
Fabien
my blog : en français, in english or both
Workaround on patch tracker
You can use "Documents and settings" or any other path containing spaces by using the workaround on the patch tracker,