how to avoid apps<->SDK variables conflicts in best way ?

13 posts / 0 new

Log in or register to post comments

Last post

Mon, 2012-05-07 12:41

#1

kas1e

kas1e's picture

Offline

Last seen: 5 months 2 days ago

Joined: 2010-11-30 15:30

how to avoid apps<->SDK variables conflicts in best way ?

Pretty offten some programms from other oses use in their code different kind of variables for their internal purposes, and offten in let's say games, you have Screen, Point, EventHandler and co, which all the time conflicts with SDK ones. Currently, i have just 2 ways to fix it: 1. Disable it in SDK. That way fast, as need to change only in one place, but its bad just because you can forget about that commenting and have lots of errors later, while you will trying to understand why. 2. Change them in the code of the apps itself. That more or less kind of ok way (as we didn't touch SDK), just madness slow and very boring. Imagine hundreds of files, where Screen vairable used, and i need manually check every source code, found Screen words, check if it not something like ScreenXXXXX or xxxxScreenxxxx, or just some plain-comment-text, and change it on something like ScreenA or kind, if it what i search for (so i can't automatise it, as there is many different scenearios when it should't be changed). Have anyone any ideas how it can be easy workorounded, so no more manuall changes every will be made , and everything will works as should and in SDK, and in the apps code itself ? I think that maybe it possible in the SDK files, one time add some #ifdefs maybe or kind.. Any ideas are welcome.

Mon, 2012-05-07 13:44

#2

salass00

salass00's picture

Offline

Last seen: 1 month 2 weeks ago

Joined: 2011-02-03 11:27

For C++ code you can just add

