ed/gencpp
1
0
Fork 0
mirror of https://github.com/Ed94/gencpp.git synced 2024-11-10 02:54:53 -08:00
Code Issues Packages Projects Releases Wiki Activity
62b0ed2112
gencpp/project/gen.bootstrap.cpp

172 lines
6.1 KiB
C++
Raw Normal View History

some cleanup of unused macros in test files, preparing bootstrap and single header code + scripts
2023-07-24 15:51:49 -07:00
#define GEN_DEFINE_LIBRARY_CODE_CONSTANTS
#define GEN_ENFORCE_STRONG_CODE_TYPES
#define GEN_EXPOSE_BACKEND
#include "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
#include "filesystem/gen.scanner.hpp"
some cleanup of unused macros in test files, preparing bootstrap and single header code + scripts
2023-07-24 15:51:49 -07:00
using namespace gen;
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
bool namespace_by_default = true;
constexpr StrC nspace_default = txt_StrC(R"(
#if defined(GEN_DONT_USE_NAMESPACE) && ! defined(GEN_NS_BEGIN)
# define GEN_NS_BEGIN
# define GEN_NS_END
#elif ! defined(GEN_NS_BEGIN)
# define GEN_NS_BEGIN namespace gen {
# define GEN_NS_END }
#endif
)");
constexpr StrC nspace_non_default = txt_StrC(R"(
#if ! defined(GEN_USE_NAMESPACE) && ! defined(GEN_NS_BEGIN)
# define GEN_NS_BEGIN
# define GEN_NS_END
#elif ! defined(GEN_NS_BEGIN)
# define GEN_NS_BEGIN namespace gen {
# define GEN_NS_END }
#endif
)");
Fixes + more setup, added more directories to clean script.
2023-07-24 15:56:15 -07:00
int gen_main()
some cleanup of unused macros in test files, preparing bootstrap and single header code + scripts
2023-07-24 15:51:49 -07:00
{
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();
Code push_ignores = scan_file( "helpers/gen.push_ignores.inline.hpp" );
Code pop_ignores = scan_file( "helpers/gen.pop_ignores.inline.hpp" );
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -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
{
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -07:00
Code header_start = scan_file( "dependencies/gen.header_start.hpp" );
Code nspace_macro = untyped_str( namespace_by_default ? nspace_default : nspace_non_default );
Code macros = scan_file( "dependencies/gen.macros.hpp" );
Code basic_types = scan_file( "dependencies/gen.basic_types.hpp" );
Code debug = scan_file( "dependencies/gen.debug.hpp" );
Code memory = scan_file( "dependencies/gen.memory.hpp" );
Code string_ops = scan_file( "dependencies/gen.string_ops.hpp" );
Code printing = scan_file( "dependencies/gen.printing.hpp" );
Code containers = scan_file( "dependencies/gen.containers.hpp" );
Code string = scan_file( "dependencies/gen.string.hpp" );
Code file_handling = scan_file( "dependencies/gen.file_handling.hpp" );
Code parsing = scan_file( "dependencies/gen.parsing.hpp" );
Code timing = scan_file( "dependencies/gen.timing.hpp" );
Builder
deps_header;
deps_header.open("gen/gen_dep.hpp");
deps_header.print_fmt("// This file is intended to be included within gen.cpp (There is no pragma diagnostic ignores)\n\n");
deps_header.print_fmt("#pragma once\n\n");
deps_header.print( push_ignores );
deps_header.print( header_start );
deps_header.print( nspace_macro );
deps_header.print_fmt( "GEN_NS_BEGIN\n\n");
deps_header.print( macros );
deps_header.print( basic_types );
deps_header.print( debug );
deps_header.print( memory );
deps_header.print( string_ops );
deps_header.print( printing );
deps_header.print( containers );
deps_header.print( string );
deps_header.print( file_handling );
deps_header.print( parsing );
deps_header.print( timing );
deps_header.print_fmt( "GEN_NS_END\n\n");
deps_header.print( pop_ignores );
deps_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
}
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -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
{
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -07:00
CodeInclude header = def_include( txt_StrC("gen_dep.hpp") );
Code impl_start = scan_file( "dependencies/gen.impl_start.cpp" );
Code debug = scan_file( "dependencies/gen.debug.cpp" );
Code string_ops = scan_file( "dependencies/gen.string_ops.cpp" );
Code printing = scan_file( "dependencies/gen.printing.cpp" );
Code memory = scan_file( "dependencies/gen.memory.cpp" );
Code parsing = scan_file( "dependencies/gen.parsing.cpp" );
Code hashing = scan_file( "dependencies/gen.hashing.cpp" );
Code string = scan_file( "dependencies/gen.string.cpp" );
Code timing = scan_file( "dependencies/gen.timing.cpp" );
Builder
deps_impl;
deps_impl.open("gen/gen_dep.cpp");
deps_impl.print_fmt("// This file is intended to be included within gen.cpp (There is no pragma diagnostic ignores)\n\n");
deps_impl.print( impl_start );
deps_impl.print( header );
deps_impl.print_fmt( "\nGEN_NS_BEGIN\n");
deps_impl.print( debug );
deps_impl.print( string_ops );
deps_impl.print( printing );
deps_impl.print( memory );
deps_impl.print( parsing );
deps_impl.print( string );
deps_impl.print( timing );
deps_impl.print_fmt( "GEN_NS_END\n\n");
deps_impl.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
}
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -07:00
// 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/gen.header_start.hpp" );
Code nspace_macro = untyped_str( namespace_by_default ? nspace_default : nspace_non_default );
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -07:00
Code types = scan_file( "components/gen.types.hpp" );
Code data_structs = scan_file( "components/gen.data_structures.hpp" );
Code interface = scan_file( "components/gen.interface.hpp" );
Code header_end = scan_file( "components/gen.header_end.hpp" );
Builder
header;
header.open( "gen/gen.hpp" );
header.print_fmt("#pragma once\n\n");
header.print( push_ignores );
header.print( header_start );
header.print( nspace_macro );
header.print_fmt( "GEN_NS_BEGIN\n\n");
header.print( types );
header.print( data_structs );
header.print( interface );
header.print( header_end );
header.print_fmt( "GEN_NS_END\n\n");
header.print( pop_ignores );
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
}
some cleanup of unused macros in test files, preparing bootstrap and single header code + scripts
2023-07-24 15:51:49 -07:00
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -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
{
Finished initial implmentation bootstrap generation and singleheader implementation.
2023-07-25 12:12:51 -07:00
Code impl_start = scan_file( "components/gen.impl_start.cpp" );
CodeInclude header = def_include( txt_StrC("gen.hpp") );
Code data = scan_file( "components/gen.data.cpp" );
Code ast_case_macros = scan_file( "components/gen.ast_case_macros.cpp" );
Code ast = scan_file( "components/gen.ast.cpp" );
Code interface = scan_file( "components/gen.interface.cpp" );
Code upfront = scan_file( "components/gen.interface.upfront.cpp" );
Code parsing = scan_file( "components/gen.interface.parsing.cpp" );
Code untyped = scan_file( "components/gen.untyped.cpp" );
Code builder = scan_file( "filesystem/gen.builder.cpp" );
Builder
impl;
impl.open( "gen/gen.cpp" );
impl.print( push_ignores );
impl.print( impl_start );
impl.print( header );
impl.print_fmt( "\nGEN_NS_BEGIN\n\n");
impl.print( data );
impl.print( ast_case_macros );
impl.print( ast );
impl.print( interface );
impl.print( upfront );
impl.print( parsing );
impl.print( untyped );
impl.print_fmt( "GEN_NS_END\n\n");
impl.print( pop_ignores );
impl.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
}
some cleanup of unused macros in test files, preparing bootstrap and single header code + scripts
2023-07-24 15:51:49 -07:00
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();
some cleanup of unused macros in test files, preparing bootstrap and single header code + scripts
2023-07-24 15:51:49 -07:00
return 0;
}
Reference in New Issue Copy Permalink