Discussion :

[Paul TOTH]

Bonjour,

J'ai développé un PDF Viewer sous Delphi qui exploite une PDFium.DLL
https://github.com/tothpaul/PDFiumReader

cela fonctionne bien mais l'API de PDFium est trop limitée pour ce que je voudrais faire...du coup je voudrais créer une nouvelle DLL mais pas moyen de compiler ce foutu code sous Visual Studio

j'ai tenté de suivre les tuto qui parlent de ninja et autres outils exotiques, et j'obtiens une compilation du code, mais pas de DLL

j'ai bien tenté de partir de zéro, c'est à dire créer un projet DLL sous VS (ça je sais faire) puis de lier le code de PDFium pour créer ma propre API mais là encore j'ai des tas d'erreurs qui sont très logiquement dues aux problèmes de configuration des dépendances (un truc très pénible en C++ pour un développeur Delphi où tout est explicitement déclaré).

Est-ce que par hasard il y a un développeur C++ par ici qui aurait déjà joué avec cela et qui voudrait bien partager une Solution VS qui fonctionne ?

pour info je suis parti des depot_tools
https://chromium.googlesource.com/ch...epot_tools.git

et en suivant ceci https://pdfium.googlesource.com/pdfium/

Code batch :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
set path=%path%;C:\PDFium\depot_tools
set DEPOT_TOOLS_WIN_TOOLCHAIN=0
mkdir repo
cd repo
call gclient config --unmanaged https://pdfium.googlesource.com/pdfium.git
call gclient sync
cd pdfium
call build\install-build-deps.sh
gn args out\Debug

avec la configuration suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
use_goma = false  # Googlers only. Make sure goma is installed and running first.
is_debug = true  # Enable debugging features.
 
# Set true to enable experimental Skia backend.
pdf_use_skia = false
# Set true to enable experimental Skia backend (paths only).
pdf_use_skia_paths = false
 
pdf_enable_xfa = false # Set false to remove XFA support (implies JS support).
pdf_enable_v8 = false  # Set false to remove Javascript support.
pdf_is_standalone = true  # Set for a non-embedded build.
is_component_build = false # Disable component build (must be false)
 
clang_use_chrome_plugins = false  # Currently must be false.

et je lance ninja -C out\Debug pdfiumça mouline un certain temps (932 objets à compiler)

avec ça j'obtiens, entre autre un fichier PDFium.lib mais VS ne semble pas l'aimer, peut-être car il contient l'entête !<thin> qui est encore un format à la con si j'ai bien compris, avec des .obj externes
https://stackoverflow.com/questions/...a-thin-archive

donc je me retrouve sans DLL, avec un .lib que je ne sais pas exploiter et sans savoir comment produit une DLL avec ninja

Quelqu'un peut m'éclairer ?

Merci

[bacelar]

Si j'ai bien compris le machin en lisant rapidement en diagonale vos références, c'est un peu fermé comme architecture.

(remarque :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set path=%path%;C:\PDFium\depot_tools

à en croire la doc, il vaut mieux le faire dans l'autre sens.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set path=C:\PDFium\depot_tools;%path%

)

Si vous n'êtes pas un développeur C++, il y a peut-être des trucs qui vous semble étranges et qui vous conduise à faire des trucs "impossibles".

Alors, on va commencer par des trucs "évident" pour un développeur C++, mais c'est toujours important de revoir les bases.

