[vim/vim] Issues with `make proto` on macOS and lack of documentation (Issue #17851)
Damien Lejay
dlejay created an issue (vim/vim#17851)make proto
One of the targets of src/Makefile is proto:. From what I understand, its goal is to populate the proto directory with each file foo.pro containing the prototypes of the functions defined in foo.c
make proto on macOS
On macOS arm64, make proto fails extensively ; it floods the terminal with errors and all the *.pro files are stained. Given that macOS is a major UNIX platform, it would be reasonable to expect this target to work out of the box.
In comparison make works out of the box on macOS.
Documentation
There is little to no documentation on make proto and the proto/*.pro files.
In conventional C projects, externally visible function prototypes are placed in header files .h. In the Vim Project, there are few header files and those do not contain function prototypes. Instead, each .c file has its own .pro file. And all .pro files are included in proto.h.
This structure is only apparent after exploring the source and build system for some time. It would benefit from being explicitly documented in the developer documentation.
Rationale
The likely motivation behind this design is to automate prototype maintenance and avoid writing them manually. However, after considerable time spent trying to make cproto work correctly on macOS — with no success — I would personally prefer writing header files by hand.
Additionally, I have not come across any other C project using .pro files in this way. I would be interested to better understand the rationale behind this approach and, if it remains the preferred method, help improve its documentation.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)@chrisbra Do any of the main contributors actively develop on macOS ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17851)I don't know. Certainly not me :) I remember having had problems with generating the prototypes for the v9.1 release for some of the C-files even on Linux (so I didn't touch those).
But I am reasonably sure @ychin uses MacOS, so perhaps he can shed some lights here.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
ychin left a comment (vim/vim#17851)I will admit, I always hand edited the prototype files 😅. Maybe I should have used make proto instead but I kind of edit them like header files when I do contributions.
I would imagine it is probably just some minor platform incompatibilities that could be fixed up if we want this to work. I don't know if other main contributors contribute to Vim C source code who use macOS but maybe they all hand edited it like me since usually you just need to add a line here and there. I personally never understood why we have these proto files but I think this issue's descriptions about C90 probably makes sense.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)Thank you all for the clarification. Let me see if I’m understanding the situation correctly :
.profiles are undocumented- The
make protocommand that generates them is unreliable and attempting to fix it would likely require a disproportionate amount of effort - Their original design rationale from decades ago isn't fully clear, even to experienced maintainers
This suggests the .pro system may be creating more problems than it solves compared to a standard header file approach.
Would it be productive to start thinking about a future where we replace the .pro system with different header architecture ?
What would be the biggest challenges in making such a transition ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
yegappan left a comment (vim/vim#17851)I always manually add the function prototype to the proto files. I don't see any issues or difficulties in this approach.
We already have "make proto" to automate this, if needed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#17851)it floods the terminal with errors and all the *.pro files are stained.
Is the above correct? Could you please paste the output of make cproto and the result of git diff immediately afterwards?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)The flood is so massive, it should be instantly replicable.
And it is a bad idea for me to copy paste it here.
Here is the git diff
https://paste.centos.org/view/e0864b06
The result of make proto seems to be too big for paste.centos.org.
Here are the head and tail
make proto 2>&1 | head -n 20 Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src && /Library/Developer/CommandLineTools/usr/bin/make proto cproto -d -E"gcc -E" -D"__attribute\\(x\\)=" -DPROTO `echo '-DLINT -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X -DMACOS_X_DARWIN -Ilibvterm/include -Dinline= -D__extension__= -Dalloca=alloca' | sed -e 's/ -[a-z-]\+//g' -e 's/ -O[^ ]\+//g'` -DFEAT_GUI alloc.c > proto/alloc.pro /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:243: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:247: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:250: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:255: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:318: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:335: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:405: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/stat.h:381: syntax error at token '__asm' Expected: {
make proto 2>&1 | tail -n 20 ... /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:132: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:134: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:153: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:162: bad character '^' /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:163: bad character '^' /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:164: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:181: syntax error at token '__asm' Expected: { /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dirent.h:187: syntax error at token '__asm' Expected: { 1 error generated. os_vms.c:223: syntax error at token 'getenv' Expected: ')' echo "/* vim: set ft=c : */" >> proto/os_vms.pro rm auto/config.h mv auto/config.h.save auto/config.h
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#17851)@dlejay Thanks.
I see, so prototype declarations for functions such as isascii() defined in ctype.h are added to each .pro file...
Could you apply the following patch and run make proto again?
diff --git a/src/os_unix.h b/src/os_unix.h index 39c93043d..c1d787c54 100644 --- a/src/os_unix.h +++ b/src/os_unix.h @@ -19,7 +19,9 @@ #endif #include <stdio.h> -#include <ctype.h> +#ifndef PROTO +# include <ctype.h> +#endif #ifdef VAXC # include <types.h>
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)Sure.
Before the patch
git diff src/proto | wc -l
11897after the patch
git diff src/proto | wc -l
11897Is there a platform where you can confirm that make proto works as intended ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#17851)I also build regularly on macOS, but I haven't had occasion to try make proto: I wonder if cproto needs any patches for macOS 🤔 it doesn't look like the current maintainer has anything to do with the packaging for macOS. (Then again, I wouldn't expect the parsing + transformation to headers to need much change per-platform.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#17851)I'm using Ubuntu 22.04.5 LTS.
The following steps correctly create a Vim binary:
$ make proto; make -j4However, an error occurs when running make proto, and differences are displayed in src/proto/*.pro.
The errors in os_amiga.pro and os_win32.pro are expected as written in src/Makefile.
https://github.com/vim/vim/blob/d1833d2827659d6176ac0607779fda3ebfee8ddc/src/Makefile#L2115-L2119
The files that show differences are actually different from the contents generated by cproto.
However, note that function prototype declarations in .pro files for features that are not needed in my environment or that are not enabled with configure will be deleted. (gui_motif.pro, gui_xmdlg.pro, if_lua.pro, if_python.pro, if_python3.pro, ...)
Below is the result of git diff.
diff --git a/src/proto/cmdexpand.pro b/src/proto/cmdexpand.pro index 1ace23c5c..388b80b13 100644 --- a/src/proto/cmdexpand.pro +++ b/src/proto/cmdexpand.pro @@ -3,7 +3,7 @@ int cmdline_fuzzy_complete(char_u *fuzzystr); int nextwild(expand_T *xp, int type, int options, int escape); void cmdline_pum_display(void); int cmdline_pum_active(void); -void cmdline_pum_remove(cmdline_info_T *cclp, int defer); +void cmdline_pum_remove(cmdline_info_T *cclp, int defer_redraw); void cmdline_pum_cleanup(cmdline_info_T *cclp); int cmdline_compl_startcol(void); char_u *cmdline_compl_pattern(void); @@ -25,5 +25,5 @@ int wildmenu_process_key(cmdline_info_T *cclp, int key, expand_T *xp); void wildmenu_cleanup(cmdline_info_T *cclp); void f_getcompletion(typval_T *argvars, typval_T *rettv); void f_getcompletiontype(typval_T *argvars, typval_T *rettv); -void f_cmdcomplete_info(typval_T *argvars UNUSED, typval_T *rettv); +void f_cmdcomplete_info(typval_T *argvars, typval_T *rettv);
/* vim: set ft=c : */
diff --git a/src/proto/diff.pro b/src/proto/diff.pro index b5c59e4a7..3a4929b0c 100644 --- a/src/proto/diff.pro +++ b/src/proto/diff.pro @@ -16,16 +16,14 @@ void diff_clear(tabpage_T *tp); int diff_check_with_linestatus(win_T *wp, linenr_T lnum, int *linestatus); int diff_check_fill(win_T *wp, linenr_T lnum); void diff_set_topline(win_T *fromwin, win_T *towin); -int diffanchors_changed(int local); +int diffanchors_changed(int buflocal); int diffopt_changed(void); int diffopt_horizontal(void); int diffopt_hiddenoff(void); int diffopt_closeoff(void); void diff_update_line(linenr_T lnum); -#ifdef FEAT_DIFF -int diff_change_parse( diffline_T *diffline, diffline_change_T *change, int *change_start, int *change_end); -int diff_find_change( win_T *wp, linenr_T lnum, diffline_T *diffline); -#endif +int diff_change_parse(diffline_T *diffline, diffline_change_T *change, int *change_start, int *change_end); +int diff_find_change(win_T *wp, linenr_T lnum, diffline_T *diffline); int diff_infold(win_T *wp, linenr_T lnum); void nv_diffgetput(int put, long count); void ex_diffgetput(exarg_T *eap); diff --git a/src/proto/ex_docmd.pro b/src/proto/ex_docmd.pro index 6d2961c01..c79d5b4d7 100644 --- a/src/proto/ex_docmd.pro +++ b/src/proto/ex_docmd.pro @@ -16,7 +16,6 @@ int cmdmod_error(int ignore_silent); void apply_cmdmod(cmdmod_T *cmod); void undo_cmdmod(cmdmod_T *cmod); int parse_cmd_address(exarg_T *eap, char **errormsg, int silent); -linenr_T get_address(exarg_T *eap, char_u **ptr, cmd_addr_T addr_type, int skip, int silent, int to_other_file, int address_count); char_u *skip_option_env_lead(char_u *start); int number_method(char_u *cmd); char_u *find_ex_command(exarg_T *eap, int *full, int (*lookup)(char_u *, size_t, int cmd, cctx_T *), cctx_T *cctx); @@ -26,6 +25,7 @@ void f_fullcommand(typval_T *argvars, typval_T *rettv); cmdidx_T excmd_get_cmdidx(char_u *cmd, int len); long excmd_get_argt(cmdidx_T idx); char_u *skip_range(char_u *cmd_start, int skip_star, int *ctx); +linenr_T get_address(exarg_T *eap, char_u **ptr, cmd_addr_T addr_type, int skip, int silent, int to_other_file, int address_count); void ex_ni(exarg_T *eap); int expand_filename(exarg_T *eap, char_u **cmdlinep, char **errormsgp); void separate_nextcmd(exarg_T *eap, int keep_backslash); diff --git a/src/proto/ex_getln.pro b/src/proto/ex_getln.pro index 7270469a2..d37be4bc9 100644 --- a/src/proto/ex_getln.pro +++ b/src/proto/ex_getln.pro @@ -1,4 +1,5 @@ /* ex_getln.c */ +int parse_pattern_and_range(pos_T *incsearch_start, int *search_delim, int *skiplen, int *patlen); void cmdline_init(void); char_u *getcmdline(int firstc, long count, int indent, getline_opt_T do_concat); char_u *getcmdline_prompt(int firstc, char_u *prompt, int attr, int xp_context, char_u *xp_arg); @@ -39,12 +40,11 @@ void f_getcmdscreenpos(typval_T *argvars, typval_T *rettv); void f_getcmdtype(typval_T *argvars, typval_T *rettv); void f_setcmdline(typval_T *argvars, typval_T *rettv); void f_setcmdpos(typval_T *argvars, typval_T *rettv); -void f_wildtrigger(typval_T *argvars, typval_T *rettv); int get_cmdline_firstc(void); int get_list_range(char_u **str, int *num1, int *num2); char *did_set_cedit(optset_T *args); int is_in_cmdwin(void); char_u *script_get(exarg_T *eap, char_u *cmd); void get_user_input(typval_T *argvars, typval_T *rettv, int inputdialog, int secret); -int parse_pattern_and_range(pos_T *is_start, int *search_delim, int *skiplen, int *patlen); +void f_wildtrigger(typval_T *argvars, typval_T *rettv);
/* vim: set ft=c : */
diff --git a/src/proto/gui_gtk_x11.pro b/src/proto/gui_gtk_x11.pro index d019cf0a3..c32572819 100644 --- a/src/proto/gui_gtk_x11.pro +++ b/src/proto/gui_gtk_x11.pro @@ -13,7 +13,7 @@ void gui_mch_show_tabline(int showit); int gui_mch_showing_tabline(void); void gui_mch_update_tabline(void); void gui_mch_set_curtab(int nr); -void gui_gtk_set_selection_targets(GdkAtom); +void gui_gtk_set_selection_targets(GdkAtom selection); void gui_gtk_set_dnd_targets(void); int gui_mch_init(void); void gui_mch_forked(void); diff --git a/src/proto/gui_motif.pro b/src/proto/gui_motif.pro index 400fa8609..2098be406 100644 --- a/src/proto/gui_motif.pro +++ b/src/proto/gui_motif.pro @@ -1,46 +1,2 @@ /* gui_motif.c */ -void gui_x11_create_widgets(void); -void gui_x11_destroy_widgets(void); -void gui_mch_set_text_area_pos(int x, int y, int w, int h); -void gui_x11_set_back_color(void); -void manage_centered(Widget dialog_child); -XmFontList gui_motif_create_fontlist(XFontStruct *font); -XmFontList gui_motif_fontset2fontlist(XFontSet *fontset); -void gui_mch_enable_menu(int flag); -void gui_motif_set_mnemonics(int enable); -void gui_mch_add_menu(vimmenu_T *menu, int idx); -void gui_mch_toggle_tearoffs(int enable); -int gui_mch_text_area_extra_height(void); -void gui_mch_compute_menu_height(Widget id); -void gui_mch_add_menu_item(vimmenu_T *menu, int idx); -void gui_motif_update_mousemodel(vimmenu_T *menu); -void gui_mch_new_menu_colors(void); -void gui_mch_new_menu_font(void); -void gui_mch_new_tooltip_font(void); -void gui_mch_new_tooltip_colors(void); -void gui_mch_destroy_menu(vimmenu_T *menu); -void gui_mch_show_popupmenu(vimmenu_T *menu); -void gui_mch_def_colors(void); -void gui_mch_set_scrollbar_thumb(scrollbar_T *sb, long val, long size, long max); -void gui_mch_set_scrollbar_pos(scrollbar_T *sb, int x, int y, int w, int h); -int gui_mch_get_scrollbar_xpadding(void); -int gui_mch_get_scrollbar_ypadding(void); -void gui_mch_enable_scrollbar(scrollbar_T *sb, int flag); -void gui_mch_create_scrollbar(scrollbar_T *sb, int orient); -void gui_mch_destroy_scrollbar(scrollbar_T *sb); -void gui_mch_set_scrollbar_colors(scrollbar_T *sb); -Window gui_x11_get_wid(void); -char_u *gui_mch_browse(int saving, char_u *title, char_u *dflt, char_u *ext, char_u *initdir, char_u *filter); -int gui_mch_dialog(int type, char_u *title, char_u *message, char_u *button_names, int dfltbutton, char_u *textfield, int ex_cmd); -void gui_mch_show_toolbar(int showit); -int gui_mch_compute_toolbar_height(void); -void motif_get_toolbar_colors(Pixel *bgp, Pixel *fgp, Pixel *bsp, Pixel *tsp, Pixel *hsp); -void gui_mch_show_tabline(int showit); -int gui_mch_showing_tabline(void); -void gui_mch_update_tabline(void); -void gui_mch_set_curtab(int nr); -void gui_motif_menu_fontlist(Widget id); -void gui_mch_find_dialog(exarg_T *eap); -void gui_mch_replace_dialog(exarg_T *eap); -void gui_motif_synch_fonts(void);
/* vim: set ft=c : */
diff --git a/src/proto/gui_xmdlg.pro b/src/proto/gui_xmdlg.pro index 256fad78c..794c5cee7 100644 --- a/src/proto/gui_xmdlg.pro +++ b/src/proto/gui_xmdlg.pro @@ -1,3 +1,2 @@ /* gui_xmdlg.c */ -char_u *gui_xm_select_font(char_u *current);
/* vim: set ft=c : */
diff --git a/src/proto/if_lua.pro b/src/proto/if_lua.pro index 2e5da0c48..8612fea4f 100644 --- a/src/proto/if_lua.pro +++ b/src/proto/if_lua.pro @@ -1,12 +1,2 @@ /* if_lua.c */ -int lua_enabled(int verbose); -void lua_end(void); -void ex_lua(exarg_T *eap); -void ex_luado(exarg_T *eap); -void ex_luafile(exarg_T *eap); -void lua_buffer_free(buf_T *o); -void lua_window_free(win_T *o); -void do_luaeval(char_u *str, typval_T *arg, typval_T *rettv); -int set_ref_in_lua(int copyID); -void update_package_paths_in_lua(void);
/* vim: set ft=c : */
diff --git a/src/proto/if_python.pro b/src/proto/if_python.pro index ee78990af..022a776b1 100644 --- a/src/proto/if_python.pro +++ b/src/proto/if_python.pro @@ -1,13 +1,2 @@ /* if_python.c */ -int python_enabled(int verbose); -void python_end(void); -int python_loaded(void); -void ex_python(exarg_T *eap); -void ex_pyfile(exarg_T *eap); -void ex_pydo(exarg_T *eap); -void python_buffer_free(buf_T *buf); -void python_window_free(win_T *win); -void python_tabpage_free(tabpage_T *tab); -void do_pyeval(char_u *str, dict_T* locals, typval_T *rettv); -int set_ref_in_python(int copyID);
/* vim: set ft=c : */
diff --git a/src/proto/if_python3.pro b/src/proto/if_python3.pro index 63104ab7d..e8c7a8914 100644 --- a/src/proto/if_python3.pro +++ b/src/proto/if_python3.pro @@ -1,14 +1,2 @@ /* if_python3.c */ -int python3_enabled(int verbose); -void python3_end(void); -int python3_loaded(void); -void ex_py3(exarg_T *eap); -void ex_py3file(exarg_T *eap); -void ex_py3do(exarg_T *eap); -void python3_buffer_free(buf_T *buf); -void python3_window_free(win_T *win); -void python3_tabpage_free(tabpage_T *tab); -void do_py3eval(char_u *str, dict_T* locals, typval_T *rettv); -int set_ref_in_python3(int copyID); -int python3_version(void);
/* vim: set ft=c : */
diff --git a/src/proto/if_ruby.pro b/src/proto/if_ruby.pro index cc7c7e6c1..30e1df610 100644 --- a/src/proto/if_ruby.pro +++ b/src/proto/if_ruby.pro @@ -1,11 +1,2 @@ /* if_ruby.c */ -int ruby_enabled(int verbose); -void ruby_end(void); -void ex_ruby(exarg_T *eap); -void ex_rubydo(exarg_T *eap); -void ex_rubyfile(exarg_T *eap); -void ruby_buffer_free(buf_T *buf); -void ruby_window_free(win_T *win); -void vim_ruby_init(void *stack_start); -void do_rubyeval(char_u *str, typval_T *rettv);
/* vim: set ft=c : */
diff --git a/src/proto/insexpand.pro b/src/proto/insexpand.pro index 5b57be988..bc57e0e87 100644 --- a/src/proto/insexpand.pro +++ b/src/proto/insexpand.pro @@ -15,9 +15,9 @@ int ctrl_x_mode_function(void); int ctrl_x_mode_omni(void); int ctrl_x_mode_spell(void); int ctrl_x_mode_line_or_eval(void); +int ctrl_x_mode_register(void); int ctrl_x_mode_not_default(void); int ctrl_x_mode_not_defined_yet(void); -int ctrl_x_mode_register(void); int compl_status_adding(void); int compl_status_sol(void); int compl_status_local(void); @@ -51,27 +51,27 @@ int ins_compl_preinsert_effect(void); int ins_compl_bs(void); void ins_compl_addleader(int c); void ins_compl_addfrommatch(void); +int ins_compl_cancel(void); int ins_compl_prep(int c); char *did_set_completefunc(optset_T *args); void set_buflocal_cfu_callback(buf_T *buf); char *did_set_omnifunc(optset_T *args); void set_buflocal_ofu_callback(buf_T *buf); +void clear_cpt_callbacks(callback_T **callbacks, int count); +void set_buflocal_cpt_callbacks(buf_T *buf); +int set_cpt_callbacks(optset_T *args); char *did_set_thesaurusfunc(optset_T *args); +int set_ref_in_cpt_callbacks(callback_T *callbacks, int count, int copyID); int set_ref_in_insexpand_funcs(int copyID); void f_complete(typval_T *argvars, typval_T *rettv); void f_complete_add(typval_T *argvars, typval_T *rettv); void f_complete_check(typval_T *argvars, typval_T *rettv); +void f_complete_match(typval_T *argvars, typval_T *rettv); void f_complete_info(typval_T *argvars, typval_T *rettv); void ins_compl_delete(void); void ins_compl_insert(int move_cursor); void ins_compl_check_keys(int frequency, int in_compl_func); int ins_complete(int c, int enable_pum); -void free_insexpand_stuff(void); -int ins_compl_cancel(void); -void f_complete_match(typval_T *argvars, typval_T *rettv); int ins_compl_setup_autocompl(int c); -void set_buflocal_cpt_callbacks(buf_T *buf); -int set_cpt_callbacks(optset_T *args); -void clear_cpt_callbacks(callback_T **cb, int count); -int set_ref_in_cpt_callbacks(callback_T *callbacks, int count, int copyID); +void free_insexpand_stuff(void);
/* vim: set ft=c : */
diff --git a/src/proto/option.pro b/src/proto/option.pro index 7429002be..f1f8a33a4 100644 --- a/src/proto/option.pro +++ b/src/proto/option.pro @@ -1,5 +1,4 @@ /* option.c */ -char *did_set_showtabpanel(optset_T *args); void set_init_1(int clean_arg); void set_fencs_unicode(void); void set_string_default(char *name, char_u *val); @@ -64,8 +63,8 @@ char *did_set_previewwindow(optset_T *args); char *did_set_pyxversion(optset_T *args); char *did_set_readonly(optset_T *args); char *did_set_scrollbind(optset_T *args); -char *did_set_shellslash(optset_T *args); char *did_set_maxsearchcount(optset_T *args); +char *did_set_shellslash(optset_T *args); char *did_set_shiftwidth_tabstop(optset_T *args); char *did_set_showtabline(optset_T *args); char *did_set_smoothscroll(optset_T *args); @@ -154,4 +153,5 @@ dict_T *get_winbuf_options(int bufopt); int fill_culopt_flags(char_u *val, win_T *wp); int magic_isset(void); int option_set_callback_func(char_u *optval, callback_T *optcb); +char *did_set_showtabpanel(optset_T *args);
/* vim: set ft=c : */
diff --git a/src/proto/optionstr.pro b/src/proto/optionstr.pro index 9fb8af7e2..734959b60 100644 --- a/src/proto/optionstr.pro +++ b/src/proto/optionstr.pro @@ -1,6 +1,4 @@ /* optionstr.c */ -char *did_set_tabpanelopt(optset_T *args); -int expand_set_tabpanelopt(optexpand_T *args, int *numMatches, char_u ***matches); void didset_string_options(void); void trigger_optionset_string(int opt_idx, int opt_flags, char_u *oldval, char_u *oldval_l, char_u *oldval_g, char_u *newval); void check_buf_options(buf_T *buf); @@ -34,7 +32,7 @@ int expand_set_buftype(optexpand_T *args, int *numMatches, char_u ***matches); char *did_set_casemap(optset_T *args); int expand_set_casemap(optexpand_T *args, int *numMatches, char_u ***matches); int expand_set_clipboard(optexpand_T *args, int *numMatches, char_u ***matches); -char * did_set_clipmethod(optset_T *args); +char *did_set_clipmethod(optset_T *args); int expand_set_clipmethod(optexpand_T *args, int *numMatches, char_u ***matches); char *did_set_chars_option(optset_T *args); int expand_set_chars_option(optexpand_T *args, int *numMatches, char_u ***matches); @@ -139,6 +137,8 @@ char *did_set_renderoptions(optset_T *args); char *did_set_rightleftcmd(optset_T *args); int expand_set_rightleftcmd(optexpand_T *args, int *numMatches, char_u ***matches); char *did_set_rulerformat(optset_T *args); +char *did_set_tabpanelopt(optset_T *args); +int expand_set_tabpanelopt(optexpand_T *args, int *numMatches, char_u ***matches); char *did_set_scrollopt(optset_T *args); int expand_set_scrollopt(optexpand_T *args, int *numMatches, char_u ***matches); char *did_set_wlseat(optset_T *args); diff --git a/src/proto/os_mswin.pro b/src/proto/os_mswin.pro index e8e08d2ee..7180f8d0b 100644 --- a/src/proto/os_mswin.pro +++ b/src/proto/os_mswin.pro @@ -1,5 +1,4 @@ /* os_mswin.c */ -void SaveInst(HINSTANCE hInst); void mch_exit_g(int r); void mch_early_init(void); int mch_input_isatty(void); @@ -54,7 +53,7 @@ void serverProcessPendingMessages(void); char *charset_id2name(int id); char *quality_id2name(DWORD id); void gui_mch_expand_font(optexpand_T *args, void *param, int (*add_match)(char_u *val)); -UINT WINAPI vimGetDpiForSystem(void); +UINT vimGetDpiForSystem(void); int get_logfont(LOGFONTW *lf, char_u *name, HDC printer_dc, int verbose); void channel_init_winsock(void); /* vim: set ft=c : */ diff --git a/src/proto/os_vms.pro b/src/proto/os_vms.pro index b58118d88..646ed6d76 100644 --- a/src/proto/os_vms.pro +++ b/src/proto/os_vms.pro @@ -1,16 +1,2 @@ /* os_vms.c */ -void mch_settmode(tmode_T tmode); -int mch_get_shellsize(void); -void mch_set_shellsize(void); -char_u *mch_getenv(char_u *lognam); -int mch_setenv(char *var, char *value, int x); -int vms_sys(char *cmd, char *out, char *inp); -char *vms_tolower(char *name); -int vms_sys_status(int status); -int vms_read(char *inbuf, size_t nbytes); -int mch_expand_wildcards(int num_pat, char_u **pat, int *num_file, char_u ***file, int flags); -int mch_expandpath(garray_T *gap, char_u *path, int flags); -void *vms_fixfilename(void *instring); -void vms_remove_version(void *fname); -int RealWaitForChar(int fd, long msec, int *check_for_gpm, int *interrupted);
/* vim: set ft=c : */
diff --git a/src/proto/popupwin.pro b/src/proto/popupwin.pro index d8df6f35a..e92d5eb21 100644 --- a/src/proto/popupwin.pro +++ b/src/proto/popupwin.pro @@ -64,8 +64,8 @@ void f_popup_findpreview(typval_T *argvars, typval_T *rettv); int popup_create_preview_window(int info); void popup_close_preview(void); void popup_hide_info(void); -int popup_overlaps_cmdline(void); void popup_close_info(void); +int popup_overlaps_cmdline(void); win_T *popup_get_message_win(void); void popup_show_message_win(void); int popup_message_win_visible(void); diff --git a/src/proto/sound.pro b/src/proto/sound.pro index c6d0541f9..8c170137c 100644 --- a/src/proto/sound.pro +++ b/src/proto/sound.pro @@ -1,14 +1,3 @@ /* sound.c */ -typedef struct soundcb_S soundcb_T; - int has_any_sound_callback(void); -int has_sound_callback_in_queue(void); -void call_sound_callback(soundcb_T *soundcb, long sound_id, int result); -void delete_sound_callback(soundcb_T *soundcb); -void invoke_sound_callback(void); -void f_sound_playevent(typval_T *argvars, typval_T *rettv); -void f_sound_playfile(typval_T *argvars, typval_T *rettv); -void f_sound_stop(typval_T *argvars, typval_T *rettv); -void f_sound_clear(typval_T *argvars, typval_T *rettv); -void sound_free(void);
/* vim: set ft=c : */
diff --git a/src/proto/tabpanel.pro b/src/proto/tabpanel.pro index 617f802c2..d62d13f3a 100644 --- a/src/proto/tabpanel.pro +++ b/src/proto/tabpanel.pro @@ -1,7 +1,7 @@ /* tabpanel.c */ +int tabpanelopt_changed(void); int tabpanel_width(void); int tabpanel_leftcol(void); -int tabpanelopt_changed(void); void draw_tabpanel(void); int get_tabpagenr_on_tabpanel(void); /* vim: set ft=c : */ diff --git a/src/proto/usercmd.pro b/src/proto/usercmd.pro index dcf2a1dbe..8c53f562b 100644 --- a/src/proto/usercmd.pro +++ b/src/proto/usercmd.pro @@ -9,7 +9,7 @@ char_u *get_user_cmd_addr_type(expand_T *xp, int idx); char_u *get_user_cmd_flags(expand_T *xp, int idx); char_u *get_user_cmd_nargs(expand_T *xp, int idx); char_u *get_user_cmd_complete(expand_T *xp, int idx); -char_u *cmdcomplete_type_to_str(int expand, char_u *arg); +char_u *cmdcomplete_type_to_str(int expand, char_u *compl_arg); int cmdcomplete_str_to_type(char_u *complete_str); char *uc_fun_cmd(void); int parse_compl_arg(char_u *value, int vallen, int *complp, long *argt, char_u **compl_arg); diff --git a/src/proto/vim9generics.pro b/src/proto/vim9generics.pro index 2fcae4db7..2d7c5d79c 100644 --- a/src/proto/vim9generics.pro +++ b/src/proto/vim9generics.pro @@ -2,7 +2,7 @@ char_u *generic_func_find_open_bracket(char_u *name); int skip_generic_func_type_args(char_u **argp); char_u *append_generic_func_type_args(char_u *funcname, size_t namelen, char_u **argp); -char_u *get_generic_func_name(ufunc_T *fp, char_u **arg); +char_u *get_generic_func_name(ufunc_T *fp, char_u **argp); char_u *parse_generic_func_type_args(char_u *func_name, size_t namelen, char_u *start, gfargs_tab_T *gfatab, cctx_T *cctx); char_u *parse_generic_func_type_params(char_u *func_name, char_u *p, gfargs_tab_T *gfatab, cctx_T *cctx); void generic_func_init(ufunc_T *fp, gfargs_tab_T *gfatab); @@ -10,10 +10,10 @@ void generic_func_args_table_init(gfargs_tab_T *gfatab); int generic_func_args_table_size(gfargs_tab_T *gfatab); void generic_func_args_table_clear(gfargs_tab_T *gfatab); void copy_generic_function(ufunc_T *fp, ufunc_T *new_fp); -ufunc_T *eval_generic_func(ufunc_T *ufunc, char_u *name, char_u **arg); -int generic_func_call(char_u **arg); +ufunc_T *eval_generic_func(ufunc_T *ufunc, char_u *name, char_u **argp); +int generic_func_call(char_u **argp); ufunc_T *generic_func_get(ufunc_T *fp, gfargs_tab_T *gfatab); -ufunc_T *find_generic_func(ufunc_T *ufunc, char_u *name, char_u **arg); -type_T *find_generic_type(char_u *type_name, size_t namelen, ufunc_T *ufunc, cctx_T *cctx); +ufunc_T *find_generic_func(ufunc_T *ufunc, char_u *name, char_u **argp); +type_T *find_generic_type(char_u *gt_name, size_t name_len, ufunc_T *ufunc, cctx_T *cctx); void generic_func_clear_items(ufunc_T *fp); /* vim: set ft=c : */
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#17851)cproto version info. on Ubuntu 22.04.5 LTS.
$ cproto -V 4.7t
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)Ok so I see that with a bit of work, on Ubuntu make proto should work as intended. By this I mean in particular that make proto should be idempotent.
Funnily enough, from the output you shared, one can see that the .pro files need to be updated.
cproto -V 4.7x
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#17851)After running make clean, make proto fails. (All prototype declarations in .pro are lost.)
In my environment, I had to perform at least the following steps:
(It would be a good idea to review the dependencies in the Makefile.)
$ make clean $ make auto/osdef.h $ make auto/gui_gtk_gresources.h $ make proto
Funnily enough, from the output you shared, one can see that the .pro files need to be updated.
Yeah. Most people don't run make proto and instead modify .pro manually.
Only occasionally does someone notice and update it...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17851)Yes, even Bram did traditionally run make proto only shortly before a new release. https://github.com/vim/vim/blob/397b9da29d29a96d92ebdfd9d6bf379249519fa1/Makefile#L103-L114
I did this last time also before releasing v9.1
And I think this is fine, otherwise you would always need a full/complete build to generate all files.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)Thanks for the clarification. That makes sense regarding the build process.
I’d like to better understand the design rationale behind the prototype generation. What are the perceived advantages of the auto-generated .pro file system compared to a more traditional model where each .c file has a corresponding .h file containing its public function declarations ? I’m sure there are trade-offs and I’m keen to learn the reasoning for this project and also document it to help onboarding the future contributors.
On a related note concerning the developer workflow, how should make depend be used ? (It also has issues on macOS) Is it similar to make proto, intended primarily for release maintenance, or is it something developers should run more frequently ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)@h-east Yes, I noticed that also and I planned to update the Makefile dependencies. But you know “one thing at a time” 😄
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17851)On a related note concerning the developer workflow, how should
make dependbe used.
I wasn't even aware of that until now 🤷
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
ychin left a comment (vim/vim#17851)make depend is the target that generates all the Makefile incremental build dependneices. On MacVim, which is downstream of Vim, I just run make depend to re-generate all the dependencies in the Makefile. The result tends to be different from the upstream Vim because of similar reasons to why make proto is so. The different environment and build configuration would affect these tools and result in the compiler behaving differently. For contributing upstream though I think it's tricky to call this script.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)I have identified at least three paths forward :
- Drop
make proto— Move to manual headers. - Fix
make protoon macOS — This would require creating dozens of mock system headers to keepcprotohappy. - Keep automatic generation but replace
cproto— Useclangor an in-house script to extract prototypes.
My vote goes to Option 1. It solves the portability problem permanently, and since people already edit the .pro files by hand, it seems like a natural step. What trade-offs am I missing ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17851)How much effort is this to use manual headers? Hopefully it is possible to generate this somehow. We can than probably also get rid of the #if defined(PROTO) across the whole code base.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)We could turn the C requirement for function prototypes into a benefit for the project. By treating header files as the formal API for each module – with function prototypes fully documented in a format like Doxygen – it could improve maintainability and make it easier for new contributors to navigate the codebase.
The current architecture, centered on a monolithic vim.h and a custom .pro file system, is quite unconventional. As such, the burden of proof is on the project to justify its continued use. It needs to be demonstrated why this bespoke system is superior to the standard C practice of pairing implementation files (e.g., foo.c) with corresponding headers (foo.h), especially in a modern development context.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#17851)I have identified at least three paths forward :
- Drop
make proto— Move to manual headers.- Fix
make protoon macOS — This would require creating dozens of mock system headers to keepcprotohappy.- Keep automatic generation but replace
cproto— Useclangor an in-house script to extract prototypes.My vote goes to Option 1. It solves the portability problem permanently, and since people already edit the
.profiles by hand, it seems like a natural step. What trade-offs am I missing ?
If we keep the current system but manually edit files, we risk that they aren't synchronized. So (1) for me would need to be paired with some other script or tool that lints the headers to make sure they are accurate.
Even on GNU/Linux, the
prototarget needs to be fixed.git clone && make protowill fail out of the box because as @h-east says there are dependencies to runmake proto.
I mean, this is true of many projects with developer dependencies. What do you propose? I recommend simply documenting the cproto dependency (and any others) in a contributing/hacking/developer guide.
Moreover,
make protoalways rebuilds all the.profiles and since the Makefile only can be used with POSIX1.2001 it means that one must add dozens of lines to the Makefile of the following form
That's not correct AIUI: none of our makefiles set .POSIX:, and I found at least one GNU-ism in src/Makefile (AUTOCONF ?= autoconf).
proto/alloc.pro: alloc.c @mkdir -p proto $(CPROTO) -DFEAT_GUI $< > $@
We already have separate targets for all objects/ files. What's one more for the proto files? Also, looking at the current rules, I'm not sure I understand why it's the case that we need these rules (but maybe that's the missing "dependencies" discussed further upthread)?
The current architecture, centered on a monolithic vim.h and a custom .pro file system, is quite unconventional. As such, the burden of proof is on the project to justify its continued use. It needs to be demonstrated why this bespoke system is superior to the standard C practice of pairing implementation files (e.g., foo.c) with corresponding headers (foo.h), especially in a modern development context.
Au contraire, see Chesterton's Fence. The current system may be rough, but a replacement system bears the burden of proof ;)
I for one would welcome a modernized codebase (perhaps structured a bit more like git/git for compilation and code organization), but it may be a lot of churn and work. We also need to keep packagers' lives easy. So again, I'm in favor of improvements, but they probably need a thought-through migration plan and justification.
Something like:
- Build new compiler (make) hooks for whatever pattern we want to use going forward.
- Convert an existing file as proof of the concept. It would continue to build alongside all other objects and link in as normal, so 2 systems interoperate. (This keeps the interface for packagers and maintainers the same, too?)
- If this bears evidence of benefit, slowly convert old files and require new files to follow the new format, perhaps somehow (automatically) marking the old format as deprecated.
- When conversion is complete, declare the old system dead and remove it.
For (3), we could even ask folks proposing changes to a legacy file to also migrate it to the new compilation system, but that adds an extra barrier to contributing that may not have positive effects.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
yegappan left a comment (vim/vim#17851)I'm concerned about dropping the current 'make proto' support without a suitable
automated replacement. The existing system is a valuable tool for identifying mistakes
in manually updated files. Removing it would make it much harder to catch errors.
Currently, there are no reported issues with the proto file generation from any main
Vim developers, so I don't see a clear reason to make this change.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)If we keep the current system but manually edit files, we risk that they aren't synchronized. So (1) for me would need to be paired with some other script or tool that lints the headers to make sure they are accurate.
Usually one mitigation is to have foo.c start with #include "foo.h"
I still haven't seen an accurate indication of what is required to fix the current system and move on.
cproto starts with pre-processing, then all the macOS special functions and symbols, Objective-C extensions etc are pulled in. Then cproto does not know how to deal with them, so it emits tons of errors and includes many basic library functions to the .pro files.
To mitigate this, one could replace all the system headers with mock headers stored in like proto/fake_headers and include this only when make proto is used.
That's not correct AIUI: none of our makefiles set .POSIX:, and I found at least one GNU-ism in src/Makefile (AUTOCONF ?= autoconf).
We already have separate targets for all objects/ files. What's one more for the proto files?
BSD make follows only POSIX1.2001. That is why there are individual objects/foo.o targets.
Au contraire, see Chesterton's Fence. The current system may be rough, but a replacement system bears the burden of proof ;)
Fair enough.
First claim : the current architecture is not documented, top contributors are not aware of some of its parts and I am still waiting for someone to explain the rationale behind it (which after doing research must date back to very early versions of Vim).
Second claim : there is an immediate reason to take actions. Newcomers using macOS (probably not a small market share) cannot use make proto at the moment, yet to make contributions one needs to write function declarations.
Third claim : currently, most people already manually edit the .pro files. So slowly transitioning to .c + .h files will come at a very small cost (again here, I might be not seeing something). The main inevitable cost is the time spent on this discussion to find out what architecture is wished for the project and to document it. I am happy to write the documentation.
Fourth claim : if the project decides on “keeping the current architecture”, this will still require to describe what the “current architecture” is supposed to be, to give rationale and to be documented.
I'm concerned about dropping the current 'make proto' support without a suitable
automated replacement. The existing system is a valuable tool for identifying mistakes
in manually updated files. Removing it would make it much harder to catch errors.
I’d like to understand your concern more. Could you give a small example of an error that could slip through and have an impact in case there were no automated system and each foo.c would simply have #include "foo.h" at the top ?
Currently, there are no reported issues with the proto file generation from any main
Vim developers, so I don't see a clear reason to make this change.
It would be useful to non-main Vim developers if you could :
- Describe the whole header /
.proarchitecture of the Vim project, with the rationale behind it - Describe the typical workflow that is expected
- Describe how you managed to successfully run
make protoon macOS.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
yegappan left a comment (vim/vim#17851)I'm concerned about dropping the current 'make proto' support without a suitable
automated replacement. The existing system is a valuable tool for identifying mistakes
in manually updated files. Removing it would make it much harder to catch errors.
I’d like to understand your concern more. Could you give a small example of an error that could slip through and have an impact in case there were no automated system and each
foo.cwould simply have#include "foo.h"at the top ?
Consider the following prototype in the proto/cmdexpand.pro file:
void f_cmdcomplete_info(typval_T *argvars UNUSED, typval_T *rettv);
The author copied this from the cmdexpand.c file. There is no need to use
UNUSED in the prototype. When you run "make proto", it updates this file
with the correct function signature. These types of errors cannot be detected
without the automated method.
Currently, there are no reported issues with the proto file generation from any main
Vim developers, so I don't see a clear reason to make this change.It would be useful to non-main Vim developers if you could :
- Describe the whole header /
.proarchitecture of the Vim project, with the rationale behind it- Describe the typical workflow that is expected
The current work flow is:
- When adding a new global function, add the function prototype to the corresponding .pro file under the proto directory.
- When modifying the arguments or return value in an existing global function, update the corresponding signature in the .pro file.
- When adding a new file, create a corresponding .pro file with the same file name under the proto directory.
This is a simple workflow.
- Describe how you managed to successfully run
make protoon macOS.
If "make proto" doesn't work on MacOS, then we should focus on adding the proper
support for it instead of completely dropping the automated mechanism.
The make proto system, while perhaps not perfect, is a crucial tool for maintaining code
consistency. Rather than removing it, the focus should be on addressing any existing issues
and ensuring it works correctly across all platforms
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)Thanks for providing that specific example.
Consider the following prototype in the proto/cmdexpand.pro file:
void f_cmdcomplete_info(typval_T *argvars UNUSED, typval_T *rettv);
The author copied this from the cmdexpand.c file. There is no need to use
UNUSED in the prototype. When you run "make proto", it updates this file
with the correct function signature. These types of errors cannot be detected
without the automated method.
You call it an “error”, but is it really ? The code compiles without issue.
The contributor did the most logical thing possible : they made the prototype in the .pro file perfectly match the function’s signature in the .c file (@girishji would you like to tell us if you ever use make proto ?). Isn’t a 1-to-1 match the ideal for clarity and correctness ?
Since correctness is ultimately enforced by the various compilers in CI, this example suggests that make proto serves more as a normaliser or beautifier than as a tool for detecting real semantic problems.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#17851)You call it an “error”, but is it really ? The code compiles without issue. The contributor did the most logical thing possible : they made the prototype in the
.profile perfectly match the function’s signature in the.cfile (@girishji would you like to tell us if you ever usemake proto?). Isn’t a 1-to-1 match the ideal for clarity and correctness ?
make proto on my Mac? Forget it. It throws so many errors I’d rather wrestle a porcupine. I just hand-edit the .pro files instead. Honestly, I don’t mind—it’s kind of nice. They’re clean and bare-bones: just the function prototypes, no random comments or sneaky inline functions hiding in there. Header files are like cluttered attics; give me the “import module” simplicity of other languages any day.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
ychin left a comment (vim/vim#17851)Second claim : there is an immediate reason to take actions. Newcomers using macOS (probably not a small market share) cannot use make proto at the moment, yet to make contributions one needs to write function declarations.
That's a strong claim, especially the immediate part. This really isn't that hard to figure out for most people, and if documentation is lacking we could just add that. Most people are familiar with header files and the concept of "add a function to the .pro file" isn't that hard to figure out / document. Also, right now, most functions are documented in the .c files itself and I personally think that's a fine choice. So even if we switch to using doxygen style comments I don't particularly think it's worth it to switch the comments to .h/.pro files, as this way you keep the explanation close to the actual implementation rather than split between header and implementation files.
I personally don't have a strong opinion on this topic (whether to keep proto or just use more standardized headers), but proposing this as a blocker deserving of immediate attention seems to be some misguided priority here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)I agree, that claim came off stronger than what I had in mind. I assumed that the raison d’être of make proto was to automate prototype generation so that contributors should not have to touch .pro files by hand.
If the expected workflow is to hand-edit the .pro files, then it’s a traditional workflow, not a blocker. 👌
If no comments in header files is the preferred style, that is also worth documenting.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
Shane-XB-Qian left a comment (vim/vim#17851)e.g :
```
# When generating os_amiga.pro and os_win32.pro there will be a
# few include files that can not be found, that's OK.
```
tho i am not a "main" contributor :smile:
even you ran 'make proto' on linux you may find some `#error`,
problem is: you maybe donot know if it was 'ok' or 'not ok' :cry:
as for you pasted error, seems was parsing err? maybe cproto bug?
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17851)Okay, seems we have some preferences here. Let's just add some documentation for the current state of afairs and keep to how it has been setup for 20 years or so.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)How much effort is this to use manual headers? Hopefully it is possible to generate this somehow. We can than probably also get rid of the #if defined(PROTO) across the whole code base.
Thinking about this, I can see that there are quite a lot of #if defined(PROTO) guards and I guess this is only to please cproto. One way of fixing make proto on macOS would be to add even more of them.
Shouldn’t the tool work for the developer instead or the developer needing to please the tool ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)I still haven't seen an accurate indication of what is required to fix the current system and move on.
Hopefully #18007 answers this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#17851)I still haven't seen an accurate indication of what is required to fix the current system and move on.
Hopefully #18007 answers this.
Thanks!
The files
sound.proanddiff.procannot be automatically generated bycprotobecause they contain more than function declarations. Yet they are in the list of files generated bymake proto.
Perhaps they need their own rules then? There are already exceptional recipes for certain files.
Those example remind me of a typical rule of header files : they should compile on their own. This is not the case with the
.profiles.
Where have you come across that? Compiling a header file doesn't make any sense to me, as it's unlikely to have any implementation to generate an object file for.
It's true that you can put any code in an included file, though, so I know some folks make "single file libraries" that are just header files.
In the world you suggest where we put prototypes and possibly docs in .h files, though, I'm not sure what it means to compile a header file.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)Where have you come across that?
Google C++ style guide for example.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#17851)Perhaps they need their own rules then? There are already exceptional recipes for certain files.
But then why have
.profiles if they are not purely automatically generated and with only prototypes ?
That's throwing the baby out with the bathwater: if most of them are auto-generated and a few need special care, that's still better than nothing.
Where have you come across that?
Google C++ style guide for example. Actually another rule in that guide is “only include what you use” whereas currently files include everything via
vim.h.
But we are neither Google nor C++.
You omitted most of my reply, so I'll restate: what does it mean to compile a header file in this context, anyway?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)You omitted most of my reply, so I'll restate: what does it mean to compile a header file in this context, anyway?
It means that the file is a valid translation unit.
That's throwing the baby out with the bathwater: if most of them are auto-generated and a few need special care, that's still better than nothing.
Let’s do it in reverse, how many files require no tailored intervention to make cproto output the .pro file correctly ? Some need post-processing (with tailored make rules) and most need pre-processing with #ifdef PROTO.
All of this to have .pro files that cannot be included on their own because they are not valid translation units.
But we are neither Google nor C++.
Really ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#17851)You omitted most of my reply, so I'll restate: what does it mean to compile a header file in this context, anyway?
It means that the file is a valid translation unit.
Ok, digging in, this answer made more sense of the idea. It seems like this is a useful check of the forward declarations being valid, but otherwise serves little purpose.
That's throwing the baby out with the bathwater: if most of them are auto-generated and a few need special care, that's still better than nothing.
Let’s do it in reverse, how many files require no tailored intervention to make
cprotooutput the.profile correctly ? Some need post-processing (with tailored make rules) and most need pre-processing with#ifdef PROTO. All of this to have.profiles that cannot be included on their own because they are not valid translation units.
I agree it would be nice if they needed less work and stood on their own, but you've subtly changed the question. The original was
But then why have .pro files if they are not purely automatically generated and with only prototypes ?
and now you ask
how many files require no tailored intervention to make
cprotooutput the.profile correctly ?
That's more about the work required in source files than about the question of having prototype files in the first place.
Anyway, I broadly agree that playing preprocessor games just to satisfy a tool doesn't add much value. It's just that the current prototype files do have some value to some folks, so we either renovate that system to reduce the churn or we switch to a new one. I outlined a possible way to do that for folks that are interested.
Going back-and-forth about what value is added seems not particularly useful anymore, since we've established there is some. I'd rather compare approaches for moving forward with (incremental) improvements, personally.
Some notes on Make and POSIX
While I'm here, I can't resist:
That's not correct AIUI: none of our makefiles set .POSIX:, and I found at least one GNU-ism in src/Makefile (AUTOCONF ?= autoconf).
We already have separate targets for all objects/ files. What's one more for the proto files?
BSD make follows only POSIX1.2001. That is why there are individual objects/foo.o targets.
I still do not find any requirement that our Makefiles use POSIX-only syntax or semantics. In fact, I see in src/INSTALL
GNU Autoconf and a few other tools have been used to make Vim work on many
different Unix systems. The advantage of this is that Vim should compile
on most systems without any adjustments. The disadvantage is that when
adjustments are required, it takes some time to understand what is happening.
and I see in src/Makefile
# Run the libvterm tests.
# This works only on GNU make, not on BSD make.
# Libtool requires "gcc".
test_libvterm:
@if $(MAKE) --version 2>/dev/null | grep -qs "GNU Make"; then \
if test -x "/usr/bin/gcc"; then \
cd libvterm; $(MAKE) -f Makefile test CC="$(CC)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"; \
fi \
fi
Fortunately we do mostly appear to use compatible constructs, and I'm surprised that the NetBSD make I have doesn't choke on AUTOCONF ?= autoconf when .POSIX: is set early on. So we definitely ought to try to stay portable (which is valuable irrespective of the rest of this conversation).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)Going back-and-forth about what value is added seems not particularly useful anymore, since we've established there is some. I'd rather compare approaches for moving forward with (incremental) improvements, personally.
Completely agree. That’s what I am spending so much time to try to convince people that trying to fix make proto is a bad idea. And that among the possible ways forward, there is at least one that is not more expensive than the status quo.
reply on POSIX syntax and make
While I'm here, I can't resist
Don’t, I am happy to have that kind of conversation.
I still do not find any requirement that our Makefiles use POSIX-only syntax or semantics.
I have added some lines on that subject in develop.txt. Also be careful, which POSIX ? BSD make is not POSIX compliant for later POSIX standards.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
ychin left a comment (vim/vim#17851)You omitted most of my reply, so I'll restate: what does it mean to compile a header file in this context, anyway?
It means that the file is a valid translation unit.
That's not really what it means though. It just means if you include a header file you won't immediately have a compiler error because you were supposed to pre-set other ifdefs or include another header files. None of our .pro files violate it since they just contain a bunch of forward declared functions. No one compiles header files as a standalone translation units since you always just compile .c (or .cpp / .cc) files instead.
Actually another rule in that guide is “only include what you use” whereas currently files include everything via vim.h.
It's honestly also not that uncommon to have modules that have a single header file to include. It really depends on how many headers you have and how fast incremental build is and how often we expect the headers to be changed. There are also large C++ projects that use pre-compiled headers that just includes a bunch of common header includes. No single coding style guide is going to work everwhere.
Completely agree. That’s what I am spending so much time to try to convince people that trying to fix make proto is a bad idea. And that among the possible ways forward, there is at least one that is not more expensive than the status quo.
I don't think anyone else here was arguing that we necessarily need to fix make proto on macOS. The argument is more "don't break the existing stuff".
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#17851)I still do not find any requirement that our Makefiles use POSIX-only syntax or semantics.
I have added some lines on that subject in develop.txt. Also be careful, which POSIX ? BSD make is not POSIX compliant for later POSIX standards.
Ah, thank you. Perhaps we should adjust the AUTOCONF ?= autoconf definition, then, since I don't see that specified by the later versions of POSIX I checked (I don't have a handy link to POSIX.1-2001 mentioned in runtime/doc/develop.txt)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien Lejay
dlejay left a comment (vim/vim#17851)The issue of make proto and the PROTO macros seems to be linked also with make depend.
make depend also fails on macOS.
@chrisbra didn’t know make depend existed, could someone explain what is the current state of affair with that target ? What would be the adverse consequences if it didn’t exist ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.