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.

[Paul TOTH]

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 ?

parce que je travaille sur une grosse application sous Delphi dans laquelle j'affiche des PDF (avec PDFium.dll) sur lesquels je veux pouvoir g�rer les annotations (pas possible avec PDFium.dll en l'�tat).

il est possible de lier des .obj dans un projet Delphi, mais cela ne fonctionne bien qu'avec des .obj sans d�pendances externes (jpeglib, zlib...) car Delphi poss�de son propre runtime diff�rent du C++, et s'il n'est pas simple de g�rer les d�pendances en C++, le faire sous Delphi (avec des .obj) est encore pire.

[bacelar]

Merci pour cette justification tout � fait recevable.

Si j'en crois l'article suivant, il y a pas mal de choses qui bougent dans le domaine de "l'interconnexion", Delphi vers C.
http://rvelthuis.de/articles/articles-cobjs.html

Je pense que vous devriez vous concentrez sur la modification des sources de PDFium pour vos fonctionnalit�s dans la lib Clang, et la cr�ation d'un client �crit en C ou C++ utilisant la librairie statique avec CLang.
VS peut utilisez CLang maintenant.
https://blogs.msdn.microsoft.com/vcb...2016-released/

Si vous n'avez pas besoin des fonctionnalit�s et corrections entre la derni�re version des sources compil� par PdfiumBuild et la derni�re version de PDFium, vous pouvez rapatrier les sources correspondant � cette version et faire vos modifications/extensions depuis ces sources.
Comme elles sont compilables en Dll, si vos modifications restent compatibles avec PdfiumBuild, vous pourrez g�n�rer une version "�tendue" de la Dll via les manipulations impl�ment� dans PdfiumBuild.

Mais il sera toujours possible de sortir/wrapper dans une Dll, g�n�r� avec Clang, juste une partie de l'API que vous avez besoin depuis la derni�re version des sources.

[Paul TOTH]

Bonjour,

Alors j'ai avanc� sur la question, en fait en lisant la doc de GN, j'ai pu cr�er une DLL qui expose ce que je veux, j'ai m�me r�ussi � cr�er une solution qui s'ouvre sous VS

voici la marche � suivre

1) cr�er une DLL dans un sous r�pertoire "dll" par exemple avec un source madll.cc

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
16
17
18
19
20
21
22
23
24
 
#include <windows.h>
#include "public/fpdfview.h"
 
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}
 
int WINAPI test(void) {
  FPDF_InitLibrary();
 ///....
}

dans le m�me r�pertoire, cr�er un fichier BUILD.gn

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
16
 
shared_library("madll") {
  cflags = []
  ldflags = []
  sources = [
    "madll.cc",
  ]
  defines = [
    "PNG_PREFIX",
    "PNG_USE_READ_MACROS",
  ]
  deps = [
    "../:pdfium",
    "//build/win:default_exe_manifest",
  ]
}

� la racine du depo, dans la fichier BUILD.gn il faut ajouter ce source dans le group pdfium_all

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
16
 
group("pdfium_all") {
  testonly = true
  deps = [
    ":pdfium_diff",
    ":pdfium_embeddertests",
    ":pdfium_unittests",
    "//dll:madll,
  ]
  if (pdf_is_standalone) {
    deps += [
      ":fuzzers",
      ":samples",
    ]
  }
}

il ne reste plus qu'� g�n�rer ce qu'il faut pour ninja et VS

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
gn gen out/MaDLL --ide=vs

cela produit un fichier out/MaDLL/all.sln pour Visual Studio

et on peut compiler le projet avec ninja en ligne de commande

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
ninja -C out/MaDLL madll

j'oubliais, pour d�fnir les param�tres de compilation il faut ajouter un fichier out/MaDLL/args.gn

par exemple

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
 
is_component_build = false
is_debug = false
symbol_level = 0
target_cpu = "x86"

il reste quelques zones d'ombre mais j'obtiens une DLL qui fonctionne c'est le but tout de m�me

[bacelar]

