headers
Jérome DUVAL | 3 Jun 2004 12:07
Favicon

need help with jam

Hi

i'm trying to build gnu bash using jam and i have little problems.

there is a build tool named 'mkbuiltins' which is built with a BinCommand
rule and it builds successfully.
This build tool is used to compile .def files to .c files.

I tried to add the following to the Jamfile (based on the rc stuff in
Jamrules) to have .def files compiled to .c files :

BinCommand mkbuiltins : mkbuiltins.c

rule MkBuiltinsComp
{
# MkBuiltins <c file> : <def file> ;
#
# <c file> and <def file> must be gristed.
SetupObjectsDir ;
SEARCH on $(2) += $(SEARCH_SOURCE) ;
MakeLocate $(1) : $(LOCATE_TARGET) ;
Depends $(1) : $(2) mkbuiltins ;
LocalClean clean : $(1) ;
MkBuiltins1 $(1) : mkbuiltins $(2) ;
}

actions MkBuiltins1
{
$(2[1]) -o $(1) $(2[2-])
}
(Continue reading)

Permalink | Reply | 11 comments |
headers
Marcus Petersson | 3 Jun 2004 16:48
Picon
Favicon

About filesystems

Just wondering if there's some sort of middle-layer, or common stub source
for various filesystems? It seems more like they are all separate from
each other. Not that it matters much. I suppose dos and iso9600 covers
most of the cases where foreign filesystems are concerned.

It would be good to have some documentation about the dos filesystem.
I'd like to modify it for personal use. The idea is to add attribute
emulation by relaying attribute calls to the boot disk, similar to my
attribute library (http://www.bebits.com/app/3683) but transparent.

Marcus
Permalink | Reply | 3 comments |
headers
Bruno G. Albuquerque | 3 Jun 2004 15:29
Picon
Gravatar

Re: About filesystems

Marcus Petersson disse:

> Just wondering if there's some sort of middle-layer, or common stub
> source for various filesystems? It seems more like they are all separate
> from each other. Not that it matters much. I suppose dos and iso9600
> covers most of the cases where foreign filesystems are concerned.

All filesystems implement a specific API that is required by the BeOS VFS
(Virtual File System) layer. Of course the internal implementation varies
from FS to FS as they do thigs differently.

> It would be good to have some documentation about the dos filesystem.

Well, the source is avaiable. :) Also, Dominic's "Practical File System
Design With The Be File System" is available for download and is the bes
reference there is for writting a filesystem for BeOS.

> I'd like to modify it for personal use. The idea is to add attribute
> emulation by relaying attribute calls to the boot disk, similar to my
> attribute library (http://www.bebits.com/app/3683) but transparent.

A cool thing to do would be something like what the SkyOS guys are doing.
Basically that is an extra layer that allows attributes to be read and
written from a specific location (a file, for instance) and that would
allow adding attribute support to filesystems that do not nativelly
support it. It is moe or less what HPFS does with FAT partitions in OS/2.

I guess a cool approach would be to create a link that would be linked to
the FS add-on and would provide all the abstraction for this so the code
required in the FS itself for this to work would be minimal.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marcus Petersson | 3 Jun 2004 18:27
Picon
Favicon

Re: About filesystems

"Bruno G. Albuquerque" <bga@...> wrote:

> All filesystems implement a specific API that is required by the BeOS VFS
> (Virtual File System) layer. Of course the internal implementation varies
> from FS to FS as they do thigs differently.

Yes, but obviously they don't share any implementation source.

> > It would be good to have some documentation about the dos filesystem.
> Well, the source is avaiable. :) 

Indeed. Seems attr.c and file.c contains every function of interest.

> Also, Dominic's "Practical File System
> Design With The Be File System" is available for download and is the bes
> reference there is for writting a filesystem for BeOS.

I guess it will keep me busy for a while. ;-)

> A cool thing to do would be something like what the SkyOS guys are doing.
> Basically that is an extra layer that allows attributes to be read and
> written from a specific location (a file, for instance) and that would
> allow adding attribute support to filesystems that do not nativelly
> support it. It is moe or less what HPFS does with FAT partitions in OS/2.

You mean on the same device? I thought about that idea for a while as well,
but decided it was much easier to start with mirror files on the boot disk.

> I guess a cool approach would be to create a link that would be linked to
> the FS add-on and would provide all the abstraction for this so the code
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruno G. Albuquerque | 3 Jun 2004 17:43
Picon
Gravatar

Re: About filesystems

On Thu, 03 Jun 2004 18:27:37 +0200 CEST, "Marcus Petersson" <
mp_1@...> said:

> > All filesystems implement a specific API that is required by the 
> > BeOS VFS
> > (Virtual File System) layer. Of course the internal implementation 
> > varies
> > from FS to FS as they do thigs differently.
> 
> Yes, but obviously they don't share any implementation source.

Yes, but that's because of what I mentioned. Each file system 
implements things differently.

