changelog of trunk including comments / devtalk

reyalp

14080

Re: changelog of trunk including comments / devtalk

« Reply #260 on: 14 / November / 2015, 21:05:36 »

Advertisements

In trunk r4288, I
* defined PLATFORMOSVER for the few dryos cams that didn't already have it defined
* adjusted makefile_cam.inc to error if it isn't defined for a dryos cam
* made it not defined for vxworks (instead of being 0)
* passed it in makefile_cam.inc cflags as -DCAM_DRYOS_REL=n, for dryos cams only.

Note this doesn't include the dryos version (2.3) or patch level (eg 54+p3). We can deal with those later if they ever become significant. I called the define "rel" rather than version for this reason.

I didn't verify every single existing makefile.inc definition was correct, but the vast majority seem to match their stubs_entry.S

The immediate motivation is to be able to set dryos version specific defaults for the filename/path limits, but I think it will allow us to simplify some other things later too.

I would like to replace the CAM_DRYOS_2_3_Rx defines, but that is probably a 1.5 project (IIRC some platforms define those differently than the actual version)

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: changelog of trunk including comments / devtalk

« Reply #261 on: 06 / December / 2015, 06:12:29 »

Back to Cygwin

Quote from: reyalp on 26 / September / 2015, 15:26:33

Quote from: srsa_4c on 21 / September / 2015, 14:51:38
Little problem is that recent Cygwin no longer includes stricmp in strings.h, so the sigfinder source needs a trivial fix (and the makefiles don't recognize Cygwin either, so that also needed a fix).
I have no objection to adding cygwin fixes if they don't break anything else. I wouldn't want cygwin to be required.

My question is: is there a supported host compiler on Windows that doesn't support strcasecmp()? The sigfinders' source uses stricmp() on a Windows host and - as mentioned above - Cygwin doesn't provide an alias for it in string.h.
Once that is sorted, the only other change required to support Cygwin is this:

Code: [Select]

Index: makefile_env.inc
===================================================================
--- makefile_env.inc	(revision 4307)
+++ makefile_env.inc	(working copy)
@@ -7,6 +7,7 @@
 
 ifndef OSTYPE
   HOSTPLATFORM:=$(patsubst MINGW%,MINGW,$(shell uname -s))
+  ISCYGWIN:=$(patsubst CYGWIN%,CYGWIN,$(shell uname -s))
   ifeq ($(HOSTPLATFORM),MINGW)
     OSTYPE = Windows
     EXE = .exe
@@ -31,11 +32,21 @@
         SORT = sort
         ESED = sed -E
       else
-        OSTYPE = Other
-        EXE =
-        SH =
-        DEVNULL = /dev/null
-        SORT = sort
+        ifeq ($(ISCYGWIN),CYGWIN)
+          OSTYPE = Windows
+          EXE = .exe
+          SH = sh
+          DEVNULL = NUL
+          OLDSEPARATOR = \\\\
+          NEWSEPARATOR = /
+          SORT := $(dir $(shell which uniq.exe | sed 's_$(OLDSEPARATOR)_$(NEWSEPARATOR)_g'))/sort.exe
+        else
+          OSTYPE = Other
+          EXE =
+          SH =
+          DEVNULL = /dev/null
+          SORT = sort
+        endif
       endif
     endif
   endif

Logged

reyalp

14080

Re: changelog of trunk including comments / devtalk

« Reply #262 on: 06 / December / 2015, 14:41:28 »

Quote from: srsa_4c on 06 / December / 2015, 06:12:29

My question is: is there a supported host compiler on Windows that doesn't support strcasecmp()? The sigfinders' source uses stricmp() on a Windows host and - as mentioned above - Cygwin doesn't provide an alias for it in string.h.

Both MinGW gcc (4.8.1 from http://www.mingw.org/wiki/MSYS) and the gcc provided with chdkshell (an older mingw compiler, IIRC) seem to do fine with strcasecmp. So it seems like it should be OK.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: changelog of trunk including comments / devtalk

« Reply #263 on: 06 / December / 2015, 16:54:48 »

Quote from: reyalp on 06 / December / 2015, 14:41:28

Quote from: srsa_4c on 06 / December / 2015, 06:12:29
My question is: is there a supported host compiler on Windows that doesn't support strcasecmp()? The sigfinders' source uses stricmp() on a Windows host and - as mentioned above - Cygwin doesn't provide an alias for it in string.h.
Both MinGW gcc (4.8.1 from http://www.mingw.org/wiki/MSYS) and the gcc provided with chdkshell (an older mingw compiler, IIRC) seem to do fine with strcasecmp. So it seems like it should be OK.

Thanks, I'll check this in later then. My aim is to provide alternatives to the CHDK-Shell workflow.

edit:
Committed. Turned out Cygwin uses /dev/null as the null device.

« Last Edit: 08 / December / 2015, 18:55:11 by srsa_4c »

Logged

rudi

129
A590IS_101B, SX260HS_100B

Re: changelog of trunk including comments / devtalk

« Reply #264 on: 04 / January / 2016, 14:57:08 »

msl reported a broken build process for sx280 since trunk rev. 4320 and no OPT_GEN_STUBS. I confirm this with chdk-shell and raw trunk 4327. patch attached.

rudi

makefile_sub.inc.patch (0.48 kB - downloaded 36 times.)

Logged

reyalp

14080

Re: changelog of trunk including comments / devtalk

« Reply #265 on: 04 / January / 2016, 17:28:34 »

Quote from: rudi on 04 / January / 2016, 14:57:08

msl reported a broken build process for sx280 since trunk rev. 4320 and no OPT_GEN_STUBS. I confirm this with chdk-shell and raw trunk 4327. patch attached.

Thanks, added in trunk 4328

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: changelog of trunk including comments / devtalk

« Reply #266 on: 03 / March / 2016, 18:52:05 »

My latest finsig related commit affects the ixus160 port - I have removed a stub ('time') that was used there by mistake. (The problem may not be very serious as the wrong function expects the same kind of argument and returns its value the same way - I don't know what it actually returns though.)
I'm not sure what would be the appropriate way to make this change in the 1.4 branch - some finsig related commits (r4497) in trunk are intermixed with the thumb2 sigfinder stuff.

Logged

reyalp

14080

Re: changelog of trunk including comments / devtalk

« Reply #267 on: 03 / March / 2016, 21:19:57 »

Quote from: srsa_4c on 03 / March / 2016, 18:52:05

I'm not sure what would be the appropriate way to make this change in the 1.4 branch - some finsig related commits (r4497) in trunk are intermixed with the thumb2 sigfinder stuff.

I think you can just merge it. I tried merging 4505 to 1.4 and the only conflict I got was on a stubs_entry.S. That you can resolve in a simple way (accept the new file completely or keep local) and then re-generate before you check in.

I do try to keep do the generated file updates as a separate commit to make it more convenient to merge, since they should always be re-generated rather than merged.

edit:
Above was assuming you don't plan to merge the e32 stuff from 4497. If you do, you'll have tree conflicts, but they should be easy enough to resolve since you don't need the affected files. I don't currently plan to backport finsig_thumb2 to 1.4

« Last Edit: 03 / March / 2016, 21:24:10 by reyalp »

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: changelog of trunk including comments / devtalk

« Reply #268 on: 04 / March / 2016, 13:15:09 »

Quote from: reyalp on 03 / March / 2016, 21:19:57

I think you can just merge it. I tried merging 4505 to 1.4 and the only conflict I got was on a stubs_entry.S. That you can resolve in a simple way (accept the new file completely or keep local) and then re-generate before you check in.

I'll probably do this. I was considering making the 1.4 sigfinder up-to-date, but that won't work - I don't currently want to "backport" the e32 stuff...
Things may start to get uglier in future since I'm planning to add more stuff to finsig.

Quote

I do try to keep do the generated file updates as a separate commit to make it more convenient to merge

Me too, but sometimes I make exceptions when I really should not...

Logged

srsa_4c

4451

Re: changelog of trunk including comments / devtalk

« Reply #269 on: 16 / May / 2016, 16:18:19 »

There's something I'd like to note (here's probably more appropriate than in the bugreport thread).

In trunk r4623..4626, the sx530 (and also sx520) port gets the default, 'weak' version (from platform/generic/wrappers.c) of the vid_get_bitmap_active_palette() function in the final main.bin file. I have not found an explanation for this. There are other ports where this particular function is located in the port's 'lower' lib.c file, but the two I tried (s80, a590) build correctly.
The biggest noticeable difference is probably the content of platform/sx530hs/sub/100c/lib.c, which was only the above mentioned function. But I don't see how that should matter.

Logged