Merci pour ce retour tr�s d�taill� sur la marche � suivre.

Je suis tr�s surpris de la "facilit�" de la chose par rapport aux manipulations que faisait PdfiumBuild.

Les personnes de Google ont peut-�tre un peu "rationalis�" leur projet.

Pouvez-vous v�rifier que votre fonction "test" est bien export�, et explort� avec le "mangling" C et pas C++ ?
Utilisez des outils comme dependency walker ( http://www.dependencywalker.com/ ) pour bien v�rifier qu'est-ce qui est export� par la dll en comment.

"FPDF_InitLibrary" devrait d�j� �tre export� correctement, donc pas besoin de la fonction test "dans l'absolu".

Si tout est bien export� ( � absolument v�rifier avec dependency walker ou autre, comme DUMPBIN ), vous �tes dans la situation optimale, en gardant Ninja comme m�canisme de construction.

Attention � ne pas mettre d'appel de fonction "complexe" dans DllMain ("FPDF_InitLibrary" semble �tre le bon exemple de chose � ne pas mettre dans DllMain).

Maintenant que vous avez surmont� tout seul les sp�cificit�s de PDFium, on pourra plus facilement vous aidez sur les aspects purement C++.

[Paul TOTH]

Alors oui j'ai un peu gal�r� sur le mangling en effet, j'�tais pass� par extern "C" pour supprimer le mangling C++ et un .def pour supprimer le manglling C, mais je me retrouvais avec deux exports, "test" et "_test@8", j'ai pu supprimer le second avec WINAPI (je n'ai pas cherch� � comprendre ce que �a d�clarait) et je n'ai pas v�rifi� si le .def �tait toujours n�cessaire.

au niveau C++ je suis aussi un peu perdu, j'ai besoin de d�composer la fonction FDPF_RenderPage

plus exactement, je veux pouvoir afficher une annotation par dessus les autres (celle que je veux d�placer), par d�faut elles sont dans l'ordre naturel ici

comme je suis dans un contexte de rendu � l'�cran, je dois pouvoir simplifier le code mais rien que cette ligne est assez obscure pour moi

si j'en crois la logique du code, �a doit correspondre � la cr�ation d'une instance de CPDF_PageRenderContext qui est suppos�ment lib�r�e ici

mais alors pourquoi ici c'est fait diff�remment, et quand ce contexte est-il supprim� ?

[bacelar]

Flute, il semble qu'il faut un compte Google pour cloner un d�p�t Git sur googlesource ? (� moins que c'est le firewall de la boite qui fait du z�le )

Si vous avez une version op�rationnelle de PDFium.dll que vous avez r�cup�r� de PdfiumBuild, utilisez dependency walker pour bien v�rifier que votre mani�re de g�n�rer la Dll exporte les fonctions de la m�me mani�re que PdfiumBuild.

Cela permettra de savoir ce que Delphi a besoin pour fonctionn�, c'est, ou des noms "mangl�s" pour en d�duire des informations pr�cieuses comme les conventions d'appel (stdcall (� la PASCAL) ou cdecl (� la C)) ; ou des noms "nettoy�s" pour ne pas faire peur � l'usag�, mais qui oblige � une convention d'appel "en d�r" etc...

Si vous supprimez tout "manglling C", via .def, vous pourrez appeler des fonctions avec les mauvaises conventions d'appel, ce qui est catastrophique.

Le C++ est assez souple pour permettre plusieurs conventions d'appel et de passage de param�tres diff�rents. Il faut faire attention, surtout quand on est sur des modules avec des langages de programmation diff�rents, que le code appelant et le code appel� utilise les m�mes conventions, d'o� le "mangling C". Je suis donc assez r�ticent � l'usage .def car il peut cacher de gros probl�mes de convention d'appel.

"test" et "_test@8"

"test" est, normalement, une fonction demandant d'utiliser les conventions d'appel et de passage de param�tre du C (le cdecl)
"_test@8" est, normalement, une fonction demandant d'utiliser les conventions d'appel et de passage de param�tre du PASCAL/API WINDOWS (le stdcall)

Donc, utiliser un .def pour cacher l'un par l'autre, c'est tr�s dangereux.

Il serait plus s�r de bien v�rifier que Delphi n'appelle que des fonctions utilisant des conventions d'appel C et faire les actions n�cessaires pour que la Dll n'exporte que ce type de fonction.
Je suis � peu pr�s s�r que c'est la fonction de la constante de compilation "FPDF_CALLCONV" vue dans les extraits que vous nous avez donn�s.
V�rifiez que sa valeur est en correspondance avec les attentes de Delphi, sinon, je pense que quelques "define" dans les fichiers de build pourrait facilement corriger le probl�me.

j'ai pu supprimer le second avec WINAPI (je n'ai pas cherch� � comprendre ce que �a d�clarait) et je n'ai pas v�rifi� si le .def �tait toujours n�cessaire.

Je ne suis pas s�r de comprendre. "WINAPI", c'est un peu la m�me chose que "stdcall". En ajoutant WINAPI on devrait passer de "test" � "_test@8" et pas l'inverse.

au niveau C++ je suis aussi un peu perdu, j'ai besoin de d�composer la fonction FDPF_RenderPage

Le code n'est pas vraiment un exemple de code "propre". Une fonction de plus de 50 lignes, c'est jamais tr�s bon.
Le code est assez caract�ristique d'une conception assez dat�e du code C++, plus proche du C que du C++ moderne.
Mais il y a l'usage de pas mal de concepts modernes du langage C++.
C'est un peu un code hybride : archa�que mais qui est sur le chemin de l'�volution.
Je signale cela car �a intervient dans les lignes que vous signalez.

"FPDF_EXPORT" dans la signature des fonctions montre bien qu'il y a tout ce qu'il faut pour facilement g�n�rer une Dll, je comprend pas pourquoi Google ne la "diffuse" pas.

plus exactement, je veux pouvoir afficher une annotation par dessus les autres (celle que je veux d�placer), par d�faut elles sont dans l'ordre naturel ici

Il y a peut-�tre d�j� tout ce qu'il faut dans la fonction "DisplayAnnots".
Comme je peux pas cloner ce repot, et qu'il y a beaucoup beaucoup moins de fonctionnalit�s dans "googlesource" que dans GitHub, c'est compliqu� de naviguer dans les sources.

comme je suis dans un contexte de rendu � l'�cran, je dois pouvoir simplifier le code mais rien que cette ligne est assez obscure pour moi

