[Geany-devel] Remove MSYS dependency of Geany on Win~1
nick.treleaven at xxxxx
Wed Jul 4 11:59:11 UTC 2012
On 28/06/2012 18:55, Dimitar Zhekov wrote:
> On Thu, 28 Jun 2012 14:41:25 +0100
> Nick Treleaven<nick.treleaven at btinternet.com> wrote:
>> Yes, using a target for plugins only would be OK.
> What if we put the an install: target in plugins/makefile.win32? That
> works, needs no DIRSEP, and is very similar to the *nix installation.
> To avoid 'C:/Program Files/Geany already exists' on the first install,
> we will have to use mkdir -p, but that's the default behaviour of the
> cmd/tcc mkdir anyway. Attached, and the patch is git-ified this time.
Well that removes DIRSEP, but adds MKDIR_P and adds defines to the
BTW if you think plugins$(DIRSEP)*.dll looks ugly, we can use:
This is what I intend to do.
> BTW (not included in the .diff):
> 'CP = copy' in doc/Makefile.win32 should be 'copy /Y'.
OK, I'll fix it.
> 'MAKE =' seems unneeded, any GNU make defines is automatically.
I already made that change last week.
>> But I'm thinking of adding a MSYS variable now to make it easier:
>> -include localwin32.mk
>> ifdef MSYS
>> CP = cp
>> CP_R = cp -r
>> RM = rm
>> DIRSEP = /
> I thought of providing a sample localwin32.msys with the standard MSYS
Then the user would have to keep merging it with their local one if we
> In all cases, -include localwin32.mk should be the last,
> to allow overriding.
>> And then perhaps use $(MAKE) CP="$(CP)" RM="$(RM)" to pass these
>> variables to the sub-makefiles so they don't need to have copies of the
>> ifdef. They only need CP and RM.
> Then all clean: targets will fail when run from a subdirectory (and the
> above install: when run from plugins/). So 'make all' in src/ will work,
> but not 'make clean'. Hmmm...
Yes, I realized after sending the email.
That means I will need to use 'ifdef MSYS' in any sub-makefiles that
need it. This is the cleanest way to provide MSYS support. The user can
even type MSYS=1 on the command-line quite easily.
>>>> Also, I think you /can/ join command lines with a trailing backslash
>>>> (but your patch change is still better to have STLIBS anyway):
>>> It failed on my mingw32-make, I wound't have bothered if it worked.
>> It seemed to work for me, and the manual seems to say that GNU make
>> interprets the trailing backslash, it doesn't pass it to the shell.
>> I have GNU Make 3.82. YMMV.
> (GNU)mingw32-make-3.82-5. Obviously treats \ different, since it's not
> an escape in C:\foo\bar. Anyway, STLIBS is a safe bet.
Did you read the link? I'm talking about a backslash as the last
character on the line.
More information about the Devel