Visual Studio n'est pas une chaine de compilation C++, mais un IDE gérant un grand nombre de langage via des modules.
Jusqu'à récemment, le seul "module" de compilation C++ s'intégrant complètement à VS était MSVC.
Depuis peu, les outils de la chaine de compilation Clang sont supportés "partiellement".
Mais rien n'empêche d'utiliser une chaine de compilation autre depuis VS mais l'intégration dans l'IHM est beaucoup moins poussée. Il faut faire des trucs à la main.
Comme par exemple quand vous utiliser NMAKE, très proche du MAKE d'Unix, les modifications dans les "sources" du système de build sont à votre charge.
En gros, avec NMAKE, on peut juste demander une compilation(génération de l'exécutable), un nettoyage des fichiers générés, démarrer une session de debugging, et utiliser l'éditeur de texte de VS, point barre.
Vous ajoutez un cpp au projet => vous devez éditer vous-même les fichiers utilisés par NMAKE.
Ninja, c'est un peu comme l'utilisation de NMAKE.
Sauf que pas mal de personnes ont créez des outils pour pallier aux limitations de ce type de "non intégration" à VS.
Mais il reste que la chaine de compilation n'est pas vraiment gérée par VS mais par les fichiers de paramétrage du système de build Ninja.
VS, comme dans le cas NMAKE ne peut demander que très peu de chose différente à la chaine de compilation que Ninja à configuré.
La chaine de compilation utilisée par ninja n'est pas explicitement donnée dans la documentation (ou j'ai lu trop vite), mais si c'était MSVC, on aurait pas tous ces outils ad hoc à installer dans VS pour gérer les fichiers "Ninja".
En C++, la chaine de compilation a une grande importance car tous les fichiers intermédiaires entre le code sources que vous tapez dans un éditeur et le module exécutable générés (code assembleur, fichier objet, fichier librairie/archive, ...) ne sont pas standardisés.
Comme ils ne sont pas standardisés, il est très compliqué (voir impossible) de prendre l'un généré par une chaine de compilation et l'utiliser ensuite dans une autre, et les fichiers .lib/.a sont des fichiers intermédiaire.
Le code source C++ devrait suivre le standard C++ (qui évolue tous les 3 ans actuellement) mais il est assez répandu d'avoir des codes sources C++ dit "non portable" qui ne sont compilable par n'importe quel compilateur C++ "standard".
Il n'est pas exclure que les sources que vous cherchiez à compiler ait des parties "non portable". Ce qui expliquerait l'usage d'outils "exotiques" et pas des trucs plus standard comme CMake.
Le format du fichier .dll est imposé par l'OS et est le même quelque soit le langage du code source, donc quelque soit la chaine de compilation.
Ce qui fait que pour de l’interfaçage entre modules, on part plutôt d'un extracteur d'informations depuis le .dll que depuis un .lib.

Si vous ne faites pas de réglage particulier dans VS et que vous partez bille en tête, vous vous retrouvez avec un projet C++ qui prend comme chaine de compilation MSVC, qui sera donc incapable d'utiliser des .lib/.a issue d'autres chaines de compilation.
Il y a une petite particularité pour les lib issues de MSCV, c'est que les .lib fournis par M$ pour pouvoir attaquer les API de l'OS sont construites avec MSVC, toutes les autres chaines de compilation qui doivent pouvoir générer des exécutable qui attaquent, directement ou indirectement, les API de l'OS doivent pouvoir lire ou convertir ces .lib MSVC vers leur format de .lib.

Sachant les détails que je viens d'exposer, je ne suis pas sûr que vouloir faire une Dll à partir de MSVC, en utilisant des .lib générées par une chaine de compilation inconnue pilotée par des fichiers de configuration de Ninja, soit la solution la plus simple et la plus directe.

Généralement, pour ne pas se compliquer la vie, soit on modifie les sources du projet initial, sans changer de chaine de compilation, soit on joue, si la conception de l'API de la Dll le permet, la stratégie des poupées russes : la nouvelle Dll appelle les fonctions de la Dll "de base". Pour la stratégie à la poupée russe, il suffit d'avoir un outil qui génère un .lib au format de la chaine de compilation à partir de la Dll.

Il existe aussi la méthode de tout recompiler avec la nouvelle chaine de compilation mais cela vous expose aux problèmes de "non portabilité" possibles. Et que je pense très probable vu la nature un peu exotique des outils.

[Paul TOTH]

Bonjour,

Merci pour cette réponse qui me conforte dans mon sentiment.

je vais préciser ma démarche, comme je ne suis pas à l'aise avec le C++, il est pour moi plus simple d'avoir un IDE comme VS pour gérer un projet C++...mais en effet PDFium ne propose pas de "Solution" toute faite pour VS, j'ai bien trouvé le projet PdfiumBuild, sauf que les modifications qu'il recommande ici ne fonctionnent plus avec les derniers sources, notamment "Change static_library("pdfium") to shared_library("pdfium")" ne fonctionne pas car on a maintenant jumbo_static_library("pdfium") qui n'a pas d'équivalent static j'ai bien compris que c'est pour cela que j'ai un .LIB et non une DLL mais ça ne m'avance pas beaucoup.

du coup je suis tout à fait près à porter le costume de ninja pour faire une DLL sous Notepad++ à compiler en ligne de commande...sauf que là je suis comme une poule devant un couteau, je n'ai pas la moindre idée de comment déclarer un projet ninja compatible avec la toolchain de PDFium qui me produise une DLL :/ le seul exemple proposé pdfium_test.cc que je pourrait modifier, produit un .exe...je suppose que ça se passe dans BUILD.gn mais ça ne me parle pas beaucoup :/

[bacelar]

Ok, quelques détails lors de ma lecture rapide m'avait échappés.

Avant de sortir l'artillerie lourde, il faudrait évaluer les modifications/ajouts que vous comptez effectuer.
En fonction de cette évaluation, des approches plus ou moins simples peuvent être plus adaptées que d'autres.

En résumé, le dépôt officiel de Google n'offre qu'une version LIB du projet Ninja de "pdfium".
Le projet Ninja de ce projet utilise les outils de Chromium, compilable depuis la chaine de compilation Clang.
Il existe un ensemble d'outils plus ou moins bricolés pour faire en sorte de piloter la compilation et le débogage de Chromium depuis VS mais toujours en le compilant avec Clang.
Le projet PdfiumBuild modifie le projet Ninja pour générer une Dll "pdfium" et met à disposition cette dll via un server de build "https://assendelft.webathome.org/Pdfium/" toutes les semaines mais qui échoue son build depuis début Avril 2018.
Ce même projet PdfiumBuild mais aussi à disposition des packages Nuget (voir lien dans "https://github.com/pvginkel/PdfiumBuild") contenant différentes version de la Dll mais la dernière version date d'il y a 7 mois.
Avez-vous vraiment besoin d'une version plus récente de cette librairie ???
Sinon, en utilisant la stratégie des poupées russe, je vous conseille d'utiliser le Package Nuget qui configurera plus ou moins automatiquement votre Projet VS-MSVC pour pouvoir utiliser facilement la Dll (s'ils ont bien fait le boulot) et étendre ces fonctionnalités.

Aux vues des modifications à faire signalés par le projet "PdfiumViewer", les sources de "pdfium" sont conçues pour être facilement "Dll-isable", ce qui rend étrange la limitation du projet Ninja de "pdfium".
Y-a-t-il eu une évolution majeure il y a 7 mois dans ce projet "pdfium" qui aurait brisées la "Dll-isation" faites pas PdfiumBuild ?
Si c'est le cas, avez-vous besoin des ajouts de ces évolutions ?

Si votre objectif principale est d'avoir une Dll "pdfium" à jour des nouvelles fonctionnalités, je pense qu'il serait plus judicieux de contacter les mainteneurs des projets "PdfiumBuild" et "PdfiumViewer" pour qu'ils réparent rapidement leurs bébés ou pour vous donner des indications précises sur comment le faire ou pourquoi c'est plus possible.

Après, il y a toujours des acrobaties possibles mais il faidrait avoir une vue plus précises des évolutions que vous comptez apporter à cette "Dll".

[Paul TOTH]

alors, manifestement les développeurs de PDFium ne se préoccupent absolument pas de ceux qui veulent l'utiliser comme une DLL, et comme indiqué dans le projet PDFViewer "Google changed their build system (again?), so new instructions.".

