Include changes

xenic
2013-10-30
2013-11-20
1 2 3 > >> (Page 1 of 3)
  • BSzili

    BSzili - 2013-11-15

    @xenic
    Sorry, I have no idea how that happened. I always update my working copy before committing anything, and I didn't get any conflicts.

     
  • xenic

    xenic - 2013-10-30

    Now that kas1e has eliminated the Include/dopus I'm going to add it back for another purpose. I'll be moving debug/dopus_debug.h and version/dopus_version.h to dopus/ and combining some other includes into a new file there. There may be some duplicate include files until I'm done in a day or 2. Most, if not all, of the amiga.h files are the same so most of them will be removed when I'm done. Also, I'll add some things to the new include file that will allow us to use the new OS4 SDK and eliminate all the "deprecated" warnings in the OS4 compile.

     
  • xenic

    xenic - 2013-10-30

    @kas1e
    I've commited the new includes and updated about, cleanup & configopus modules. It's taking longer than I thought but I should have it done in a day or 2.

     
  • BSzili

    BSzili - 2013-11-01

    I'm sorry if you've done this in your working copy already, but the prototypes

    #if !defined(__MORPHOS__) && !defined(__AROS__)
    char *stpblk(char *p);
    #endif
    char *stptok(const char *s, char *tok, size_t toklen, char *brk);
    

    should be added somewhere in ftp.module, or to dopus/common.h. I'm treating implicit function declarations as errors for the AROS build.

     
    Last edit: BSzili 2013-11-01
  • xenic

    xenic - 2013-11-01

    @BSzili
    Since those functions are only used in ftp.module, I'll add that to ftp.h which is included everywhere in the ftp sources. If that won't work, let me know.

     
  • xenic

    xenic - 2013-11-01

    @kas1e
    I've completed the includes changes and everything should now compile with the new OS4 SDK. I rushed through the change and may need to make some minor adjustments but that shoulddn't affect the compiles.

    I tested the changes with OS3 & OS4 compile. You need to test the MOS compile to see if there are problems. I'm sure BSzili will let me know if I break his AROS compile.

     
  • kas1e

    kas1e - 2013-11-01

    @xenic
    just in case: you can also check dopus5.org, if something wrong there will be no archive and only build log with error. of course it will compiles only one time in 24hours, but still you always can check if all compiles

     
  • xenic

    xenic - 2013-11-01

    @kas1e
    If there is an error in one compile, will the server continue to compile the other platforms? My concern has been that a compile error for one platform will cause the server script to exit and not compile the other platforms.

    EDIT: I see MOS and OS4 builds on the dopus5.org site but no OS3 or AROS builds. It's possible that the build occurred while I was changing the includes. Are the build times in GMT or local time for the location of the server? I need to avoid making changes at the time the builds are occurring.

     
    Last edit: xenic 2013-11-01
  • kas1e

    kas1e - 2013-11-01

    @xenic
    if one build have errors another ones still continue. i.e all 5 builds done always so we can see errors of any of them. as for time : script downloa svn and do builds in 00:05 every night. sadly i cant say now gmt time (not at home now), but if i remember right it was gmt+2 or gmt+4, byt exactly can say tomorrow

     
  • xenic

    xenic - 2013-11-01

    @kas1e
    Dopus5 should now compile with the new OS4 SDK. For some reason my OS3 ftp.module won't link unless I make TimerBase a global variable. I'm going to commit code that compiles with my OS3 compiler. I know you were getting a good OS3 compile but hopefully the changes I'm going to commit will work for all OS3 compilers. If not, I'll need to revert my changes and live with not compiling OS3 ftp.module.

     
  • kas1e

    kas1e - 2013-11-02

    @xenic
    seems os3 build on server builds fine after your change. but aros builds stop compiles (and for arm and for i386). check plz build logs to see errors .

     
  • BSzili

    BSzili - 2013-11-02

    It fails because

    #include <intuition/cghooks.h>
    

    didn't make it into dopus/common.h.

     
  • xenic

    xenic - 2013-11-02

    @BSzili
    Thanks for pointing that out. The missing include has been added and committed. Hopefully that will restore the AROS overnight compile.

    The OS4 includes are designed to include all related include files in the proto include file. I guess the includes for other platforms are mostly based on the OS3 includes.

     
  • xenic

    xenic - 2013-11-02

    @all
    I'm going to fix the modules makefiles so that for each platform the module makefiles will all be the same. If a change in the module makefiles are needed in the future, one set of makefiles can be changed and copied to all modules. I will also be moving several include files that are used in several Dopus5 components into Include/dopus. If anyone spots any problems on another platform (except OS3 and OS4, which I can test), please let me know.

     
  • kas1e

    kas1e - 2013-11-04

    @Xenic

    Checked latest commits in last days, and have question: Is there any needs for all those "includes in includes", i mean: mod_cleanup.h, mod_configopus.h, mod_ftp.h, mod_icon.h, mod_pathformat.h, etc. They (imho) have no needs to be there, and instead, what we have inside of them, better to have in the modules itself. As "include/dopus" its something global , why we need to put there includes, which only include those includes for the necessary modules, while we can just add them directly in those modules where they need ? I mean, we can by the same way put all includes from all modules in include/dopus, which also imho a bit wrong.

    Imho, good when all what related to one module, included in the module dir, and not put it to include/dopus. its just a bit mess the things imho. Its ok of course to have some include which is global for everything, but put there specific for one module includes, make no big sense and (imho) should be instead in the module's directory.

    Also i think mod_base.h content can go to something like "Include/Libraries/module.h".

     
    Last edit: kas1e 2013-11-04
  • xenic

    xenic - 2013-11-04

    @kas1e
    The mod_cleanup.h, mod_ftp.h etc. includes were a last minute change to keep the overnight build working. While I was changing all the module makefiles so that they are all the same for each platform, I decided that the includes that are needed by more than one component of Dopus5 (i.e. in Program and some modules) should be in one place. However, moving those includes into one include file in Include/dopus failed because so many includes depend on other includes. I'm sure you've noticed that if you change the order of some of the includes in Program/dopus.h, the compile get's totally screwed up.

    Because my original plan would require more complicated changes to all the includes, I split the modules includes in Include/dopus so that I would know where they belonged and I can easily change them back to the way they were before (i.e. like "#include Program/main_commands.h" in icon module). Those "mod_..." includes in Include/dopus5 are temporary. Either I find a better way to do the includes or I put them back in modules the way they were.

    When variables & structures are used by more than one component of a program, they should be on one place (like Include/dopus). If a variable or structure needs to be changed, then the change will be included wherever the variable or structure are used. That's common programming practice.

    One thing we need to avoid is redefining a structure in several components of the program like we have in the ftp module. If you look at ftp_opusftp.h in the ftp module you will see that GUI_element is the same as GUI_element in Program/display.h. That was necessary because including Program/display.h will screw up the ftp compile. However, if we ever need to change GUI_element in the Program then the old GUI_Element declared in ftp/ftp_opusftp.h will be different and could cause problems unless someone remembers that it's declared in 2 places.

    I'm going to try to move all the Program defines (i.e. '#define') into a single file (dopus/common.h) to make it easier to work with the variable & structure declarations in the include files in Program. Does that bother your? I won't commit any of that until I check with you and BSzili.

    Also i think mod_base.h content can go to something like "Include/Libraries/module.h".

    That's a good idea. I'll try that change and commit it if it works out.

     
  • xenic

    xenic - 2013-11-04

    @kas1e
    I noticed that there are some structures in libraries/module.h that are not packed. Is there a reason for that or can I add packing for those structures too.

     
  • kas1e

    kas1e - 2013-11-04

    @xenic
    as for me all your plans are logical and good after your explain. as for structures: they ofcourse should.all be packed (just recheck twice as in some places packing done for whole file (ie start at begining and ends.at bottom) and in some files packing done around structures only)

     
  • xenic

    xenic - 2013-11-05

    @kas1e
    I committed the changes for moving the module base struct to Include/libraries/module.h. The OS3 overnight compile has failed for 2 days now. I just compiled the OS3 DOpus5 and it works fine. If the OS3 overnight compile fails tommorrow, then we need to find out why it compiles for me but not on your server.

     
  • kas1e

    kas1e - 2013-11-05

    @Xenic

    I manually tried to rebuild all on server (svn 840), and os3 build still fails as few days before with such error:

    ipc.c: In function `Local_IPC_ProcStartup':
    ipc.c:12: `SysBase' undeclared (first use in this function)
    ipc.c:12: (Each undeclared identifier is reported only once
    ipc.c:12: for each function it appears in.)
    
     
  • xenic

    xenic - 2013-11-06

    @kas1e
    I commited changes before the new nightly build. I changed ipc.c and removed the warning. The warning still shows up in the log for the nightly build. That means that there was no new compile of the OS3 version; it's the same compile and log that was there yesterday. I think something has gone wrong with your server script or compile for OS3.

    I examined the includes and concluded that it will take to long to untangle them so I removed the temporary includes from Include/dopus and restored the includes in the modules back to they way the were; external inlcudes are called directly like "#include Program/...".

     
  • kas1e

    kas1e - 2013-11-06

    @Xenic
    Seems that you just upload your change after nightly build done (or on that time), so latest commit (842), wasn't in place when compilation starts.

    So i just now manually update svn again, do rebuild, and while main program, and configopus module builds fine, it failson filetype module with the same errors:

    filetype.c:639: `SysBase' undeclared (first use in this function)
    filetype.c:639: (Each undeclared identifier is reported only once
    filetype.c:639: for each function it appears in.)
    filetype.c: In function `finder_editor_proc_code':
    filetype.c:813: `SysBase' undeclared (first use in this function)
    filetype.c: In function `creator_display_info':
    filetype.c:1999: warning: initialization makes integer from pointer without a cast
    filetype.c: In function `creator_editor_proc_code':
    filetype.c:2255: `SysBase' undeclared (first use in this function)
    

    So i add the same as you do in the ipc.c, its going futher, but then fail on build of ftp.module, with:

    In file included from ftp_main.c:66:
    ftp.h:34: proto/socket.h: No such file or directory
    

    It happens because you remove from ftp makefile that:

    -I/usr/local/amiga/m68k-amigaos/netinclude 
    

    Which i added there to have ability to split normally netincludes on server (to not mess with those which come originally, and our ones which send me BSZili). On native builds it make no harm to have such -I added, so should be ok to have it back.

    So, after i fix on server filetype.c and add such include in makefile of ftp.module, os3 build done again.

    Want you me to commit those changes, or you can do so ?

    EDIT: Btw, i checked now, and server's time are GMT+0. I.e. svn updates in the 00:05 by GMT+0, and then recompile happens (for about 10-15 minutes in summ).

     
    Last edit: kas1e 2013-11-06
  • xenic

    xenic - 2013-11-06

    @kas1e

    Which i added there to have ability to split normally netincludes on server (to not mess with those which come originally, and our ones which send me BSZili). On native builds it make no harm to have such -I added, so should be ok to have it back.

    The harm it does is that all the work I did to make the module makefiles the same was for nothing because you stuck your network includes in a location that is not in the standard gcc include path. In your /usr/local/amiga directory you should have these directories:

    bin
    include
    info
    lib
    m68k-amigaos
    man
    

    If your includes are the same as the ones in the 68k-gcc_cross_cygwin_ndk directory in the repository, you should be able to move the files and directories from the netinclude directory to the /usr/local/amiga/include directory and everything should work without the special include.

    When I extracted all the archives in the repository 68k-gcc_cross_cygwin_ndk directory, the only thing in amiga/include directory is a g++-3 directory.
    In my standard gg 68k gcc installation, all the network files are located there too.

     
  • xenic

    xenic - 2013-11-06

    @kas1e
    I committed the fix for Modules/filetype/filetype.c but can't understand why those SysBase errors just suddenly appeared. Nothing that I changed for the makefiles should have had anything to do with those errors. Did you change the OS3 compiler or the preprocessor?

     
  • kas1e

    kas1e - 2013-11-07

    @Xenic

    Did you change the OS3 compiler or the preprocessor?

    Of course not, its all the same from beginning, why i ever will change anything there and didn't inform you :)

    If your includes are the same as the ones in the 68k-gcc_cross_cygwin_ndk directory

    That what i do to install os3 cross-compiler on server:

    cd /root/cross-compilers-distribs/
    mkdir os3
    cd os3
    wget http://cross.zerohero.se/i686-linux/m68k-amigaos-binutils-2.14.tar.bz2
    wget http://cross.zerohero.se/i686-linux/m68k-amigaos-gcc-2.95.3.tar.bz2
    cp * /usr/local/
    cd /usr/local/
    tar jxf m68k-amigaos-binutils-2.14.tar.bz2
    tar jxf m68k-amigaos-gcc-2.95.3.tar.bz2
    rm -rf m68k-amigaos*
    
    m68k-amigaos-gcc -v
    Reading specs from /usr/local/amiga/lib/gcc-lib/m68k-amigaos/2.95.3/specs
    gcc version 2.95.3 20010315 (release/lcs-2002-04-12) 
    

    Also i download 68k netincludes from BSzili (those ones which i upload before for you there). I was told to not put them into /usr/local/amiga/m68k-amigaos/ , as it can overwrite some important files which should't be overwritten. So instead i just add them as separate directory.

    Maybe you can prepare an archive with all netincludes, so i can just unpack them and put to /usr/local/amiga/m68-amigaos/ without messing with netincludes from BSZili ?

     
    Last edit: kas1e 2013-11-07
1 2 3 > >> (Page 1 of 3)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks