GhostScript 9.04 Win32 bouwen

Ik wil GhostScript 9.04 voor Win32 bouwen en ik heb de documentatie gelezen om dit te doen, met details over het maken van je eigen makefile-project.

Ik was gewoon nieuwsgierig naar het "ghostscript.vcproj" dat ik in de map op het hoogste niveau vind. Als ik dit naar VS2010 converteer, lijkt het erop dat ik er een goede build van krijg.

Is er een reden om dit "ghostscript.vcproj" niet te gebruiken? De opdrachtregel van de build lijkt wat extra spullen te bevatten dan wat in de documentatie wordt beschreven, dus ik was bang dat het een soort gespecialiseerde build zou maken. Zie hieronder

"nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO= && nmake -f psi\msvc32.mak DEVSTUDIO= bsc"

Bedankt!

1

2 antwoord

Je kunt de meegeleverde oplossingen gebruiken, ze zijn in orde en wat we gebruiken. Als je liever nmake en de makefiles gebruikt, dan is dat ook goed, de oplossingen gebruiken eenvoudigweg de makefiles, dus het is hetzelfde, in sommige opzichten handiger als je Visual Studio gebruikt.

De 'extra dingen' zijn daar om de bron van de visuele studio te ondersteunen, in principe om de ervaring te verbeteren bij het gebruik van Visual Studio, het is niet essentieel.

Ik zal het updaten van de documentatie in make.htm bekijken.

2
toegevoegd
Heel erg bedankt, dat wilde ik weten!
toegevoegd de auteur Steve, de bron

Sorry dat ik een heel oud onderwerp tegen het lijf zou lopen, maar als ik probeer GhostScript v.9.14.1 te compileren met Visual Studio 2015, krijg ik de volgende fouten:

Error U1034 syntax error : separator missing lib.mak (line 51)

Error MSB3073 The command "nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO= debug && nmake -f psi\msvc32.mak DEVSTUDIO= debugbsc" exited with code 2.   ghostscript C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets

Hier is de code op regel 51 in lib.mak :

GLLCMS2CC=$(CC_SHARED) $(GCFLAGS) $(I_)$(GLI_) $(II)$(LCMS2SRCDIR)$(D)include$(_I) $(GLF_)

Is er een manier om dit te verhelpen?

Dank je.

PS: Is dit DLL-bestand gebouwd in dit project? Kunnen we het DLL-bestand zelf bouwen?

1
toegevoegd
Helaas gooit zelfs de opdrachtregel nmake dezelfde U1034-syntaxisfout. Ik zal v9.2x proberen. Elke manier om oudere versies van VS te krijgen, misschien? Van wat ik heb gelezen, kan het een make/nmake incompatibiliteit zijn. Ik start simpelweg het .VCPROJ-bestand in de uitgepakte map en VS2015 heeft een eenrichtingsupgrade; enige ding is deze nmake-fout.
toegevoegd de auteur iSofia, de bron
Nogmaals bedankt, KenS. Temidden van een hele reeks waarschuwingen, compileerde het en de DLL werkt. Zeer gewaardeerd. De reden dat ik de oudere versies probeerde, is omdat ze onder de vrijere open-sourcelicentie zaten en ik geloof dat de latere versies onder striktere distributieregels vallen. Ik wil de DLL graag verspreiden met mijn closed-source commerciële applicaties.
toegevoegd de auteur iSofia, de bron
Je hebt gelijk; Ik heb een beetje gelezen en de distributie met closed-source is in strijd met de GPL-licentievoorwaarden. Ik ben een keukentafelontwikkelaar en de inkomsten zijn klein, dus elk soort licentiekosten zou niet erg betaalbaar zijn. Aangezien ik mijn software niet daadwerkelijk via een willekeurig massamedium "distribueer", maar fysiek in de lokalen van de klant installeer, denk ik dat ze een kopie voor eigen gebruik kunnen downloaden. Zou eenvoudigweg interfacing met een geïnstalleerd exemplaar als een overtreding worden beschouwd, denkt u?
toegevoegd de auteur iSofia, de bron
Je hebt gelijk; veel grijze gebieden. Een vriend stelde voor om alleen de module open te sourcen waarvoor GhostScript nodig is, die PostScript-bestanden converteert naar PDF's. De hoofdtoepassing kan dan eigendom blijven, aangezien het consumeren van de gegenereerde PDF-bestanden geen inbreuk maakt op de voorwaarden van de licentie. Ik denk dat dat een goede afweging is.
toegevoegd de auteur iSofia, de bron
Update: Schreef naar Artifex en zij bevestigden dat een dergelijke distributieconfiguratie wettelijk aanvaardbaar was. Zolang elke zelfstandige module die GhostScript-functionaliteit gebruikte, werd gedistribueerd onder de AGPL-licentie (open-source on demand), kon GhostScript (volledig, gedeeltelijk, aangepast) zonder probleem worden gedistribueerd.
toegevoegd de auteur iSofia, de bron
Nou, het moet werken, echter, 9.14 is best oud, de huidige code is 9.20 en 9.21 zal in een paar weken worden vrijgegeven. Ik heb momenteel geen VS 2015 geïnstalleerd, ik gebruik momenteel Team editie 2008. Hebt u al de bron van derden daar? Waaronder de LCMS2-directory? Je zou kunnen proberen om nmake rechtstreeks op psi/msvc32.mak te gebruiken en te zien wat er gebeurt
toegevoegd de auteur KenS, de bron
Nou, ik heb de VS2015 Community Edition in het verleden gebruikt om GS te bouwen (na het upgraden van het projectbestand) en het werkte goed ..... Ik zal kijken of iemand een exemplaar heeft geïnstalleerd en het kan proberen.
toegevoegd de auteur KenS, de bron
Als je nagaat wat U1034 betekent, ziet het eruit als een bug in nmake, het klagen dat er geen ':' is tussen doel en afhankelijkheden, maar dit is geen doelregel, het is een opdracht
toegevoegd de auteur KenS, de bron
Volgens een van mijn collega's importeert en bouwt de huidige versie van Ghostscript zonder problemen op VS 2015. We zijn echter niet in een positie om tijd te besteden aan het testen van een obselete-versie. De dingen zijn veranderd sinds 9.14 en er waren enkele problemen (met betrekking tot VS 2015) die na die release werden verholpen. Dus als je een upgrade uitvoert, zou het goed moeten zijn.
toegevoegd de auteur KenS, de bron
Ik geloof niet dat er enig verschil is tussen GPL v2 en AGPL v3 (de AFPL-licentie was een long tijd geleden) met betrekking tot de distributie van de DLL. Ik ben er ook redelijk zeker van dat 9.14 werd gedistribueerd onder dezelfde AGPL v3-licentie (in feite lijkt de verandering rond 9.07 te zijn geweest). Als je het DLL-bestand met een closed-source applicatie verspreidt, ben je (geloof ik) op heel dun ijs aan het schaatsen, ik ben geen advocaat, maar als je Ghostscript in een commerciële toepassing gaat gebruiken, moet je zoek zeker naar een commerciële licentie naar mijn mening.
toegevoegd de auteur KenS, de bron
Ik ben bang dat dat het punt is waar ik zou moeten buigen. Ik geloof (maar als u zich zorgen maakt, moet u deskundig advies inwinnen) dat de hoofdtaak van de (A) GPL is dat gebruikers in staat moeten zijn om de open-sourcecomponent te vervangen door een nieuwere (of mogelijk andere) ) versie. Het lijkt mij dat, vanuit juridisch oogpunt, het eenvoudigweg gebruiken van een geïnstalleerde versie compatibel is, omdat je gewoon een andere versie kunt installeren. Een aantal organisaties (sommige verrassend groot) gebruiken deze techniek om te voorkomen dat ze moeten betalen voor de software die ze gebruiken.
toegevoegd de auteur KenS, de bron