new branch - CHDK : Elf Edition - Developers wanted - page 8 - General Discussion and Assistance - CHDK Forum

new branch - CHDK : Elf Edition - Developers wanted

  • 316 Replies
  • 134198 Views
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #70 on: 18 / December / 2011, 02:57:32 »
Advertisements
BUILD_NUM should be revision. I implement best way to make it which I found. Maybe another way exists.

Reason for this variable - CHDK core should know what revision it is. If I make some changes required to new module or add new export symbol, then I should have the way to determine that this revision is minimal requirement. New export symbol requirement will be catched by module system (althrough it can't say what revision required), but changing of core algoritm/sizes is not detectable at all.

And developer should not care about change manualy in CHDK core what its current revision is.
« Last Edit: 18 / December / 2011, 03:11:50 by tsvstar »

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #71 on: 18 / December / 2011, 08:54:19 »
I changed the lines in reyalp-flt ( r1491) as shown :

Code: [Select]
    // Separate CHDK build num
    char* build = BUILD_NUMBER;
    int build_num=0;
    for ( ; *build; build++) {
        if (isdigit(*build))
        {
            build_num = build_num * 10 + strtol(build, NULL, 0/*autodetect base oct-dec-hex*/);   
        }
    }
    fprintf(out_h,"#define CHDK_BUILD_NUM %d\n",build_num);

Now it dies a little farther along with :

gui.c -> gui.o
gui.c:1210:6: error: #error camera alt-buttons not defined
gui.c: In function 'gui_alt_mode_button_enum':
gui.c:1214: error: 'names' undeclared (first use in this function)
gui.c:1214: error: (Each undeclared identifier is reported only once
gui.c:1214: error: for each function it appears in.)
gui.c:1215: error: 'keys' undeclared (first use in this function)
C:\Users\a\Desktop\CHDK\gcc4\bin\gmake.exe[1]: *** [gui.o] Error 1
gmake: *** [all-recursive] Error 1
Ported :   A1200    SD940   G10    Powershot N    G16

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #72 on: 18 / December / 2011, 11:44:39 »
waterwingz,

Strange, I change nothing related to this part. I succesfully compile for G10 102a from newly downloaded branch (I only add revision into version.inc)
Source code say that reason of error is that CAM_ADJUSTABLE_ALT_BUTTON is defined (probable at platform_camera.h for selected platform) but this is different camera then listed in this function.

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #73 on: 18 / December / 2011, 12:25:00 »
@tsvstar : I can compile the reyalp-flt branch successfully for my ixus120_sd940 but the g10 (or G10) throws the error I listed above.   The g10 compiles correctly in the main trunk.

Did you compile successfully in the reyalp-flt branch or the main trunk ?  According to svn I have the current version (other than the change in the  tools/makeexport.c).

Update :  now its working in the reyalp-flt branch  with PLATFORM=g10.   Very strange !
« Last Edit: 18 / December / 2011, 12:31:35 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14128
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #74 on: 18 / December / 2011, 18:40:44 »
BUILD_NUM should be revision. I implement best way to make it which I found. Maybe another way exists.
It needs to compile out of the box from SVN, which the current code does not. It may work in chdkshell, which IIRC automatically does something with version.inc.

I would like to get the autobuilds at least using the svn rev for build number. - edit: actually, it already does.

 For end users builds, we can't assume this information is available to the build process.
Quote
Reason for this variable - CHDK core should know what revision it is. If I make some changes required to new module or add new export symbol, then I should have the way to determine that this revision is minimal requirement. New export symbol requirement will be catched by module system (althrough it can't say what revision required), but changing of core algoritm/sizes is not detectable at all.
This is an interesting question. Having some kind of API versioning like PTP might be a better approach. So both module and core have version X.Y defines. Minor version are backwards compatible (e.g. add new functionality but don't affect existing), major versions are incompatible. OTOH, doing this globally means that modules which aren't really affected would need to be updated when some other part of the API changes.
« Last Edit: 18 / December / 2011, 21:17:08 by reyalp »
Don't forget what the H stands for.

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #75 on: 19 / December / 2011, 02:07:25 »
This is an interesting question. Having some kind of API versioning like PTP might be a better approach. So both module and core have version X.Y defines. Minor version are backwards compatible (e.g. add new functionality but don't affect existing), major versions are incompatible. OTOH, doing this globally means that modules which aren't really affected would need to be updated when some other part of the API changes.

I do agree that possible current mechanizm could be improved.

Why I use revision:
- It require no additional work from developer to change core version (and so decrease chance to forget something)
- It make more userfriendly message. If revision is below than expected, module system say what revision you need. In case of API version system is end-user know what API it is in exact revision?
It have cons: - Changes of functionality should be limited manually.

It slightly duplicate other automatic checks. But it purpose is beeing just simple user-friendly check.
BTW: Is it possible to get SVN revision of current source code?

How limits are working now:
- Check FLAT version.
- Check requirement for branch. (main,DE, SDM,...). If fail say "Require different branch"
- Check is revision >= than required to module. If fail say "Require XXX revision"
- Check is platformid is equal to required. If fail say "Require platformYYY"
- If one of imported by module symbol out of range - then it require upper revision but don't know which one. Say "Require different revision".
- If module_load callback in core or in module return "fail", then also say that "CHDK mismatch". This is the way to make any comparision and check that we need.

What limitiation of common major-minor system I see: we have a lot different part of core. If we change the way in which works one of them and because this change major version, then other modules will be rejected also althrough they work ok
« Last Edit: 19 / December / 2011, 02:10:30 by tsvstar »

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #76 on: 19 / December / 2011, 03:21:15 »
This is an interesting question. Having some kind of API versioning like PTP might be a better approach. So both module and core have version X.Y defines. Minor version are backwards compatible (e.g. add new functionality but don't affect existing), major versions are incompatible. OTOH, doing this globally means that modules which aren't really affected would need to be updated when some other part of the API changes.

I do agree that possible current mechanizm could be improved.

Why I use revision:
- It require no additional work from developer to change core version (and so decrease chance to forget something)
- It make more userfriendly message. If revision is below than expected, module system say what revision you need. In case of API version system is end-user know what API it is in exact revision?
It have cons: - Changes of functionality should be limited manually.

It slightly duplicate other automatic checks. But it purpose is beeing just simple user-friendly check.
BTW: Is it possible to get SVN revision of current source code?

How limits are working now:
- Check FLAT version.
- Check requirement for branch. (main,DE, SDM,...). If fail say "Require different branch"
- Check is revision >= than required to module. If fail say "Require XXX revision"
- Check is platformid is equal to required. If fail say "Require platformYYY"
- If one of imported by module symbol out of range - then it require upper revision but don't know which one. Say "Require different revision".
- If module_load callback in core or in module return "fail", then also say that "CHDK mismatch". This is the way to make any comparision and check that we need.

What limitiation of common major-minor system I see: we have a lot different part of core. If we change the way in which works one of them and because this change major version, then other modules will be rejected also althrough they work ok

By 'revision', do you mean the SVN changeset number?
This is added to BUILD_NUMBER in version.inc by CHDK-Shell when it downloads the trunk .zip file - it is not included in either CHDK or CHDK-DE by default.

You can get the current SVN number using svnversion; but it is not specific to the trunk/branch you are in - it is global to the whole repository.

Even if you could get the SVN revision it's not a good number to use.
Consider what happens when the current gets converted to the 'stable' release branch and the trunk becomes version 2.x.
You might set the minimum revision for modules to be 1500 (as an example because that's the first changeset in 2.x); but someone adds a bug fix to the 'stable' branch and now that's changeset 1501. You're module revision check will now accept the 'stable' branch as valid even though it shouldn't.

I suggest either using the CHDK version.inc BUILD_NUMBER, or adding a module system specific version number.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #77 on: 19 / December / 2011, 03:35:35 »
Even if you could get the SVN revision it's not a good number to use.
Consider what happens when the current gets converted to the 'stable' release branch and the trunk becomes version 2.x.
You might set the minimum revision for modules to be 1500 (as an example because that's the first changeset in 2.x); but someone adds a bug fix to the 'stable' branch and now that's changeset 1501. You're module revision check will now accept the 'stable' branch as valid even though it shouldn't.
This could be resolved by "branch" check.

Quote
I suggest either using the CHDK version.inc BUILD_NUMBER, or adding a module system specific version number.
Sure. No problem to make two component build_number (version+revision). Or even just version. Second variant is more simple, still userfriendly, but require to change version.inc manualy.

Quote
You can get the current SVN number using svnversion; but it is not specific to the trunk/branch you are in - it is global to the whole repository.
I see. Is it specific to workspace or just "last revision of main repository"?

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #78 on: 19 / December / 2011, 04:51:11 »
This is added to BUILD_NUMBER in version.inc by CHDK-Shell when it downloads the trunk .zip file - it is not included in either CHDK or CHDK-DE by default.

You can get the current SVN number using svnversion; but it is not specific to the trunk/branch you are in - it is global to the whole repository.

CHDK-DE includes a query of svnversion, changeset 585 + changeset 587.

But there are some difficulties. The compiler produces a warning, because svnversion.exe is an obsolete version. You can overwrite  the svnversion.exe in GCC with the version from slik SVN (needs also all DLLs). This works with a working copy of Tortoise, but don't with the normal source code (without subversion controle).

msl
CHDK-DE:  CHDK-DE links

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #79 on: 19 / December / 2011, 04:55:55 »
Even if you could get the SVN revision it's not a good number to use.
Consider what happens when the current gets converted to the 'stable' release branch and the trunk becomes version 2.x.
You might set the minimum revision for modules to be 1500 (as an example because that's the first changeset in 2.x); but someone adds a bug fix to the 'stable' branch and now that's changeset 1501. You're module revision check will now accept the 'stable' branch as valid even though it shouldn't.
This could be resolved by "branch" check.

What do you mean by 'branch check'?
I can understand the need to check if something is specific to CHDK / CHDK-DE / SDM; but within CHDK why would you want to check the branch? Wouldn't this make it difficult for someone to create a test branch for experimentation? Looking at the module_load.c code I don't see how you would cater for multiple 'branches' - e.g. a module is compatible with CHDK and CHDK-DE; but not SDM?

Also in module_load.c you have an optional check for PLATFORMID.
The PLATFORMID is the camera identifier for a specific model - why would you have a module that is specific to only a single camera model? If you did want this what if the module is compatible with more than one camera model - would you need to compile a seperate module for each camera?

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics


SimplePortal © 2008-2014, SimplePortal