Hello, >> Building binaries for Windows - Part III: >> ========================================== >> The winbuild.ps1 script is able to create a zip file (binaries + VHDL >> packages) for the delivery. >> .\winbuild.ps1 -CreatePackage -Zip >> >> Shall I create an install script, which is embedded into the zip file? >> >> Possible tasks for such a script: >> - Install (copy into a destination folder; register in PATH) >> - Uninstall (delete folder) >> - Update (remove old files, copy new files) >> >> I think NSIS support is not needed any more. I also looked into WIX (Windows >> Installer XML), >> it's nice but a bit too complex for just doing xcopy deployment. > > Isn't an installer the common usage on Windows ? >
YES, an installer is a common usage like packages are for Linux systems. BUT, installers are made for complex installation routines like: - accept an EULA - choose a language, add-ons - install dependencies or hot-fixes like VC++ redistributable, DirectX or .NET library - add shortcuts - register all DLLs in the registry or GAC - register file extensions, add explorer sub-menus All this does not apply to GHDL. We just need to copy all files into a directory and register the installation path in $env:Path, if it's wanted by the user. There is also this new trend for package managers on Windows. I think the first one was NuGet. It's a PowerShell addon for the VisualStudio PowerShell console, to install and update .NET libraries and VisualStudio Addons in an 'apt-get' style. On top of the NuGet format and infrastructure, several other solutions were developed. One is known as Chocolatey and the newest 'OneGet' is integrated in Windows 10. https://chocolatey.org/ For example the well-known Notepad++ can be installed with this command line: PS> choco install notepadplusplus.install In these days, chocolatey hosts circa 2900 packages. If this distribution way is wanted by the GHDL community, it should be possible to distribute GHDL via the chocolatey infrastructure like it's done via Debian repositories. It's also possible to use MyGet, a free NuGet package hoster. Packages up to 100 MB are hosted free. If there are interested parties, I could look into the .nuspec format. Regards Patrick ----------------------------------- Wissenschaftliche Hilfskraft Technische Universität Dresden Fakultät Informatik Institut für Technische Informatik Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur 01062 Dresden Tel.: +49 351 463-38451 Fax: +49 351 463-38324 Raum: APB-1020 E-Mail: patrick.lehm...@tu-dresden.de WWW: http://vlsi-eda.inf.tu-dresden.de -----Original Message----- From: Ghdl-discuss [mailto:ghdl-discuss-boun...@gna.org] On Behalf Of Tristan Gingold Sent: Friday, September 11, 2015 9:25 PM To: ghdl-discuss@gna.org Subject: Re: [Ghdl-discuss] Next release ? On 11/09/15 11:12, Lehmann, Patrick wrote: > Hello, > > is 0.32 the correct number? The current development version is 0.33; or do > you use some kind of backport strategy? > > Building binaries for Windows - Part I: > ========================================== > If have tested the current development version (rev. 866) with the newest > GNAT for Windows (20150428-49). > > There is a linker error: > ------------------------------------------------- > gnatlink ghdl_jit.ali -O -g -o ghdl.exe grt-cbinding.o clock.o > grt-cvpi.o memsegs_c.o win32.o -Wl,--stack,8404992 > win32.o: In function `grt_stack_init': > D:/hg/ghdl/src/grt/config/win32.c:65: undefined reference to > `grt_set_main_stack' > win32.o: In function `ghdl_SEH_handler': > D:/hg/ghdl/src/grt/config/win32.c:170: undefined reference to > `grt_stack_error_null_access' > D:/hg/ghdl/src/grt/config/win32.c:172: undefined reference to > `grt_stack_error_memory_access' > collect2.exe: error: ld returned 1 exit status > gnatlink: error when calling C:\Tools\GNAT\2015\bin\gcc.exe > gnatmake: *** link failed. Oops, I have to update win32.c > My last (successful) compile test with GNAT 2015 and GHDL was rev. 856. > > > Building binaries for Windows - Part II: > ========================================== > The docs say it's only possible to compile GHDL for Windows with mcode > backend. Recently I found LLVM for Windows. Is it compatible and now possible > to build it for LLVM backend, too? It is possible to build with llvm or gcc backend (ie there is no fundamental blocking reason) but this is much harder. As I am not a Windows specialist, I have never tried. > Building binaries for Windows - Part III: > ========================================== > The winbuild.ps1 script is able to create a zip file (binaries + VHDL > packages) for the delivery. > .\winbuild.ps1 -CreatePackage -Zip > > Shall I create an install script, which is embedded into the zip file? > > Possible tasks for such a script: > - Install (copy into a destination folder; register in PATH) > - Uninstall (delete folder) > - Update (remove old files, copy new files) > > I think NSIS support is not needed any more. I also looked into WIX (Windows > Installer XML), > it's nice but a bit too complex for just doing xcopy deployment. Isn't an installer the common usage on Windows ? Tristan. _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
