"Sibi Siddharthan via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Sibi Siddharthan <sibisiddharthan.github@xxxxxxxxx>
>
> Implement the placeholder substitution to generate scripted
> Porcelain commands, e.g. git-request-pull out of
> git-request-pull.sh
>
> Generate shell/perl/python scripts and template using CMake instead of
> using sed like the build procedure in the Makefile does.
>
> The text translations are only build if `msgfmt` is found in your path.
>
> NOTE: The scripts and templates are generated during configuration.
OK.
> Changes
> The CMake script parses the Makefile for:
> SCRIPT_SH
> SCRIPT_PERL
Below the three-dash line.
> +#shell scripts
> +parse_makefile_for_scripts(git_sh_scripts "SCRIPT_SH" ".sh")
OK.
> +set(git_shell_scripts
> + ${git_sh_scripts}
> + git-mergetool--lib git-parse-remote git-rebase--preserve-merges
> + git-sh-setup git-sh-i18n git-instaweb)
Do we need to have enumeration here, which can drift out of sync
with the reality? Wouldn't we want to avoid it with something like
parse_makefile_for_scripts(git_sh_lib "SCRIPT_LIB" "")
too?
> +#perl modules
> +file(GLOB_RECURSE perl_modules "${CMAKE_SOURCE_DIR}/perl/*.pm")
> +
> +foreach(pm ${perl_modules})
> + string(REPLACE "${CMAKE_SOURCE_DIR}/perl/" "" file_path ${pm})
> + file(STRINGS ${pm} content NEWLINE_CONSUME)
> + string(REPLACE "@@LOCALEDIR@@" "${LOCALEDIR}" content "${content}")
> + string(REPLACE "@@NO_PERL_CPAN_FALLBACKS@@" "" content "${content}")
> + file(WRITE ${CMAKE_BINARY_DIR}/perl/build/lib/${file_path} ${content})
> +#test-lib.sh requires perl/build/lib to be the build directory of perl modules
> +endforeach()
> +
> +
> +#templates
> +file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/templates/blt/branches) #create branches
> +set(hooks_templates
> + applypatch-msg.sample pre-applypatch.sample pre-push.sample
> + commit-msg.sample pre-commit.sample pre-rebase.sample
> + fsmonitor-watchman.sample pre-merge-commit.sample pre-receive.sample
> + post-update.sample prepare-commit-msg.sample update.sample)
Do we need to have enumeration here, which can drift out of sync
with the reality? Wouldn't we want to avoid it with file(GLOB) or
something?
> +#templates have @.*@ replacement so use configure_file instead
> +#hooks
> +foreach(tm ${hooks_templates})
> + configure_file(${CMAKE_SOURCE_DIR}/templates/hooks--${tm} ${CMAKE_BINARY_DIR}/templates/blt/hooks/${tm} @ONLY)
> +endforeach()
> +
> +#info
> +configure_file(${CMAKE_SOURCE_DIR}/templates/info--exclude ${CMAKE_BINARY_DIR}/templates/blt/info/exclude @ONLY)
> +
> +#this
> +configure_file(${CMAKE_SOURCE_DIR}/templates/this--description ${CMAKE_BINARY_DIR}/templates/blt/description @ONLY)
I was hoping that we could drive any build system without having to
have separate rules like the above. The idea behind all files with
funny double-dash in its name under templates/ directory is:
- double-dash denotes directory boundary
- when a template input ends with double-dash, it tells us to
create a directory
- leading "this--" denotes "not in a subdirectory but at the top
level of the generated template directory"
so that each of them knows what the name of the file and directory
hierarchy of the final destination is, and the result of transforming
can be created and deposited at the final place mechanically with a
single rule.
> +#translations
> +if(MSGFMT_EXE)
> + set(po_files bg ca de el es fr is it ko pt_PT ru sv tr vi zh_CN zh_TW)
Do we need to have enumeration here, which can drift out of sync
with the reality? Wouldn't globbing for *.po be sufficient?
> + foreach(po ${po_files})
> + file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES)
> + add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo
> + COMMAND ${MSGFMT_EXE} --check --statistics -o ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo ${CMAKE_SOURCE_DIR}/po/${po}.po)
> + list(APPEND po_gen ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo)
> + endforeach()
> + add_custom_target(po-gen ALL DEPENDS ${po_gen})
> +endif()
Thanks.
