[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v3 2/8] cmake: generate the shell/perl/python scripts and templates, translations
From:       Sibi Siddharthan <sibisiddharthan.github () gmail ! com>
Date:       2020-05-30 18:57:10
Message-ID: CAKiG+9Ue1fqrzqHduZY4Pnsh4q+Thqq618JymkonmVhGewmM1g () mail ! gmail ! com
[Download RAW message or body]

On Sat, May 30, 2020 at 12:58 AM Junio C Hamano <gitster@pobox.com> wrote:
> 
> "Sibi Siddharthan via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > From: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
> > 
> > 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?
> 

Will do.

> > +#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?
> 

Will glob the above, and the po files as well.

> > +#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:
> 

So, I have to write the logic for determining the directories?
If so will do.

> - 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.


[prev in list] [next in list] [prev in thread] [next in thread]