gencpp/project/bootstrap.cpp

355 lines
12 KiB
C++
Raw Normal View History

#define GEN_DEFINE_LIBRARY_CODE_CONSTANTS
#define GEN_ENFORCE_STRONG_CODE_TYPES
#define GEN_EXPOSE_BACKEND
#define GEN_C_LIKE_CPP 1
#include "gen.cpp"
#include "helpers/push_ignores.inline.hpp"
#include "helpers/helper.hpp"
GEN_NS_BEGIN
#include "helpers/push_container_defines.inline.hpp"
#include "dependencies/parsing.cpp"
#include "helpers/pop_container_defines.inline.hpp"
GEN_NS_END
#include "auxillary/builder.hpp"
#include "auxillary/builder.cpp"
#include "auxillary/scanner.hpp"
using namespace gen;
constexpr char const* generation_notice =
"// This file was generated automatially by gencpp's bootstrap.cpp "
"(See: https://github.com/Ed94/gencpp)\n\n";
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
#include <cstdlib> // for system()
void format_file( char const* path )
{
String resolved_path = string_make_strc(GlobalAllocator, to_strc_from_c_str(path));
String style_arg = string_make_strc(GlobalAllocator, txt("-style=file:"));
string_append_strc( & style_arg, txt("../scripts/.clang-format "));
// Need to execute clang format on the generated file to get it to match the original.
#define clang_format txt("clang-format ")
#define cf_format_inplace txt("-i ")
#define cf_verbose txt("-verbose ")
String command = string_make_strc( GlobalAllocator, clang_format );
string_append_strc( & command, cf_format_inplace );
string_append_strc( & command, cf_verbose );
string_append_string( & command, style_arg );
string_append_string( & command, resolved_path );
log_fmt("\tRunning clang-format on file:\n");
system( command );
log_fmt("\tclang-format finished reformatting.\n");
#undef cf_cmd
#undef cf_format_inplace
#undef cf_style
#undef cf_verbse
}
Code dump_to_scratch_and_retireve( Code code )
{
Builder ecode_file_temp = Builder::open("gen/scratch.hpp");
ecode_file_temp.print(code);
ecode_file_temp.write();
format_file("gen/scratch.hpp");
Code result = scan_file( "gen/scratch.hpp" );
remove("gen/scratch.hpp");
return result;
}
int gen_main()
{
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
gen::init();
// PreprocessorDefines.append("GEN_NS");
Code push_ignores = scan_file( "helpers/push_ignores.inline.hpp" );
Code pop_ignores = scan_file( "helpers/pop_ignores.inline.hpp" );
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
// gen_dep.hpp
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
{
Code platform = scan_file( "dependencies/platform.hpp" );
Code macros = scan_file( "dependencies/macros.hpp" );
Code basic_types = scan_file( "dependencies/basic_types.hpp" );
Code debug = scan_file( "dependencies/debug.hpp" );
Code memory = scan_file( "dependencies/memory.hpp" );
Code string_ops = scan_file( "dependencies/string_ops.hpp" );
Code printing = scan_file( "dependencies/printing.hpp" );
Code containers = scan_file( "dependencies/containers.hpp" );
Code hashing = scan_file( "dependencies/hashing.hpp" );
Code strings = scan_file( "dependencies/strings.hpp" );
Code filesystem = scan_file( "dependencies/filesystem.hpp" );
Code timing = scan_file( "dependencies/timing.hpp" );
Builder
header = Builder::open("gen/gen.dep.hpp");
header.print_fmt( generation_notice );
header.print_fmt( "// This file is intended to be included within gen.hpp (There is no pragma diagnostic ignores)\n" );
header.print( platform );
header.print_fmt( "\nGEN_NS_BEGIN\n" );
header.print( macros );
header.print( basic_types );
header.print( debug );
header.print( memory );
header.print( string_ops );
header.print( printing );
header.print( containers );
header.print( hashing );
header.print( strings );
header.print( filesystem );
header.print( timing );
2023-08-21 22:51:59 -07:00
header.print_fmt( "\nGEN_NS_END\n" );
header.write();
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
}
// gen_dep.cpp
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
{
Code src_start = scan_file( "dependencies/src_start.cpp" );
Code debug = scan_file( "dependencies/debug.cpp" );
Code string_ops = scan_file( "dependencies/string_ops.cpp" );
Code printing = scan_file( "dependencies/printing.cpp" );
Code memory = scan_file( "dependencies/memory.cpp" );
Code hashing = scan_file( "dependencies/hashing.cpp" );
Code strings = scan_file( "dependencies/strings.cpp" );
Code filesystem = scan_file( "dependencies/filesystem.cpp" );
Code timing = scan_file( "dependencies/timing.cpp" );
Builder
src = Builder::open( "gen/gen.dep.cpp" );
src.print_fmt( generation_notice );
src.print_fmt( "// This file is intended to be included within gen.cpp (There is no pragma diagnostic ignores)\n" );
src.print( src_start );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\nGEN_NS_BEGIN\n" );
src.print( debug );
src.print( string_ops );
src.print( printing );
src.print( hashing );
src.print( memory );
src.print( strings );
src.print( filesystem );
src.print( timing );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\nGEN_NS_END\n" );
src.write();
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
}
CodeBody gen_component_header = def_global_body( args(
def_preprocess_cond( PreprocessCond_IfDef, txt("GEN_INTELLISENSE_DIRECTIVES") ),
pragma_once,
def_include(txt("components/types.hpp")),
preprocess_endif,
fmt_newline,
2024-12-04 08:30:54 -08:00
untyped_str( to_strc_from_c_str(generation_notice) )
));
// gen.hpp
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
{
Code header_start = scan_file( "components/header_start.hpp" );
Code types = scan_file( "components/types.hpp" );
Code ast = scan_file( "components/ast.hpp" );
Code ast_types = scan_file( "components/ast_types.hpp" );
Code code_types = scan_file( "components/code_types.hpp" );
Code interface = scan_file( "components/interface.hpp" );
Code inlines = scan_file( "components/inlines.hpp" );
Code header_end = scan_file( "components/header_end.hpp" );
2024-12-07 14:17:02 -08:00
CodeBody ecode = gen_ecode ( "enums/ECodeTypes.csv" );
CodeBody eoperator = gen_eoperator ( "enums/EOperator.csv" );
CodeBody especifier = gen_especifier( "enums/ESpecifier.csv" );
CodeBody ast_inlines = gen_ast_inlines();
Builder
header = Builder::open( "gen/gen.hpp" );
header.print_fmt( generation_notice );
header.print_fmt( "#pragma once\n\n" );
header.print( push_ignores );
header.print( header_start );
2023-08-21 22:51:59 -07:00
header.print_fmt( "\nGEN_NS_BEGIN\n\n" );
2023-08-21 22:51:59 -07:00
header.print_fmt( "#pragma region Types\n" );
header.print( types );
header.print( fmt_newline);
header.print( dump_to_scratch_and_retireve(ecode) );
header.print( fmt_newline);
header.print( dump_to_scratch_and_retireve(eoperator) );
header.print( fmt_newline);
header.print( dump_to_scratch_and_retireve(especifier) );
header.print( fmt_newline);
header.print_fmt( "#pragma endregion Types\n\n" );
2023-08-21 22:51:59 -07:00
header.print_fmt( "#pragma region AST\n" );
header.print( ast );
header.print( code_types );
header.print( ast_types );
2023-08-21 22:51:59 -07:00
header.print_fmt( "\n#pragma endregion AST\n" );
header.print( interface );
2023-08-21 23:09:20 -07:00
header.print_fmt( "\n#pragma region Inlines\n" );
header.print( inlines );
2023-08-21 22:51:59 -07:00
header.print( fmt_newline );
header.print( dump_to_scratch_and_retireve(ast_inlines) );
header.print( fmt_newline );
2023-08-21 22:51:59 -07:00
header.print_fmt( "#pragma endregion Inlines\n" );
header.print( header_end );
header.print_fmt( "GEN_NS_END\n\n" );
header.print( pop_ignores );
header.write();
Builder
header_ecode = Builder::open( "components/gen/ecode.hpp" );
header_ecode.print( gen_component_header );
header_ecode.print( ecode );
header_ecode.write();
Builder
header_eoperator = Builder::open( "components/gen/eoperator.hpp" );
header_eoperator.print( gen_component_header );
header_eoperator.print( eoperator );
header_eoperator.write();
Builder
header_especifier = Builder::open( "components/gen/especifier.hpp" );
header_especifier.print( gen_component_header );
header_especifier.print( especifier );
header_especifier.write();
Builder
header_ast_inlines = Builder::open( "components/gen/ast_inlines.hpp" );
header_ast_inlines.print( gen_component_header );
header_ast_inlines.print( ast_inlines );
header_ast_inlines.write();
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
}
// gen.cpp
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
{
Code src_start = scan_file( "components/src_start.cpp" );
Code static_data = scan_file( "components/static_data.cpp" );
Code ast_case_macros = scan_file( "components/ast_case_macros.cpp" );
Code ast = scan_file( "components/ast.cpp" );
Code code_serialization = scan_file( "components/code_serialization.cpp" );
Code interface = scan_file( "components/interface.cpp" );
Code upfront = scan_file( "components/interface.upfront.cpp" );
Code lexer = scan_file( "components/lexer.cpp" );
Code parser = scan_file( "components/parser.cpp" );
Code parsing_interface = scan_file( "components/interface.parsing.cpp" );
Code untyped = scan_file( "components/interface.untyped.cpp" );
CodeBody etoktype = gen_etoktype( "enums/ETokType.csv", "enums/AttributeTokens.csv" );
2024-12-03 06:31:27 -08:00
//CodeNS nspaced_etoktype = def_namespace( name(parser), def_namespace_body( args(etoktype)) );
CodeBody nspaced_etoktype = def_global_body( args(
etoktype
2024-12-03 06:31:27 -08:00
));
Builder
src = Builder::open( "gen/gen.cpp" );
src.print_fmt( generation_notice );
src.print( push_ignores );
src.print( src_start );
src.print_fmt( "\nGEN_NS_BEGIN\n");
src.print( static_data );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\n#pragma region AST\n\n" );
src.print( ast_case_macros );
src.print( ast );
src.print( code_serialization );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\n#pragma endregion AST\n" );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\n#pragma region Interface\n" );
src.print( interface );
src.print( upfront );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\n#pragma region Parsing\n\n" );
src.print( dump_to_scratch_and_retireve(nspaced_etoktype) );
src.print( lexer );
src.print( parser );
src.print( parsing_interface );
src.print( untyped );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\n#pragma endregion Parsing\n\n" );
src.print_fmt( "#pragma endregion Interface\n\n" );
src.print_fmt( "GEN_NS_END\n\n");
src.print( pop_ignores );
src.write();
Builder
src_etoktype = Builder::open( "components/gen/etoktype.cpp" );
src_etoktype.print( gen_component_header );
src_etoktype.print( nspaced_etoktype );
src_etoktype.write();
}
// gen_builder.hpp
{
Code builder = scan_file( "auxillary/builder.hpp" );
Builder
header = Builder::open( "gen/gen.builder.hpp" );
header.print_fmt( generation_notice );
header.print_fmt( "#pragma once\n\n" );
header.print( def_include( txt("gen.hpp") ));
2023-08-21 22:51:59 -07:00
header.print_fmt( "\nGEN_NS_BEGIN\n" );
header.print( builder );
2023-08-21 22:51:59 -07:00
header.print_fmt( "GEN_NS_END\n" );
header.write();
}
// gen_builder.cpp
{
Code builder = scan_file( "auxillary/builder.cpp" );
Builder
src = Builder::open( "gen/gen.builder.cpp" );
src.print_fmt( generation_notice );
src.print( def_include( txt("gen.builder.hpp") ) );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\nGEN_NS_BEGIN\n" );
src.print( builder );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\nGEN_NS_END\n" );
src.write();
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
}
// gen_scanner.hpp
{
Code parsing = scan_file( "dependencies/parsing.hpp" );
Code scanner = scan_file( "auxillary/scanner.hpp" );
Builder
header = Builder::open( "gen/gen.scanner.hpp" );
header.print_fmt( generation_notice );
header.print_fmt( "#pragma once\n\n" );
header.print( def_include( txt("gen.hpp") ) );
2023-08-21 22:51:59 -07:00
header.print_fmt( "\nGEN_NS_BEGIN\n" );
header.print( parsing );
header.print( scanner );
header.print_fmt( "\nGEN_NS_END\n" );
header.write();
}
// gen_scanner.cpp
{
Code parsing = scan_file( "dependencies/parsing.cpp" );
Code scanner = scan_file( "auxillary/scanner.cpp" );
Builder
src = Builder::open( "gen/gen.scanner.cpp" );
src.print_fmt( generation_notice );
src.print( def_include( txt("gen.scanner.hpp") ) );
2023-08-21 22:51:59 -07:00
src.print_fmt( "\nGEN_NS_BEGIN\n" );
src.print( parsing );
// src.print( scanner );
2023-08-21 22:51:59 -07:00
src.print_fmt( "GEN_NS_END\n" );
src.write();
}
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
gen::deinit();
return 0;
}