Exporting public headers for consumption as a library

[hoheinzollern]

Update: this reverts back to the previous project structure, and only intends to export public headers.

Changes are:

• added build rules to export public headers

I'm happy to take comments on the changes.

[jlaurens]

I have no problem in changing the project structure. The actual layout is tied to TeXLive build system. If we change the layout in GitHub, we must provide some target that updates a local TeXLive repository before committing with svn.

[jlaurens]

I forgot to mention one thing: 3rd party tools also rely on the actual layout.

[hoheinzollern]

Here I rely on you to know what are the constraints and what could be a good option. The only real necessity for consuming this project as a library is that the public headers are clearly separated and exported in the right way. Also, with commit 7dd91ed I changed some of the variable names to follow the standard naming in meson.

[jlaurens]

I think this is not a good idea to change the name synctex test files to test because some tests cannot be automated (they rely on 3rd party tools that may be not be available, whether not installed or inexistent for some OS). Instead, a new test directory with only completely automated tests would be more appropriate. The parts of the actual synctex test files folder that can be automated can then move to the test directory, one after the other.

Moreover, starting with a white page allows to organize things more properly. Here is a sketch of testing as I see it, rather complicated at first glance...

• use lua scripting language and texlua as interpreter. Version 5.3 of the language, as used in texlua. I favor lua against python because the version management is easier and there is no extra installation step, normally. Moreover, the l3build library can be imported, which is interesting to run tex related tools.
• the contents of the test folder is organized as follows

  test
  testing.lua
  ⟨units_1⟩
  test.lua
  ...
  ⟨units_2⟩
  test.lua
  ...

  Each "⟨units_i⟩" folder is a test suite corresponding to entries in meson.build:

  
  synctex_nomalloc = environment({'MALLOC_PERTURB_': '0'})

test( '⟨units_i⟩/'⟨unit name_j⟩', find_program('texlua'), args: [ 'test.lua' ], workdir: meson.current_source_dir() / 'test/⟨units_i⟩/', env: synctex_nomalloc, )

The `test.lua` imports the testing framework `testing.lua` and drives the tests of this suite.
The test units are gathered by directory and can also belong to a suite in meson acception.
This allows to organize test according to 2 logical dimensions, for example there can be test for big files, forms... gathered in different directories and inside each directory some test for direct synchronization (`synctex view`) and others for reverse synchronization (`synctex edit`). That makes two suites for `meson.build`.

I'll put this in practice for big files to see if that fits.

[hoheinzollern]

This sounds very reasonable. I'll try later to revert the structure changes and see what we get, and if it can be used correctly downstream.

[hoheinzollern]

I think this PR is ready to be merged then after your comment, I reverted the changes in structure, there's only variable names and header exports following the meson naming conventions.