Dès lors l'API de PDFium.dll est un choix indépendant de PDFium si je ne m'abuse. Ce que je cherche à faire c'est de rendre les "annotations" éditables, ça fonctionne presque avec la DLL standard mais il me manquerait la possibilité de faire un rendu d'une annotation (celle qui est active) par dessus les autres, et de comprendre pourquoi quand je change la position de certaines d'entres elles via FPDFAnnot_SetRect(), je n'ai pas le résultat escompté.

et tant qu'à faire je me suis dit que si j'étais capable de produire une DLL à partir des sources de PDFium, je pourrais changer librement l'API en tapant aussi bas que je le désire dans le code d'origine..d'où aussi l'idée de pouvoir tracer tout cela sous VS.

En fait j'ai été sans doute mal éduqué par Delphi; dans ce langage, il suffit d'ajouter tous les "uses" (équivalent d'import en Java) de tous les modules nécessaires et hop ça compiler...ou pas, mais le compilateur vous met le nez sur l'erreur car l'édition de liens et la compilation se font en une seule passe en Pascal les liens sont explicites contrairement à l'extern du C qui laisse libre interprétation au linker.

[bacelar]

alors, manifestement les développeurs de PDFium ne se préoccupent absolument pas de ceux qui veulent l'utiliser comme une DLL

Sauf que la présence d'une constante de compilation comme "FPDFSDK_EXPORTS", ça sent quand même un usage, peut-être qu'interne à Google, d'une version Dll, peut-être pour des tests.
Parce que, sinon, ça serait bien plus compliqué de générer une Dll à partir d'un code qui n'a pas été conçu pour.

Comme le projet PdfiumBuild est parti en sucette il y a 7 mois, je crains une rupture de compatibilité des sources. Mais cela impliquerait des modifications majeures dans le projet initial PDFium.

et comme indiqué dans le projet PDFViewer "Google changed their build system (again?), so new instructions."

Attention à la date du post : "Sep 28, 2016"
PdfiumBuild fonctionnait après ce post.
Google a changer un truc, mais PdfiumBuild a réussi à maintenir le système opérationnel.
Est-ce qu'une modification d'encore plus grande ampleur est cassé le système et ça fait 7 mois que les mainteneurs rament ? Moi, je suis plutôt sur l'optique que les mainteneurs ont laissé le projet vivre tout seul via des updates automatiques des sources bien avant les 7 mois. Et que personne n'a cherché à corriger le "problème" même s'il est minime.
C'est en cela que je vous proposais de contacter les différents mainteneurs.

Parce que, si des personnes qui ont réussi à faire PdfiumBuild galèrent à rendre le projet Ninja "Dll-isable", je ne pense pas qu'un non spécialiste du C++ (voir du C, parce que le code dans "pdfium_test.cc", c'est pas super super objet) puisse le faire rapidement, et même un spécialiste qui ne connait pas les projets PDFium et Chromium.

Dès lors l'API de PDFium.dll est un choix indépendant de PDFium si je ne m'abuse.

Je ne comprends pas où vous voulez en venir.
Pour l'instant, la dernière version de PDFium.dll ne correspond pas aux dernières sources de la librairie PDFium fourni par Google, mais à une version plus ancienne.

Ce que je cherche à faire c'est de rendre les "annotations" éditables, ça fonctionne presque avec la DLL standard mais il me manquerait la possibilité de faire un rendu d'une annotation (celle qui est active) par dessus les autres, et de comprendre pourquoi quand je change la position de certaines d'entres elles via FPDFAnnot_SetRect(), je n'ai pas le résultat escompté.

Ce que je comprends de ces choses (je ne connais absolument rien sur ces librairies, désolé), c'est que ce n'est pas un simple ajout mais une modification du comportement.
Il est peut-être possible que vous cherchez avec faire soit implémentable juste pas ajouts mais c'est pas gagné.
Vous pouvez toujours valider ou invalider cette hypothèse en essayant de l'implémenter dans les sources du projet initial, dans la lib donc.
Vous implémentez un client rudimentaire pour tester vos modifications, en utilisant les outils de Google, pas VS-MSVC malheureusement.