> > A cool thing to do would be something like what the SkyOS guys are 
> > doing.
> > Basically that is an extra layer that allows attributes to be read 
> > and
> > written from a specific location (a file, for instance) and that 
> > would
> > allow adding attribute support to filesystems that do not nativelly
> > support it. It is moe or less what HPFS does with FAT partitions in 
> > OS/2.
> 
> You mean on the same device? I thought about that idea for a while as 
> well,
> but decided it was much easier to start with mirror files on the boot 
> disk.

Yes, but having it on the target partition itself makes it posible to
(Continue reading)

Permalink | Reply | 0 comments |
headers
shatty | 3 Jun 2004 18:57
Picon

Re: need help with jam

Hello Jérome,

I can't see your problem just by reading the jam.
I would recommend you to look at the resource file
compiler for a model though.  It's in:
current/src/tools/rc

Also please include the output you get from jam and
how it doesn't conform to your expectations.

Andrew
Permalink | Reply | 1 comment |
headers
Ingo Weinhold | 4 Jun 2004 00:28
Picon

Re: need help with jam

On 2004-06-03 at 12:07:35 [+0200], Jérome DUVAL wrote:
> 
> i'm trying to build gnu bash using jam and i have little problems.
> 
> there is a build tool named 'mkbuiltins' which is built with a BinCommand
> rule and it builds successfully.
> This build tool is used to compile .def files to .c files.
> 
> I tried to add the following to the Jamfile (based on the rc stuff in
> Jamrules) to have .def files compiled to .c files :
> 
> BinCommand mkbuiltins : mkbuiltins.c
> 
> rule MkBuiltinsComp
> {
> # MkBuiltins <c file> : <def file> ;
> #
> # <c file> and <def file> must be gristed.
> SetupObjectsDir ;
> SEARCH on $(2) += $(SEARCH_SOURCE) ;
> MakeLocate $(1) : $(LOCATE_TARGET) ;
> Depends $(1) : $(2) mkbuiltins ;
> LocalClean clean : $(1) ;
> MkBuiltins1 $(1) : mkbuiltins $(2) ;
> }
> 
> actions MkBuiltins1
> {
> $(2[1]) -o $(1) $(2[2-])
> }
(Continue reading)

Permalink | Reply | 10 comments |
headers
Axel Dörfler | 4 Jun 2004 02:41
Picon

Re: need help with jam

Ingo Weinhold <bonefish@...> wrote:
> > Additionally, i'd need to have the build tool 'mkbuiltins' not 
> > present in
> > the distro folder. In fact, it is only used as a bash build tool.
> Although that's not so nice, you can just insert a
> 
> 	MakeLocate mkbuiltins : $(LOCATE_TARGET) ;
> 
> after the BinCommand invocation, which will place the file in 
> `objects/...' 
> instead.

Additionally, we also have a set of rules for this stuff, like:
BuildPlatformMain

That's only an example as there are more :-)
It's important to use a different rule there, because the application 
must run on the host platform, not the target one (even if that's not a 
big problem at this point).

Bye,
   Axel.
Permalink | Reply | 3 comments |
headers
Jérome DUVAL | 4 Jun 2004 11:01
Favicon

Re: need help with jam

Hi Andrew,

the problem is more complex than expected for me.
I'm getting used to jam more and more :)

It seems i have to add a 'final' target so that jam tries to build it. If
not, it doesn't bother with my rules.

Jerome

----- Original Message ----- 
From: "shatty" <shatty@...>
To: <openbeos@...>
Sent: Thursday, June 03, 2004 6:57 PM
Subject: [openbeos] Re: need help with jam

> Hello Jérome,
>
> I can't see your problem just by reading the jam.
> I would recommend you to look at the resource file
> compiler for a model though.  It's in:
> current/src/tools/rc
>
> Also please include the output you get from jam and
> how it doesn't conform to your expectations.
>
> Andrew
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jérome DUVAL | 4 Jun 2004 11:54
Favicon

Re: need help with jam

>
> In principle it looks quite OK. As Andrew already wrote, it would be
> helpful, if you gave a bit more info what exactly your problem is.

As i wrote to Andrew, it seems adding a 'final' target makes jam build with
the rules ...

>
> Regarding debugging, that's not so simple. If you suspect a problem with
> dependencies, you can run jam with the `-d3' option, which prints the
> dependency tree. `-d5' additionally gives you a rule processing trace,
> which, due to the size of our build system, is huge.

In fact, huge :)

>
> > Do i need to grist kill.c and kill.def somewhere ? How to do this btw ?
>
> Given the comment in your rule, you need apparently to grist the
> parameters. :-P
>
> Grist is used to make create globally unique target identifiers. Most
rules
> that come with jam (like Main) automatically add grist to source file
> names. So, if in your example you feed `kill.c' to such a rule, it will
> actually try to find something like `<src!...>kill.c', while, as you use
it
> now,  MkBuiltinsComp generates `kill.c'. Hence there's a good chance that
> things won't work properly. You either have to add grist to the parameter
> you pass to the rule MkBuiltinsComp or you let the rule itself add the
(Continue reading)

Permalink | Reply | 3 comments |

Gmane