Remove cpp from the build chain

[flh]

Using cpp for preprocessing OCaml files was very convenient, but since we now have pa_ocaml, we should get rid of cpp.

pa_ocaml offers the features we need (#ifdef) and understands OCaml syntax, which will prevents bugs such as the parsing bug on SVG.ml mentionned #1 (C-style comment nested in an OCaml multiline string).

[rlepigre]

Note that I fixed the immediate problem by changing from multi-line C-like comments to single-line comments (// ...) in the source code. Of course, this does not resolve the issue.

On that point, I'm not sure that we should use pa_ocaml everywhere. Perhaps we should simply avoid #ifdef stuff whenever possible. Here is what I propose:

• Confine the use of cpp to the patfonts library,
• Remove support for multiple languages (src/Typography/TypoLanguage.ml),
• Handle multiple database technology differently in src/db/Db.ml (interface with several implementations),
• Remove the else part of #ifdef CAMLZIP in src/Drivers/Pdf/Pdf.ml,
• Handle the PDF_TYPE3_ONLY with a boolean in src/Drivers/Pdf/Pdf.ml.

What do you think?

For the language support part, my argument is that it is too early to have that kind of consideration, and that it is therefore useless.

[flh]

I'm currently trying to remove #ifdefs from src/db/Db.ml. Do you have any example code which actually uses this, so that I can try to modify Db.ml without breaking to many things? (Maybe a question for @craff?)

[rlepigre]

I think there is examples/demo.txp in the repository.

[rlepigre]

Maybe you can juste remove all the #ifdefs, and temporarily require all the database libraries to be installed. sqlite3 is already required anyway, this would only require one more dependency: mysql. I think we should refactor this code so that it relies on database drivers, which would be dynamically loaded modules. In this way, we could compile only those for which the necessary libraries are installed.

Note that we could use a similar approach for the Patoline drivers.

[flh]

I've started working on refactoring the code, by moving all DBMS-specific stuff to separate modules with a common interface so that we can only build modules whose dependencies are satisfied.

I do not see how dynamic loading would improve things.

[rlepigre]

I was just saying that we could change the code of Db so that all the different database drivers have a common interface, that could be loaded independently. If I understand correctly, this is exactly what you are doing.

I was just suggesting that we provide an initialisation function taking a database driver module name, and attempts to load it dynamically, to avoid having to choose the database we want to work with at compile time (or rather linking time).

[craff]

On 18-02-19 14:09:20, Rodolphe Lepigre wrote:

I was just saying that we could change the code of Db so that all the different database drivers have a common interface, that could be loaded independently. If I understand correctly, this is exactly what you are doing.

I was just suggesting that we provide an initialisation function taking a database driver module name, and attempts to load it dynamically, to avoid having to choose the database we want to work with at compile time.

Cool ... I will try to fix the pb of GL and Patonet driver due to partial fix ... Juste doing what I needed for a talk + other things that I do not understand.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

[flh]

I've pushed 16f552b724fbe789cca8350c01745f118e21f3d8 which refactors Db.ml (see commit message).

The source builds correctly with Sqlite3 and Mysql, yet I have no time to run the code and test it. I think I have only moved things around, but feel free to yell at me when your presentation using Db crashes...

(I am a bit frightened by the "disconnect" call in interactive_start_hook, which was previously guarded by a match on an option type, but is now always executed. Should I add an exception handler here, in case the database is already disconnected?)

@craff please tell me if this really breaks your code.

[craff]

Hello,

We will need more of them if we want to support more db, without forcing build dep.

However, we can replace cpp by patoline.

Remark: patonet is already broken ... and i did not have the time to fix it... But this is ennoying.

Cheers, Christophe

Le 18 février 2018 15:35:33 GMT-03:00, flh [email protected] a écrit :

I'm currently trying to remove #ifdefs from src/db/Db.ml. Do you have any example code which actually uses this, so that I can try to modify Db.ml without breaking to many things? (Maybe a question for @craff?)

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/patoline/patoline/issues/5#issuecomment-366536736

-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

[rlepigre]

Why would you replace cpp by Patoline?

The whole point with what @flh is doing is to avoid making choices at compile time. We just enable / disable the compilation of a database interface depending on the presence of the dependencies, that's all.

What's really annoying, and really slows the development of Patoline is that the Patonet code is too invasive. There are pieces everywhere, and this is not right. Patonet is only one of the applications of Patoline, with only one user so far, and such developments should not impact everyone (especially not everyone's ability to install Patoline).

However, the main reason why Patonet was developed this way is that we probably do not have the right interface for drivers. Maybe one solution would be to have an extensible variant type for RawContent.raw, defaulting to the bare minimum (pdf stuff).

Any thoughts on that?

[craff]

Le 22 février 2018 06:33:25 GMT-10:00, Rodolphe Lepigre [email protected] a écrit :

Why would you replace cpp by Patoline?

The whole point with what @flh is doing is to avoid making choices at compile time. We just enable / disable the compilation of a database interface depending on the presence of the dependencies, that's all.

What's really annoying, and really slows the development of Patoline is that the Patonet code is too invasive. There are pieces everywhere, and this is not right. Patonet is only one of the applications of Patoline, with only one user so far, and such developments should not impact everyone (especially not everyone's ability to install Patoline).

However, the main reason why Patonet was developed this way is that we probably do not have the right interface for drivers. Maybe one solution would be to have an extensible variant type for RawContent.raw, defaulting to the bare minimum (pdf stuff).

Any thoughts on that?

Clearly this is better than using any prepro.

We should however enforce the type of the modules.

-- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

[rlepigre]

The type of the modules is obviously enforced, have a look at the Db module.