Moved rc from <build> tools to target standard command tools.
Updated rules to build the <build>rc platform version. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26146 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Philippe Houdoin
parent
01f28a0ae3
commit
e221c09e50
@ -201,6 +201,7 @@ SubInclude HAIKU_TOP src bin patch ;
|
||||
SubInclude HAIKU_TOP src bin pc ;
|
||||
SubInclude HAIKU_TOP src bin pcmcia-cs ;
|
||||
SubInclude HAIKU_TOP src bin playsound ;
|
||||
SubInclude HAIKU_TOP src bin rc ;
|
||||
SubInclude HAIKU_TOP src bin rmd160 ;
|
||||
SubInclude HAIKU_TOP src bin screen_blanker ;
|
||||
SubInclude HAIKU_TOP src bin sed ;
|
||||
|
||||
32
src/bin/rc/Jamfile
Normal file
32
src/bin/rc/Jamfile
Normal file
@ -0,0 +1,32 @@
|
||||
SubDir HAIKU_TOP src bin rc ;
|
||||
|
||||
SetSubDirSupportedPlatformsBeOSCompatible ;
|
||||
|
||||
GENERATE_C++ on [ FGristFiles lexer.l parser.y ] = true ;
|
||||
|
||||
SubDirC++Flags -Wno-sign-compare -Wno-unused ;
|
||||
|
||||
local r5Compatibility = [ FDirName $(SUBDIR) R5Compatibility.h ] ;
|
||||
SubDirCcFlags -include $(r5Compatibility) ;
|
||||
SubDirC++Flags -include $(r5Compatibility) ;
|
||||
|
||||
StaticLibrary librdef.a :
|
||||
compile.cpp decompile.cpp lexer.l parser.y rdef.cpp ;
|
||||
|
||||
# On BeOS incompatible platforms we implicitly link against libroot_build.so,
|
||||
# which does already include the strl*() routines.
|
||||
local strlSources ;
|
||||
if $(HOST_PLATFORM_BEOS_COMPATIBLE) {
|
||||
strlSources = strlcpy.c strlcat.c ;
|
||||
}
|
||||
|
||||
BinCommand rc :
|
||||
rc.cpp
|
||||
|
||||
# these two are needed for R5 only
|
||||
$(strlSources)
|
||||
: librdef.a $(TARGET_LIBSTDC++) be $(TARGET_LIBSUPC++)
|
||||
;
|
||||
|
||||
SEARCH on [ FGristFiles $(strlSources) ]
|
||||
= [ FDirName $(HAIKU_TOP) src system libroot posix string ] ;
|
||||
@ -1,43 +1,43 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Work notes</TITLE>
|
||||
</HEAD>
|
||||
<BODY BGCOLOR="#FFFFFF">
|
||||
|
||||
<H1>Work notes</H1>
|
||||
|
||||
<P>These are my notes on the evolution of rc. I used to keep these in separate files on my development machine, but it makes more sense to include them here. Warning: geeky stuff ahead.</P>
|
||||
|
||||
<UL>
|
||||
|
||||
<LI>Unlike in most parsers, the unary minus operator is currently not part of the 'data' rules, but of 'integer' and 'float'. When expression support is more complete, it may make more sense to put this in 'data'. However, 'integer' is used in other places as well and these places allow negative numbers too. Maybe we can replace the calls to 'integer' with 'data' and allow the data to the integer only (by always trying to cast it, perhaps). Then you can do stuff like 'resource(10 + 1) 123;' But maybe that goes too far.<BR> </LI>
|
||||
|
||||
<LI>When filling in boolean fields of user-defined types or messages, you can do either "field = true" or "field = false". I thought it would be nice if you could also do just "field" and "!field". However, that introduced a reduce/reduce conflict in the parser. You see, the name of the field is an IDENT token, but we already have something like that in the 'type' rule of 'data'. The parser doesn't know what the IDENT is supposed to be: the name of the boolean field or the name of the type. Maybe there is a solution for this by shuffling around the parser rules a bit.<BR> </LI>
|
||||
|
||||
<LI>Support for the built-in types point, rect, and rgb_color is currently hardcoded into the decompiler. The other built-in types -- app_flags, mini_icon, etc -- are not supported at all. It would be better to use the type symbol table for this as well. Then the decompiler can also support user-defined types (although these type definitions must be provided to the decompiler somehow). This is advanced stuff that probably no one will ever use.<BR> </LI>
|
||||
|
||||
<LI>The builtin types are added to the symbol table "by hand". You can see this near the bottom of 'parser.y'. This is a bit cumbersome, so I have devised an alternative. We put the builtin type definitions in an rdef script and install this in a "standard include dir", for example: ~/config/include/rc. Before it compiles the user's rdef files, the compiler first loads all scripts from that standard folder. (This also allows us to use these rdef files for decompiling, and users can simply install their own. See above.)<BR> </LI>
|
||||
|
||||
<LI>In "auto names" mode, the decompiler currently does not use the enum symbol table. So if two resources have the same name and that name is a valid C/C++ identifier, the decompiler will add two conflicting symbols to the enum statement. This can also happen when multiple input files have conflicting resource IDs.<BR> </LI>
|
||||
|
||||
<LI>When you decompile certain apps (BeMail, Slayer) and then compile these rdef files again, the archive and message fields in the new .rsrc file are larger than the original's. I think this is because rc doesn't add the message fields as "fixedSize" (see the BMessage docs from the BeBook). This doesn't really hurt, though, since the BMessage will be properly unflattened regardless.<BR> </LI>
|
||||
|
||||
<LI>Right now, archives are treated as messages. Maybe we should give them their own type, B_ARCHIVED_OBJECT (type code 'ARCV').<BR> </LI>
|
||||
|
||||
<LI>New options, stolen from other resource compilers (rez and beres):
|
||||
|
||||
<UL>
|
||||
<LI><B>-D --define symbol[=value]</B> set the value of symbol to value (or 1 if no value supplied)</LI>
|
||||
<LI><B>--no-names</B> do not write any names in resource file</LI>
|
||||
<LI><B>-h</B> write resource as C struct in a header file</LI>
|
||||
<LI><B>-d</B> dump resource to stdout</LI>
|
||||
</UL><BR></LI>
|
||||
|
||||
<LI>Attributes. I would be nice to have a tool that can take text-based descriptions of attributes and write out an attribute file. Of course, rc is the ideal candidate for this, since it already does the same for resources. However, resources and attributes are not the same. Attributes are name/data pairs. The name should be unique. They don't have IDs. They do have a type code, but it isn't used to identify the attribute. It is probably best to add a new kind of definition: attribute(). Should this statement allow only simple data, or must attributes be able to handle flattened messages, arrays, etc too? A source file should either contain resource() statements or attribute() statements, not both.<BR> </LI>
|
||||
|
||||
<LI>User-defined symbolic constants. To keep things simple, adding a #define keyword would suffice, although this always creates global symbols so there is a chance of name collisions. In addition (or instead) we can extend user-defined types to have their own (local) defines too. If we use the #define keyword, we should infer the type of the constant from the data (100 is integer, 10.5 is a float, etc). This is necessary because we don't have a separate preprocessor step like C/C++ does -- that is why our symbolic constants are typed.</LI>
|
||||
|
||||
</UL>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Work notes</TITLE>
|
||||
</HEAD>
|
||||
<BODY BGCOLOR="#FFFFFF">
|
||||
|
||||
<H1>Work notes</H1>
|
||||
|
||||
<P>These are my notes on the evolution of rc. I used to keep these in separate files on my development machine, but it makes more sense to include them here. Warning: geeky stuff ahead.</P>
|
||||
|
||||
<UL>
|
||||
|
||||
<LI>Unlike in most parsers, the unary minus operator is currently not part of the 'data' rules, but of 'integer' and 'float'. When expression support is more complete, it may make more sense to put this in 'data'. However, 'integer' is used in other places as well and these places allow negative numbers too. Maybe we can replace the calls to 'integer' with 'data' and allow the data to the integer only (by always trying to cast it, perhaps). Then you can do stuff like 'resource(10 + 1) 123;' But maybe that goes too far.<BR> </LI>
|
||||
|
||||
<LI>When filling in boolean fields of user-defined types or messages, you can do either "field = true" or "field = false". I thought it would be nice if you could also do just "field" and "!field". However, that introduced a reduce/reduce conflict in the parser. You see, the name of the field is an IDENT token, but we already have something like that in the 'type' rule of 'data'. The parser doesn't know what the IDENT is supposed to be: the name of the boolean field or the name of the type. Maybe there is a solution for this by shuffling around the parser rules a bit.<BR> </LI>
|
||||
|
||||
<LI>Support for the built-in types point, rect, and rgb_color is currently hardcoded into the decompiler. The other built-in types -- app_flags, mini_icon, etc -- are not supported at all. It would be better to use the type symbol table for this as well. Then the decompiler can also support user-defined types (although these type definitions must be provided to the decompiler somehow). This is advanced stuff that probably no one will ever use.<BR> </LI>
|
||||
|
||||
<LI>The builtin types are added to the symbol table "by hand". You can see this near the bottom of 'parser.y'. This is a bit cumbersome, so I have devised an alternative. We put the builtin type definitions in an rdef script and install this in a "standard include dir", for example: ~/config/include/rc. Before it compiles the user's rdef files, the compiler first loads all scripts from that standard folder. (This also allows us to use these rdef files for decompiling, and users can simply install their own. See above.)<BR> </LI>
|
||||
|
||||
<LI>In "auto names" mode, the decompiler currently does not use the enum symbol table. So if two resources have the same name and that name is a valid C/C++ identifier, the decompiler will add two conflicting symbols to the enum statement. This can also happen when multiple input files have conflicting resource IDs.<BR> </LI>
|
||||
|
||||
<LI>When you decompile certain apps (BeMail, Slayer) and then compile these rdef files again, the archive and message fields in the new .rsrc file are larger than the original's. I think this is because rc doesn't add the message fields as "fixedSize" (see the BMessage docs from the BeBook). This doesn't really hurt, though, since the BMessage will be properly unflattened regardless.<BR> </LI>
|
||||
|
||||
<LI>Right now, archives are treated as messages. Maybe we should give them their own type, B_ARCHIVED_OBJECT (type code 'ARCV').<BR> </LI>
|
||||
|
||||
<LI>New options, stolen from other resource compilers (rez and beres):
|
||||
|
||||
<UL>
|
||||
<LI><B>-D --define symbol[=value]</B> set the value of symbol to value (or 1 if no value supplied)</LI>
|
||||
<LI><B>--no-names</B> do not write any names in resource file</LI>
|
||||
<LI><B>-h</B> write resource as C struct in a header file</LI>
|
||||
<LI><B>-d</B> dump resource to stdout</LI>
|
||||
</UL><BR></LI>
|
||||
|
||||
<LI>Attributes. I would be nice to have a tool that can take text-based descriptions of attributes and write out an attribute file. Of course, rc is the ideal candidate for this, since it already does the same for resources. However, resources and attributes are not the same. Attributes are name/data pairs. The name should be unique. They don't have IDs. They do have a type code, but it isn't used to identify the attribute. It is probably best to add a new kind of definition: attribute(). Should this statement allow only simple data, or must attributes be able to handle flattened messages, arrays, etc too? A source file should either contain resource() statements or attribute() statements, not both.<BR> </LI>
|
||||
|
||||
<LI>User-defined symbolic constants. To keep things simple, adding a #define keyword would suffice, although this always creates global symbols so there is a chance of name collisions. In addition (or instead) we can extend user-defined types to have their own (local) defines too. If we use the #define keyword, we should infer the type of the constant from the data (100 is integer, 10.5 is a float, etc). This is necessary because we don't have a separate preprocessor step like C/C++ does -- that is why our symbolic constants are typed.</LI>
|
||||
|
||||
</UL>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
@ -1,12 +1,14 @@
|
||||
SubDir HAIKU_TOP src tools rc ;
|
||||
|
||||
SEARCH_SOURCE += [ FDirName $(HAIKU_TOP) src bin rc ] ;
|
||||
|
||||
USES_BE_API on <build>librdef.a <build>rc = true ;
|
||||
|
||||
GENERATE_C++ on [ FGristFiles lexer.l parser.y ] = true ;
|
||||
|
||||
SubDirC++Flags -Wno-sign-compare -Wno-unused ;
|
||||
|
||||
local r5Compatibility = [ FDirName $(SUBDIR) R5Compatibility.h ] ;
|
||||
local r5Compatibility = [ FDirName $(HAIKU_TOP) src bin rc R5Compatibility.h ] ;
|
||||
SubDirCcFlags -include $(r5Compatibility) ;
|
||||
SubDirC++Flags -include $(r5Compatibility) ;
|
||||
|
||||
@ -25,9 +27,9 @@ BuildPlatformMain <build>rc :
|
||||
|
||||
# these two are needed for R5 only
|
||||
$(strlSources)
|
||||
|
||||
: <build>librdef.a $(HOST_LIBSTDC++) $(HOST_LIBBE) $(HOST_LIBSUPC++)
|
||||
;
|
||||
LinkAgainst <build>rc
|
||||
: <build>librdef.a $(HOST_LIBSTDC++) $(HOST_LIBBE) $(HOST_LIBSUPC++) ;
|
||||
|
||||
SEARCH on [ FGristFiles $(strlSources) ]
|
||||
= [ FDirName $(HAIKU_TOP) src system libroot posix string ] ;
|
||||
|
||||
Loading…
Reference in New Issue
Block a user