For C++ code you can just add "-D__USE_AMIGAOS_NAMESPACE__" to CXXFLAGS and all the OS structures and such will be defined under "AmigaOS" namespace. For C just avoid including AmigaOS includes in such files that have these conflicting definitions (shouldn't be too hard for a ported program). If you have to use AmigaOS functions directly you can always write a separate source file with functions containing the AmigaOS calls in it and then just use these from the rest of the program.

Tue, 2012-05-08 01:58

(Reply to #2) #3

broadblues

broadblues's picture

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

For C just avoid including

For C just avoid including AmigaOS includes in such files that have these conflicting definitions (shouldn't be too hard for a ported program). If you have to use AmigaOS functions directly you can always write a separate source file with functions containing the AmigaOS calls in it and then just use these from the rest of the program.

That as my approach in blender, where there were many namespace clashes usually words like 'Image'. I simply isolated all the amigaos code into seperate files. For a maintainable port this is usually the best way anyway.

Tue, 2012-05-08 12:01

(Reply to #3) #4

kas1e

kas1e's picture

Offline

Last seen: 5 months 2 days ago

Joined: 2010-11-30 15:30

Btw, what if for plain C

Btw, what if for plain C apps, just use not gcc, but g++ instead, so then -D__USE_AMIGAOS_NAMESPACE__ and no worry about isolating of amiga files ? Why i still worry about something like this good fix for c++ but for c: its because offten when you port apps, there is no any amiga specific code in the app. Its just one include include another, another include include other one, and in end, its come to some dos / exec / intuition includes, isolating of which mean again or changes in SDK, or playing games with the code of the app, which some time will be even harde in compare with chaning all the labels names. And its ok if it one, or two apps which you mantain, but when you just port many of them, and want somehow get rid of manuall and annoing work, some kind of solution still good.. All the ported app usually done not for amigaos, so they know nothing about amiga includes, and imho its just in the SDK it done like this that onflicts because of includes happens. I do not know, maybe just in the SDK files add some #ifdef AVOID_SDK_CONFLICTS , and when compile a programms just -D__AVOID_SDK_CONFLICTS__ , and so linker will never attach specific parts of includes when flag are used ?

Tue, 2012-05-08 15:09

(Reply to #4) #5

broadblues

broadblues's picture

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

Btw, what if for plain C

Btw, what if for plain C apps, just use not gcc, but g++ instead, so then -D__USE_AMIGAOS_NAMESPACE__ and no worry about isolating of amiga files ?

You can build C apps with g++ but it will enforce c++ rules. An application written for C will likely not meet these ultra fussy requirements (particularly with types) so you could end up with as much hassle as you had before to fix the code, just different hassle....

Its just one include include another, another include include other one, and in end, its come to some dos / exec / intuition includes, isolating of which mean again or changes in SDK,

There aren't many include files that get included that way. Probably only exec/types.h Assuming you are talking about files that ultimately get included by clibrary includes. Often types are defined high up in the applications include file tree and you just add some conditional compilation there to avoid redefineing the types. If these includes are drawn in by some other ported library then the problem is with that port, and you should ask the author of that port to fix it, ot fix it yourself.

I do not know, maybe just in the SDK files add some #ifdef AVOID_SDK_CONFLICTS , and when compile a programms just -D__AVOID_SDK_CONFLICTS__ , and so linker will never attach specific parts of includes when flag are used ?

Trying to adapt the SDK to avoid namespace clashes in C code is a moving target and not the way to go. Ultimately the problem is that many "portable" applications, really means they build on more than one kind of unix. (and windows if you are really lucky). It's a pain but that's what porting is about.

Tue, 2012-05-08 15:27

(Reply to #5) #6

afxgroup

afxgroup's picture

Offline

Last seen: 10 months 2 weeks ago

Joined: 2011-02-03 15:26

in my experience the best

in my experience the best thing is to replace with an editor (like Textwrangler on Mac) all references of Image with something like _Image... Otherwise you will spend a lot of time to find useless solution (like comment temporary the SDK structs) However if you need to keep in sync the project this is not a good solution and you must find another way to fix this problem.

Tue, 2012-05-08 15:52

(Reply to #6) #7

kas1e

kas1e's picture

Offline

Last seen: 5 months 2 days ago

Joined: 2010-11-30 15:30

@afxgroup Yep, that why i do

@afxgroup Yep, that why i do as well (changing manually variables) currently. @all Still, i think that such a way can be not that bad in end: let's say we have clash with Image. Linkier always point out where in SDK clash happens, so we just go to that SDK file, and do: #ifndef __AVOID_SDK_CLASHES__ there is clashed part #endif And add to linker -D__AVOID_SDK_CLASHES__. By this way we will fix it in SDK (sure touching of SDK suck, but..) but everything will works just the same as before, just once we will have a code which clash with Image, we add neessary flag to linker, and all going well. If we not pass the flag, then everything just like before. By this way just collect all the usuall clashes and change them one time. Its usually Screen, Image, EventHandler, Point, Box, Menu and few others. Not that many in general, just offten used in different apps.

Tue, 2012-05-08 16:41

(Reply to #7) #8

broadblues

broadblues's picture

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

@kas1e Yep, that why i do as

@kas1e Yep, that why i do as well (changing manually variables) currently.

That's the least maintainable way to do it. If you need to globablyy change avariable or type name, do it with a #define This way assumes you are *not* mixing amigaos specific and generic program code....

// This block of code should go before the include that draws in the namepace clash.
// Ideally in a high level include file that is included by all project files.
#if defined(__amigaos4__)
 
#include <the SDK include that defines Image>
//This #define only affects that which comes after it so name clash is elimnated and 
#define Image _Image
#endif

If the problem occurs *because* you are mixing amigaos and generic code them move the amigaos code to a sepaerate file. and add a #define to the original to choose the amigaos function instead. Usuing the above means you only have a small amount of work to maintain changes against a CVS repository.

@kas1e Still, i think that such a way can be not that bad in end: let's say we have clash with Image. Linkier always point out where in SDK clash happens, so we just go to that SDK file, and do: #ifndef __AVOID_SDK_CLASHES__ there is clashed part #endif And add to linker -D__AVOID_SDK_CLASHES__. By this way we will fix it in SDK (sure touching of SDK suck, but..) but everything will works just the same as before, just once we will have a code which clash with Image, we add neessary flag to linker, and all going well. If we not pass the flag, then everything just like before. By this way just collect all the usuall clashes and change them one time. Its usually Screen, Image, EventHandler, Point, Box, Menu and few others. Not that many in general, just offten used in different apps.

A few things to say about this: 1. Don't modify you own copy of the SDK in any way other than adding files and libraries to the local directory. because a: When you come to upgrade the SDK you will lose all chnages, and at the least have to reapply them by hand. b: When some one else takes over the maintenance of your port, as oftens happens, or needs to buikld it from scratch to test something they will not have your changes and so will not be able to do it. 2. Lets's assume that you get this idea past ssolie and he nake such changes to the SDK officially. (dream on :-)) So to fix app A

#if defined(__AVOID_SDK_CLASHES__)
#define Image _Image
#endif

But appp B has

struct _Image {}
 
typedef struct _Image Image.

Damn need to change the SDK again.... Do you see that what am saying? You are never going to predict how any given app will need the SDK modifying to avoid these clashes. The correct way is to change the port code not the SDK.

Tue, 2012-05-08 21:04

(Reply to #8) #9

kas1e

kas1e's picture

Offline

Last seen: 5 months 2 days ago

Joined: 2010-11-30 15:30

@Andy If the problem occurs

@Andy

If the problem occurs *because* you are mixing amigaos and generic code them move the amigaos code to a sepaerate file. and add a #define to the original to choose the amigaos function instead.

But when we port something from let's say unix, code do not have amigaos code. So, there is nothing what we can "move the amigaos code to a separate file". All the amigaos code already in separate files : in the SDK. App by itself didn't contain amigaos specific code which i can move to separate files, its only SDK which containt it.

Usuing the above means you only have a small amount of work to maintain changes against a CVS repository.

You mostly talk about something which someone want to mantain. But i mostly say about some port, which you do, and never will come back to it. So, to avoid problems for "fast porting".

a: When you come to upgrade the SDK you will lose all chnages, and at the least have to reapply them by hand.

Sure, but there is not many clashes usually, just about 5-10 maximum for all the times. Just one time write them to some text file, and when new SDK coming out just in few minuts make a changes.

b: When some one else takes over the maintenance of your port, as oftens happens, or needs to buikld it from scratch to test something they will not have your changes and so will not be able to do it.

Sure, fair point. If only we talk about something which worth of mantaining, etc. I mostly mean all of this in terms of massive-fast-porting. There is some scenarios, when you loose hour for changing all of this manually, but game in end want something which we do not have (like some opengl extensions), or its buggy, or just slow like hell, but you already spend a few hours to build something which not worth to build by any of the reassons. But when its somehow workorounded, then for fast-for-check-ports it can be pretty nice. In general, one can just check it with such a -D__AVOID_SDK_CLASHES__, but if it will worth of it, then, manually change everything for final release,etc.

2. Lets's assume that you get this idea past ssolie and he nake such changes to the SDK officially. (dream on :-)) So to fix app A #if defined(__AVOID_SDK_CLASHES__) #define Image _Image #endif But appp B has struct _Image {} typedef struct _Image Image.

Mm.. nope, i didn't mean that way. I mean:

#if !defined (_AVOID_SDK_CLASHES__)
 
 .. there is everything without changes in the SDK .. just when we add that flag, that piece of include just do not grabs .. That will works, because sometime ago i do and manual changes in the SDK as well, and they was only in commenting one single clashing line (=> no mess). 
 
#endif

In other words, only (and only when), -D__AVOID_SDK_CLASHES__ are used, something changes in the SDK (auto-commenting of clashing lines). But if no flag passes, SDK just works like before, without any problems, so programms B,C,and any other will continue to works as before and only that one which specify -D__AVOID_SDK_CLASHES__ will just skip clashing lines :)

You are never going to predict how any given app will need the SDK modifying to avoid these clashes.

From all my expirience in last years (which is few hundreds of ports), all the clashes usually Image, Screen, Window, Menu + some others, and i back in the past pretty fine comment out the lines in the SDK about. Sure, changing the SDK its always bad idea, but as we know what we do, why not play with :)

Wed, 2012-05-09 00:36

(Reply to #9) #10

salass00

salass00's picture

Offline

Last seen: 1 month 2 weeks ago

Joined: 2011-02-03 11:27

But when we port something

But when we port something from let's say unix, code do not have amigaos code. So, there is nothing what we can "move the amigaos code to a separate file". All the amigaos code already in separate files : in the SDK. App by itself didn't contain amigaos specific code which i can move to separate files, its only SDK which containt it.

Obviously that is not the case since as you already said you have conflicts. You should check where the offending SDK file is being included from and if it's in the program remove it. SDK includes don't just magically include themselves, either the program is including them directly or it includes something else which in turn includes them in which case that include will have to be fixed and not the OS includes. BTW you can stop individual OS includes from being included by adding -DPATH_TO_INCLUDE_H to the commandline. F.e. if <intuition/intuition.h> file is causing problems just add -DINTUITION_INTUITION_H to CFLAGS, but as I said before you really should check where the files are being #include:d from.

Wed, 2012-05-09 01:53

(Reply to #10) #11

broadblues

broadblues's picture

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

But when we port something

But when we port something from let's say unix, code do not have amigaos code. So, there is nothing what we can "move the amigaos code to a separate file". All the amigaos code already in separate files : in the SDK. App by itself didn't contain amigaos specific code which i can move to separate files, its only SDK which containt it.

I'm not sure if we are talking at cross purposes here, but if you are compiling "pure" unix code, then only the C library includes will occur, and these will only result in a few includes from exec, mainly exec/types.h as I stated above. If you are getting clashes when you haven't added any Amiga code yourself then they must be comng via a third party libraries includes, so it's those that need fixing not the SDK. Do you have a specific recent example with the errors emited from gcc? I don't quite undertsnd what you mean about "fast porting" if it's worth porting at all it';s worth doing properly. If you just want to test build something to see if a port is viable, then could do what you like, but a released port should not IMHO be done by hacking the SDK. If all you want with your suggested 'hack' is to exclude specific parts of the SDK then as salass00 says you can set the macro found at the top of each file eg a completely random example (first one under the mouse pointer) #ifndef IMAGES_FILLER_H #define IMAGES_FILLER_H just add #define IMAGES_FILLER_H 1 to the project header files or to the gcc command line with -D

Wed, 2012-05-09 11:09

(Reply to #11) #12

afxgroup

afxgroup's picture

Offline

Last seen: 10 months 2 weeks ago

Joined: 2011-02-03 15:26

most of the problems are

most of the problems are caused by GL libraries. I've only see this kind of problem on games or graphics programs. And it is not always possible use -DINTUITION_INTUITION_H since maybe that file is needed by another file in the SDK. Since MiniGL use the standard sdk libraries sometimes is impossible to avoid this problem. The only solution is to rename the structures into the source code

Wed, 2012-05-09 15:13

(Reply to #12) #13

broadblues

broadblues's picture

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

Since MiniGL use the standard

Since MiniGL use the standard sdk libraries sometimes is impossible to avoid this problem. The only solution is to rename the structures into the source code

In this case renaming is not the best solution but using a #define would be as I described above. and some varaition on #if defined(__amigaos4__) #include #define Image __Image #define Window __Window #endif to the highest level include of the project, or if the includes done't form a true tree to the top of each affected source file. In the sceond case it nmight be worth creating a include file _fix_clashes.h and including that instaed of the #if block.

Log in or register to post comments