C'est l'un des exemples qu caract�re "hybride" de ce code, qui ne simplifie pas du tout sa lecture.
"pdfium::MakeUnique" doit �tre un pis-all� de "std::make_unique" (https://en.cppreference.com/w/cpp/me...tr/make_unique) ajout� � la norme C++ en 2014 (C++14).
Dans la pr�sentation du projet Chromium, c'est indiqu� que les sources doivent �tre C++11 (la norme C++ publi�e en 2011) mais que les ajouts de C++14 sont en cours "d'�valuation/migration".
En gros, le d�veloppeur a voulu utiliser les m�mes "concepts" que le C++14 mais sans utiliser les options de compilations qui vont avec (peur de se faire taper sur les doigts par les mainteneurs du projet, Google ?).

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

pdfium::MakeUnique<CPDF_PageRenderContext>()

Si c'est bien le cas, cette ligne, c'est la version "bricol�" de la mani�re standard (C++14) de cr�er un objet "dynamique" en m�moire.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

std::make_unique<CPDF_PageRenderContext>()

En version archa�que, super-compliqu� � maintenir correctement sans suite m�moire, du C++, �a donnerai simplement :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

 new CPDF_PageRenderContext

si j'en crois la logique du code, �a doit correspondre � la cr�ation d'une instance de CPDF_PageRenderContext qui est suppos�ment lib�r�e ici

Oui.

C'est assez bizarre comme mani�re de faire. On utilise des concepts super �volu�s (C++14) mais comme si on �tait encore dans du vieux code.
�a donne un code peu �l�gant, comme du vieux code, aussi dangereux (fuite m�moire) que du vieux code, mais avec de nouveaux outils.

mais alors pourquoi ici c'est fait diff�remment, et quand ce contexte est-il supprim� ?

Bin, ici, il s'est m�me pas pris la t�te a utilis� pleinement les nouveaux concepts et fait un autre bricolage pour arriver au m�me.
Normalement, c'est lib�r� de la m�me mani�re, "pdfium::WrapUnique" doit "vampiriser" la variable "pContext".
Apr�s vampirisation, utiliser "pContext" donne des comportements ind�termin�s.
C'est pour cela que la version "std::make_unique/pdfium::MakeUnique" est plus "safe".

[Paul TOTH]

Merci pour ces retours

alors dans Delphi c'est tr�s simple d'utiliser une DLL en lien statique (sinon c'est comme en C, LoadLibrary/GetProcAdress)

Code delphi :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
function test: integer; external 'madll.dll'; stdcall;

tout est indiqu� dans le source, pas besoin d'un .lib, .def ou autre (comme en Visual Basic finalement), le mot cl� external pr�cise le nom de la DLL; si elle est omise c'est qu'on a li� un .OBJ avec la directive {$L fichier.obj}, l� aussi directement dans le source, pas besoin d'ajouter un param�tre de compilation pour pr�ciser qu'on fait r�f�rence � autre chose.

Code delphi :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
{$L moncode.obj}
function test: Integer; external; stdcall;

mais on retombe sur d'�ventuels probl�mes de linker car il n'y a pas de lien explicite entre le .obj li� et la fonction externe

la convention d'appel Pascal (qui utilise des registres) est diff�rente du stdcall, d'o� le mot cl� stdcall en fin de ligne; globalement la logique Pascal est l'inverse du C, le "int ()" retourn� est donn� par ": Integer" en Pascal

si je conserve le mangling C, �a m'oblige � le d�clarer, Delphi ne le fait pas pour moi

Code delphi :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
function test: integer; external 'madll.dll' name '_test@8'; stdcall;

idem pour du C++, c'est juste le nom qui change.

donc je pr�f�re comme l'API Win32 ne pas avoir de mangling, et en grand fan de OpenGL je pr�f�re �viter les overload, m�me si j'ai d�j� vu ce genre de chose sous Delphi :

Code delphi :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
procedure glVertex(x, y, z: Single); external 'opengl32.dll' name 'glVertex3f'; overload;
procedure glVertex(x, y, z: Double); external 'opengl32.dll' name 'glVertex3d'; overload;
procedure glVertex(x, y, z: Integer); external 'opengl32.dll' name 'glVertex3i'; overload;

ce code consiste � r�introduire de l'overload sur glVertex* alors que l'API utilise un suffixe de type.

[bacelar]

J'avais oubli� que Delphi est bas� sur le Pascal.
�a fait plus de 25 ans que j''utilise plus de Pascal, c'�tait m�me pas objet � l'�poque.

Le fait qu'il fasse sp�cifier les conventions d'appel dans le code Delphi indique plut�t que c'est au programmeur de faire attention aux conventions d'appel et que la d�coration C n'est pas utilis� pour inf�rer du code d'interconnexion entre Delphi et la Dll.

la convention d'appel Pascal (qui utilise des registres) est diff�rente du stdcall, d'o� le mot cl� stdcall en fin de ligne; globalement la logique Pascal est l'inverse du C, le "int ()" retourn� est donn� par ": Integer" en Pascal

Heu, c'est pas vraiment �a pour les registres: https://en.wikipedia.org/wiki/X86_calling_conventions
A moins d'une sp�cificit� Delphi ???
J'ai indiqu� le terme "pascal" car cela intervient dans la documentation M$, mais la page Wikip�dia est bien plus pr�cise.
Oui, "stdcall" est diff�rent de la convention Pascal/Delphi, d�sol�.

tout est indiqu� dans le source, pas besoin d'un .lib, .def ou autre (comme en Visual Basic finalement), le mot cl� external pr�cise le nom de la DLL; si elle est omise c'est qu'on a li� un .OBJ avec la directive {$L fichier.obj}, l� aussi directement dans le source, pas besoin d'ajouter un param�tre de compilation pour pr�ciser qu'on fait r�f�rence � autre chose.

Attention, le .def n'est n�cessaire que si l'on n'utilise pas les conventions de nommage de Windows ET qu'on n'utilise pas les extensions des compilateurs pour faire cela.
(Et .def, c'est juste pour la g�n�ration de la dll, pas pour son utilisation)

Comme je pense que les personnes de Google ont d�j� pens�es � cela, je suis � peu pr�s s�r qu'en utilisant les MACRO "FPDF_EXPORT" et "FPDF_CALLCONV" sur votre fonction "test" permettra de vous en servir comme les autres fonctions export�es par la Dll.
Pas la peine de faire de la fonction "test" un cas particulier.
Et on est d'accord que c'est juste pour un test, cette fonction "test", non ?

Le .lib, c'est aussi non obligatoire. C'est juste pour ne pas gal�rer avec les "LoadLibrary/GetProcAdress" et d'utiliser les Dll encore plus facilement qu'en Pascal/Delphi ou en VB6, o� il faut faire toutes les d�clarations � la main, et sans se planter ni dans la signature ni dans les conventions d'appel.

si je conserve le mangling C, �a m'oblige � le d�clarer, Delphi ne le fait pas pour moi

Comme indiqu� avant, on ne devrait pas se focaliser sur la fonction "test" qui ne sert � rien mais sur l'usage des "vraies" fonctions export�es par la Dll (usage de dependency walker pour savoir o� on en est du mangling de ces fonctions).
Il faudrait aussi v�rifier que la valeur de "FPDF_CALLCONV" soit en ad�quation avec ce que vous donnez comme convention dans votre code Delphi.

donc je pr�f�re comme l'API Win32 ne pas avoir de mangling

Heu, non, elle est mangl�e selon les conventions C + extension Windows (pour les conventions d'appel).

et en grand fan de OpenGL

Sauf erreur de ma part, OpenGL utilise une API C avec des conventions d'appel _cdecl, donc elle est aussi mangl�e selon les conventions C + extension Windows (pour les conventions d'appel).

[Paul TOTH]

Heu, non, elle est mangl�e selon les conventions C + extension Windows (pour les conventions d'appel).


Sauf erreur de ma part, OpenGL utilise une API C avec des conventions d'appel _cdecl, donc elle est aussi mangl�e selon les conventions C + extension Windows (pour les conventions d'appel).

pour le coup je suis sur de moi puisque Delphi ne g�re pas le mangling

Pour OpenGL, la seule diff�rence est la convention d'appel stdcall sous Windows et le pr�fixe "_" sous OSX

https://github.com/tothpaul/Delphi-L...ossGL.pas#L389

et pour Win32 on a juste un �ventuel suffixe A ou W pour les fonctions Ansi/Unicode

https://github.com/tothpaul/Delphi/b...nSSPI.pas#L548

[bacelar]

Ok, comme je fais jamais (plus) de "LoadLibrary/GetProcAdress" et que j'utilise toujours les .lib (qui contiennent ces informations), c'est le genre de d�tail qu'on oublie.

Sauf erreur de ma part,

Effectivement des dll Win32 exportent sans suivre les conventions que M$ pr�conisent, car ils fournissent les .lib, et aussi pour "simplifier" le travail des g�n�rateurs de code de glue "langage h�te <-> API C" "basique".

Pour cela, M$ utilise les extensions de MSVC pour piloter le mangling sans avoir recourir au .def.

En utilisant les 2 MACRO, "FPDF_EXPORT" et "FPDF_CALLCONV", je pense que votre fonction "test" suivra les m�mes conventions que le reste des fonctions de la Dll et sera utilisable comme celles-ci sous Delphi.

V�rifiez quand m�me que la convention d'appel attendue par les fonctions de la Dll (via la valeur de "FPDF_CALLCONV") correspond bien � ce que vous sp�cifiez dans Delphi.
Comme les conventions de nommage ne seraient pas respecter (via la valeur de "FPDF_EXPORT"), vous devriez tester via le d�bogueur que les param�tres sont bien compris/transmis.

et pour Win32 on a juste un �ventuel suffixe A ou W pour les fonctions Ansi/Unicode

C'est pas vraiment du mangling, c'est 2 fonctions diff�rentes, pour faire la m�me chose. Maintenant, la version A appel la version W apr�s transformation des chaines de caract�res.

[Paul TOTH]

Bonjour,

je viens de publier le r�sultat des mes premiers travaux sur github
https://github.com/tothpaul/PDFiumReader

la partie C++ est dans
https://github.com/tothpaul/PDFiumRe...ster/libPDFium

je n'ai pas trouv� comment inclure un fichier version.rc dans le projet..enfin si mais j'ai des erreurs de compilation ce qui ne m'avances pas beaucoup.

NB: je ne sais pas comment on g�re les Interfaces en C++, j'ai donc utilis� du code C pour faire tout �a, �a me convient comme �a vu que mon but est d'utiliser la DLL sous Delphi

j'ai test� tout de m�me la compilation en C, avec TCC car c'est le seul compilateur C que j'arrive � faire fonctionner sans probl�me..peut-�tre car il est plus permissif que les autres...

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
#include <windows.h>
#include <stdio.h>
#include "libpdfium.h"
 
int main(void) {
	IPDFium pdf = 0;
	IPDFPage page = 0;
	IPDFText text = 0;
 
	unsigned short buffer[1024];
	int len;
 
	printf("C raw API\n"); 	
	PDF_Create(1, &pdf);
	PDF_LoadFromFile(pdf, "hello.pdf", NULL);
	PDF_GetPage(pdf, 0, &page);
	PDFPage_GetText(page, &text);
	len = PDFText_CharCount(text);
	PDFText_GetText(text, 0, len, buffer);
	printf("%d: %S\n", len, buffer);	
	PDF_FreeHandle(text);
	PDF_FreeHandle(page);	
	PDF_FreeHandle(pdf);	
 
	text = 0;
	page = 0;
	pdf = 0;
 
	printf("COM API\n"); 	
	PDF_Create(1, &pdf);	
	(*pdf)->LoadFromFile(pdf, "hello.pdf", NULL);
	(*pdf)->GetPage(pdf, 0, &page);
	(*page)->GetText(page, &text);
	len = (*text)->CharCount(text);
	(*text)->GetText(text, 0, len, buffer);
	printf("%d: %S\n", len, buffer);
	(*text)->Release(text);
	(*page)->Release(page);
	(*pdf)->Release(pdf);
 
}

[bacelar]

GG

je n'ai pas trouv� comment inclure un fichier version.rc dans le projet..enfin si mais j'ai des erreurs de compilation ce qui ne m'avances pas beaucoup.

Vous pouvez toujours mettre les messages d'erreur dans ce fil de message pour c'est qui connaissent la toolchaine Clang, mais bon, c'est loin d'�tre la seule Dll sans num�ro de version.

NB: je ne sais pas comment on g�re les Interfaces en C++, j'ai donc utilis� du code C pour faire tout �a, �a me convient comme �a vu que mon but est d'utiliser la DLL sous Delphi

Il n'y a pas encore de standard au niveau du C++.
Faire une API C++ obligerait l'utilisateur de votre Dll � utiliser le m�me compilateur, voire la m�me version de ce compilateur, et les m�mes options de compilation, une �norme gal�re pour pas grand-chose.

Un programmeur C++ � l'habitude de faire sont wrapping C++ autour de l'API C.
En plus votre API est con�ue avec les paradigmes COM, donc pas de probl�me de conception objet.
De simples CComPtr<IPDFium>, CComPtr<IPDFPage>, etc devrait m�me suffire pour un usage simple en C++.

Encore Merci.