Re: [PATCH v3 2/8] cmake: generate the shell/perl/python scripts and templates, translations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 30, 2020 at 12:58 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "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?
>

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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux