On 15 April 2015 at 15:17, David Macek <[email protected]> wrote: > On 15. 4. 2015 15:16, Paul Moore wrote: >> I'm having a problem building gawk for mingw64. I'm not using >> configure, as that assumes a POSIX-like environment such as msys or >> cygwin). Rather, gawk has a customised build process for PC/mingw. You >> copy some customised files from the pc subdirectory, including a >> makefile and a config.h, and then run make. > > Why not use configure? makepkg-mingw depends on the POSIX part of MSYS2 > anyway. There are no expectations that mingw packages can be built just using > mingw tools and the specialized makefiles are often problematic as they're > inflexible and sometimes even call Windows shell commands, which is > undesirable in MSYS2.
It's possible that I could make that work. But when I tried, I got a lot of build errors, as far as I can see caused by an assumption in the source that if you're building with configure, you'll be running the built executable on a POSIX-based system (which isn't true when building mingw executables with msys). Also, there was a PC-based build process provided, so it seemed reasonable to use it (it *is* much simpler to do that if you just manually edit stuff to match your preferred install location, etc - it's only when you try to make the build configurable that it becomes messy :-() I may have another go at getting configure to work. Given how messy the custom PC build is becoming, it may be less work in the long run. >> What I'm trying to do is to modify this build process to allow it to >> be packaged. So I've made the code get its paths relative to the exe >> (using the msys2 pathtools library), and modified how the default path >> is set. I'm setting a prefix=/mingw64 argument to make, which I'm then >> using to set defines -DBINDIR="\"$(prefix)/bin\"" and a default path, >> in the CFLAGS. Then I make the default path relative (using BINDIR as >> the root). It's not the most straightforward process, but it's >> relatively clean. >> >> The problem is that it appears that by the time the BINDIR and DEFPATH >> macros are seen in the source code, their values are Windows-style >> paths (C:\Work\Scratch\msys2\...), which completely breaks the path >> correction code which expects Unix-style paths. > > Only problem I see are the slashes (`get_executable_path` returns Windows > paths with forward slashes). If you're able to tweak the build process in the > right place, you can use `cygpath -m` to convert the path. If not, use > `sanitise_path` at runtime. I'm just not sure what changed the paths on me. If I do CFLAGS="-DBINDIR="\"/mingw64/bin\"" (plus other stuff) in the makefile, I find that in my C code, "char *path = BINDIR" results in path having a value of "C:\Work\Scratch\msys2\mingw64\bin". The C preprocessor should simply do text substitution - so *something* changed the arguments supplied to cpp, or to gcc, or something, to change that value. I'm unsure what that was, or why it did that. And more importantly I don't know how to tell it *not* to do that. The big problem is that because I'm confused about what value ends up in my variable, I don't know how to write the code to process it... >> I'm guessing that this is caused by some part of the msys >> infrastructure "helpfully" converting paths. But I've no idea where, >> nor how to stop it doing so. Can anyone help? >> >> I could hard-code the values in the source, but if I do that, I can't >> make a viable PKGBUILD spec, as that requires the ability to specify >> the install directory at build time. (Hmm, actually I could - the >> relocation code doesn't care if the arguments to >> get_relocated_path_list are *accurate*, just that they are consistent. >> But it's horribly ugly, and I'd still like to know what's going on >> with the path translation code anyway). > > I'm not sure I understand what you mean, but I'd say that baking in paths > like "C:\msys64\mingw64\share\gawk" and "C:\msys64\mingw64\bin" is okay, as > long as they're never actually accessed and the runtime-computed path is > correct. I'd actually be baking in Unix-format paths rather than Windows-format ones as you show, but yes the runtime-computed path is correct, so I guess it doesn't matter in practice. It does leave me with a sour taste, though... (The fact that the hard coded default library could be "/this/is/a/broken/default/share/awk" as long as I supply a bindir of "/this/is/a/broken/default/bin" just feels meh). Paul ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