Si vous y arrivez juste par ajouts de fonctionnalités et que la version qui a servi de base à la dernière Dll est compatible avec vos modifications, l'approche "poupée russe" peut fonctionner.
Vous créez dans VS-MSVC un projet Dll, où vous mettez le code que vous avez mis au point lors du développement de vos ajouts de fonctionnalité dans l'environnement Google.

Avec un peu d'attention, la compatibilité au niveau code source entre VS-MSVC et Google-Clang ne devrait pas poser trop de problème.
On pourrait faire le même raisonnement sur tout le projet PDFium et pas juste vos modifications, mais comme il n'y a pas de fourniture d'une version du projet directement pour VS ou un outils de génération de projet compatible VS, il y a des chance qu'ils n'ont pas trop fait attention à la portabilité du code entre les compilateurs.
On peut faire attention à la portabilité du code dans vos modifications, mais, à la vue de la taille de PDFium en entier, c'est une tâche bien plus longue, et les mainteneurs de PDFium peuvent ne pas vouloir de vos modifications.

Ensuite, vous intégrez à votre projet VS-MSVC Dll le package Nuget de PdfiumBuild pour pouvoir utiliser la lib compatible MSCV de PDFium.dll et donc utilisez les fonctionnalités de la Dll PDFium.dll pour l'implémentation de votre code.
Moyennant quelques modifications potentielles dans VOTRE code source, votre nouvelle Dll étendant PDFium.dll pourra être utilisée à la place de PDFium.dll (impliquant du code "passe-plat" pour que votre Dll appelle les primitives de PDFium.dll pour les fonctions que vous n'avez pas modifiées mais que vous voulez offrir aux utilisateur de votre nouvelle Dll) ; soit en plus de PDFium.dll , si vos modifications permettent d'utiliser les 2 Dll (la vôtre et PDFium.dll) en même temps.

Si vos modifications ne se contentent pas de juste des ajouts mais des modifications directement dans le projet PDFium, le plus "simple" serait de "réparer" PdfiumBuild pour qu'il génère de nouveau PDFium.dll.
Une fois réparé, vous en servirez pour générer votre version de la Dll PDFium.

Une autre solution, c'est de créer un projet Google-Clang Dll et vous essayez de remettre tout le code de PDFium dedans. La dll généré par cet outil est compatible avec "tout", contrairement à la lib.
Mais, à la vue de la complexité de génération de la lib, remettre tout PDFium dans ce projet, c'est peut-être pas gagné.

P.S: Pourquoi avez-vous besoin absolument d'une version Dll de PDFium et pas juste utiliser les outils Google-CLang pour vous servir de la version LIB, et aussi l'étendre ?

et tant qu'à faire je me suis dit que si j'étais capable de produire une DLL à partir des sources de PDFium, je pourrais changer librement l'API en tapant aussi bas que je le désire dans le code d'origine

Sauf qu'il n'est pas évidant que ces sources aient les qualités de portabilité entre compilateur qui permettent de faire cela facilement.

En fait j'ai été sans doute mal éduqué par Delphi; dans ce langage, il suffit d'ajouter tous les "uses" (équivalent d'import en Java) de tous les modules nécessaires et hop ça compiler...ou pas, mais le compilateur vous met le nez sur l'erreur car l'édition de liens et la compilation se font en une seule passe en Pascal les liens sont explicites contrairement à l'extern du C qui laisse libre interprétation au linker.

C'est la même chose en C++, quand on reste dans la même chaine de compilation.

Comme C++ est bien plus "ouvert" que Delphi, il y a beaucoup d'intervenant dans cet égo-système, qui ne se mettent pas forcement d'accord.
Avec les avancées régulières de normalisation depuis quelques années, on a espoir que cela se simplifie.