[Harbour] 2008-02-09 10:06 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
2008-02-09 10:06 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl) * harbour/contrib/hbtpathy/tplinux.c * harbour/contrib/hbtpathy/tpos2.c * harbour/contrib/hbtpathy/tpwin32.c * Fixed guarding file content with proper OS constant (HB_OS_UNIX, HB_OS_WIN_32, HB_OS_OS2) -- Marek Paliwoda mpaliwoda at interia pl -- Potega i sila na wyciagniecie reki - sprawdz! Zagraj http://link.interia.pl/f1cf3 ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
Hi Marek, Truely speaking the whole libnames problem is a little bit unclear to me. I don't want to jump in, or take a one side in this disputation, but certainly if the decision was to rename the libnames, it would be better to do it now than later. 1.0 means something (at least to me). BTW, I don't know technical reasons behind having so much libraries instead of just one harbour-static.lib, but surely I never liked the current set of so much libraries at all. If it has any benefits, I doubt they'll overcome its weaknesses (a simple example is a cross libraries dependency, which makes troubles for some linkers). I completely agree that it would be way better to have less libs. This would remove the burden from all users to deal with this whole bunch of names, and break the link process by leaving or misspelling one or two of them. It would also make all link commands much shorter. Circular dependency would also go as a problem. Overriding parts of the libs (like getsys) wouldn't suffer (AFAICS). Having one lib would have the benefit to be (more) in sync with the .dll version of the lib. One drawback which was mentioned on the list, is that we have a different license for the compiler lib, the RTL libs and pbly also PCRE. We also have some mutually exclusive libs. Also, since GTs and RDDs are plugin type of libs, I wouldn't mix them either in the global one. So, we might end up with a few separate libs at the end. Actually - if I see this correctly - the latest changes in the GNU make system have the benefit that it seems now much easier to generate one global lib (Thanks a lot to Ryszard for this work), than it would have been before. Having so many libs has nothing to do with any decisions in the past, it was just how the project evolved, and some new modules where simply put into new dirs (which is perfectly okey) and all these automatically got separate libs. This is a possible simplified lib layout: - harbour (hbcpage + hbcommon + hbdebug + hblang + hbmacro + hbpp + hbrdd + hbrtl + hbvm + hbrddusr + hbsix + hbhsx) - hbcomp - hbpcre - gt* - rdd* - hbmain* - hbnulrdd This was already mentioned on the list not long ago, and there was not too many reactions to it. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: 2008-02-08 15:58 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemek: 2008-02-08 15:58 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/config/os2/global.cf ! use FOR command to delete group of files With these changes, with old make.exe (3.76.1): - make_gnu.cmd: work entirely - make_gnu.cmd install: work entirely - make_gnu.cmd clean: fail [E:\harbour802]make -r clean 1make_gnu.log make: [clean] Error 31880 (ignored) make[1]: [clean] Error 31880 (ignored) make[1]: [clean] Error 31880 (ignored) make[2]: [clean] Error 31880 (ignored) make[2]: [clean] Error 31880 (ignored) make[1]: [clean] Error 31880 (ignored) make[1]: [clean] Error 31880 (ignored) make[2]: [clean] Error 31880 (ignored) make[2]: [clean] Error 31880 (ignored) make[1]: [clean] Error 31880 (ignored) make[1]: [clean] Error 31880 (ignored) make[2]: [clean] Error 31880 (ignored) Previously I made changes to global.cf locally and now it can delete group of files, remove directories, AND delete individual files, so all processes are complete My config\os2\global.cf are included below Can you delete lines marked with label DAVID: and commit to SVN ? Thanks ( as I see, e-mail client wrap some lines ) In summary changes are (based in PREVIOUS global.cf): OS2_ARCH_DIR = $(subst /,\,$(HB_ARCH)) OS2_LIB_DIR = $(subst /,\,$(LIB_DIR)) OS2_LIB_PATH = $(subst /,\,$(LIB_PATH)) OS2_LIB_ARCH = $(subst /,\\,$(LIB_ARCH)) --- It let to delete individual files in place of OS2_ARCH_DIR = $(subst /,\\,$(HB_ARCH)) OS2_LIB_DIR = $(subst /,\\,$(LIB_DIR)) OS2_LIB_PATH = $(subst /,\\,$(LIB_PATH)) OS2_LIB_ARCH = $(subst /,\\,$(LIB_ARCH)) and \\*.* --- It let do delete group of files in place of \*.* David Macias # # $Id: global.cf 8286 2008-02-07 19:17:55Z druzus $ # all : first HB_GT_LIST=\ gtcgi \ gtos2 \ gtpca \ gtstd \ # verify if GT drivers exist #HB_GT_LIBS := $(foreach gt, $(HB_GT_LIST), $(if $(wildcard $(TOP)$(ROOT)source/rtl/$(gt)),$(gt),)) # temporary workaround for some possible problems with some GNU make versions HB_GT_LIBS := $(HB_GT_LIST) ifeq ($(HB_GT_LIB),) HB_GT_LIB = gtos2 endif ifeq ($(SHLVL),) # An OS/2 command shell ARCH_DIR = $(HB_ARCH) #DAVID: OS2_ARCH_DIR = $(subst /,\\,$(HB_ARCH)) #DAVID: OS2_LIB_DIR = $(subst /,\\,$(LIB_DIR)) #DAVID: OS2_LIB_PATH = $(subst /,\\,$(LIB_PATH)) #DAVID: OS2_LIB_ARCH = $(subst /,\\,$(LIB_ARCH)) OS2_ARCH_DIR = $(subst /,\,$(HB_ARCH)) OS2_LIB_DIR = $(subst /,\,$(LIB_DIR)) OS2_LIB_PATH = $(subst /,\,$(LIB_PATH)) OS2_LIB_ARCH = $(subst /,\\,$(LIB_ARCH)) DIRSEP = $(subst /,\,\) MK = $(subst /,\,$(subst \~,~,$(MAKE))) ifeq ($(OS2_SHELL),) # Not running on OS/2 (which comes in handy for 'make -r clean') RM = del /q else # Running on OS/2 RM = del /n endif RD = rmdir CP = copy MV = move MD = md ifeq ($(LIB_PATH),) dirbase:: -CMD.EXE /C FOR %d IN ($(HB_ARCHITECTURE) $(OS2_ARCH_DIR)) DO IF NOT EXIST %d $(MD) %d clean:: #DAVID: -CMD.EXE /C IF EXIST $(OS2_ARCH_DIR)\*.* $(RM) $(OS2_ARCH_DIR)\*.* -CMD.EXE /C IF EXIST $(OS2_ARCH_DIR)\*.* $(RM) $(OS2_ARCH_DIR)\\*.* -CMD.EXE /C FOR %d IN ($(OS2_ARCH_DIR) $(HB_ARCHITECTURE)) DO IF EXIST %d $(RD) %d else dirbase:: -CMD.EXE /C FOR %d IN ($(HB_ARCHITECTURE) $(OS2_ARCH_DIR) $(OS2_LIB_PATH) $(OS2_LIB_DIR)) DO IF NOT EXIST %d $(MD) %d clean:: #DAVID: -CMD.EXE /C IF EXIST $(OS2_ARCH_DIR)\*.* $(RM) $(OS2_ARCH_DIR)\*.* -CMD.EXE /C IF EXIST $(OS2_ARCH_DIR)\*.* $(RM) $(OS2_ARCH_DIR)\\*.* -CMD.EXE /C FOR %d IN ($(OS2_ARCH_DIR) $(HB_ARCHITECTURE)) DO IF EXIST %d $(RD) %d -CMD.EXE /C IF EXIST $(OS2_LIB_ARCH) $(RM) $(OS2_LIB_ARCH) endif else # bash ARCH_DIR = $(HB_ARCH) MK = $(MAKE) RM = rm -f RD = rm -f -r CP = cp -f MV = mv -f MD = mkdir MDP = mkdir -p OS2_LIB_ARCH = $(LIB_ARCH) dirbase:: @[ -d $(ARCH_DIR) ] || $(MDP) $(ARCH_DIR) @[ -z $(LIB_DIR) ] || [ -d $(LIB_DIR) ] || $(MDP) $(LIB_DIR) clean:: -$(RD) $(ARCH_DIR) $(LIB_ARCH) endif ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
Hi Viktor, [...] One drawback which was mentioned on the list, is that we have a different license for the compiler lib, the RTL libs and pbly also PCRE. O s... ;-), I completly forgot about. But it means that we have problem with .dll (.so) builds also, haven't we ? We also have some mutually exclusive libs. Also, since GTs and RDDs are plugin type of libs, I wouldn't mix them either in the global one. So, we might end up with a few separate libs at the end. Actually - if I see this correctly - the latest changes in the GNU make system have the benefit that it seems now much easier to generate one global lib (Thanks a lot to Ryszard for this work), than it would have been before. Yes, I appreciate Ryszard's contribution very much. And yours, and Przemek's, and all others :). Having so many libs has nothing to do with any decisions in the past, it was just how the project evolved, and some new modules where simply put into new dirs (which is perfectly okey) and all these automatically got separate libs. This is a possible simplified lib layout: - harbour (hbcpage + hbcommon + hbdebug + hblang + hbmacro + hbpp + hbrdd + hbrtl + hbvm + hbrddusr + hbsix + hbhsx) - hbcomp - hbpcre - gt* - rdd* - hbmain* - hbnulrdd This was already mentioned on the list not long ago, and there was not too many reactions to it. That's a proposition which seems resonable, but let's discuss it after the release :). -- Marek -- Zmus swojego faceta, zeby to przeczytal Kliknij http://link.interia.pl/f1ceb ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: 2008-02-08 15:58 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Sat, 09 Feb 2008, David Arturo Macias Corona wrote: With these changes, with old make.exe (3.76.1): - make_gnu.cmd: work entirely - make_gnu.cmd install: work entirely - make_gnu.cmd clean: fail [E:\harbour802]make -r clean 1make_gnu.log make: [clean] Error 31880 (ignored) [...] Previously I made changes to global.cf locally and now it can delete group of files, remove directories, AND delete individual files, so all processes are complete My config\os2\global.cf are included below Can you delete lines marked with label DAVID: and commit to SVN ? Thanks ( as I see, e-mail client wrap some lines ) I think you should do it your self. If you do not have write access then please create your SF account and send your SF ID here. It will be much easier if OS2 users will make modifications for this OS directly. Now we have to guess how OS2 shell works looking for error messages. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
On Sat, 09 Feb 2008, Lorenzo Fiorini wrote: Why should we not finish Harbour at this time? Because the two main developers don't agree about latest changes. Not exactly. I agree that library names can be source of some name conflict and I like the idea to resolve the problem. I only do not like that it was done few minutes before release and break the release process. From small modification we have much bigger one then any of us expected and build/clean process on some platforms is still broken. Instead of release new binaries now we have to check all builds. Meanwhile few of us lost important data. Because both have announced they'll leave the project. Not exactly again. I only plan to reduce my activity in this project and concentrate on some other things - believe me that Harbour is not my whole life :-). But as I said there are still some things I started and I would like to finish them like MT mode or multi window core GT API. Anyhow I do not want to be master of release process. I can create binaries for some platforms when we will be ready but I do not want to decide about terms, create SVN tags, etc. I believe that we will find someone who can make it much better then me. So since it's unlike we'll have a 1.1 I think we should at least leave the lib names as they have been in the last 8 years and do a favor to poor users. It's also important argument though in fact there is a problem that we do not have compiler and linker wrapper which can work in non bash environment. Sth like hb* scripts which fully hides library names for end users so they will not notice any difference. Creating sth like that in C seems to be important. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-02-09 12:50 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-02-09 12:50 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/config/w32/global.cf * removed ' quoting from commands - *sh shells removed them but without such shell they are passed to windows command interpreter and not all version removed them best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-02-04 09:31 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Fri, 08 Feb 2008, Szakáts Viktor wrote: [...] With all due respect if someone creating an official binary release is not able to do this, we may have some other problems too. Viktor, the most important is that it will be necessary to make some modifications before compilation. I intentionally always tried to reduce them to avoid problems and typos during manual updating. I do not expect that packager will have any deep knowledge about OS or programming. I only want to ask him to run one of the build script and send us the results. It will greatly reduce differences between binary builds of the same release we had in the past. I also think that it will be good to add sth like make_tgz.sh for Windows users who do not use *nix like shell for BCC, MSVC, POCC binaries. We also still do not have make_os2.cmd which is necessary for OS2 users - now they are using make_gnu.cmd from older Harbour versions or from xHarbour. As an alternate solution we might as well distribute all those headers as a separate download, so that all headers can be copied to one dir, or to each contrib dir, and do the build as usual. This way it's not in the SVN, but still easy to access for everyone with just one easy extra step (to be done once) to extract to /include/. I can even prepare such a file. What do you think about it? It will help and maybe it's quite good final solution though it will not resolve the problem of RPMs for cross builds when user do not have write access to cross compiler environment. But I do not understand why it's important to make the packagers' life harder during RC tests. We already spend more time discussing it then it's worth. Anyhow I'll update spec files and add optional support for zlib so if someone will want create Harbour RPMs native or for cross build (Win32 and WinCE) with ZLIB support then it will be necessary to use --with zlib switch. Of course after adding the header files to one of include paths. At least it will reduce the problem. I can understand your POV and I'd definitely miss your contributions. I also plan to move away, especially since I still have no direct business interest in contributing to Harbour, but other things are constantly growing on me. Maybe making a few clients switch to the Win32 version of my app could change that. Each of us has own life which is the most important of us. I will also miss your contributions. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
On Feb 9, 2008 12:31 PM, Przemyslaw Czerpak [EMAIL PROTECTED] wrote: Not exactly again. I only plan to reduce my activity in this project and concentrate on some other things - believe me that Harbour is not my whole life :-). I'm very happy to read this. Since time is never enough by definition I still think that a two tiers development will help all. Core developers could work in a forge without having to worry about releases, makefiles, packages and so on, while others would take the sources from the forge and do all the release tasks. IMHO this will greatly speed up the development. But as I said there are still some things I started and I would like to finish them like MT mode or multi window core GT API. Sorry if I ask but how much it'll take to have MT mode? I have some projects that really need multitasking and I've to decide what to do so having even a vague idea about the time frame could help. Please understand me, I'm not asking the release day :) but simply if it can take 1 month or 1 year. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
Hi Lorenzo, Do you really find a change like this between beta3 and RC necessary and needed? It could certainly help in the future that such concerns would be expressed before deciding about these changes, yet, all I got was silence (from you) and a few approvals. Silence used to be considered okey, no concern or I don't care. All the users will need to update their makefiles, projects and/or batches/scripts to the new lib names and replace all the GTI_ to Since we have a problem which we would need to solve eventually anyway, what is the better time for it: Before 1.0? or after 1.0? I think before suggests a more mature approach for any projects. And the overall work to be done for all developers is at least the same for both cases, but probably less with the before approach. HB_GTI_ for what if the developers are looking elsewhere? Not true. See below. For me old names where consistent with Clipper lib names: 1. dir source/rdd/dbfcdx creates lib dbfcdx 2. in the source there is REQUEST DBFCDX rddSetDefault( DBFCDX ) First of all this haven't changed. Second, we have RDD names which don't have anything to do with the lib name (DBFDBT for one example), if that's what you are saying. Since one RDD lib file may contain multiple RDD names, syncing these names cannot be a goal. 3. in the Clipper 5.x drivers guide the drivers is called DBFCDX in all examples Well, all of our filenames differ from CA-Cl*pper for that matter. Except the header files of course. This is for a purpose. I find it very odd to name our libs the same way as Clipper, as this was for example making it impossible to use a common LIBRARY envvar pointing to both the CA-Cl*pper libs and the Harbour ones (for BCC32, MSVC, and probably more). Now after 8 years and 3 betas the lib become suddenly rddcdx. I think we should rename the libs as they were and revert HB_GTI to GTI_. 1.0 RC should be usable by a beta3 user without any modification. GTI_* is _still_ available the same way as it was. The only thing changed is that it's now in compatibility status rather than primary status, and those who have collisions can _explicitly_ and optionally switch them off. I'm writing this the 3rd time, first time being the ChangeLog entry itself. Maybe I wasn't clear enough. Again: GTI_* _still_ _do_ _work_. App code _doesn't need any modification_ to compile (both C and Harbour). The only implication is that in Harbour core/contrib code, HB_GTI_* usage is encouraged (but GTI_* would still work). Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-02-04 09:31 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Sat, 09 Feb 2008, Szakáts Viktor wrote: I'll look into this header package problem tomorrow. One thing that would help a lot here, is to have a separate include dir inside the Harbour source tree, which is empty in the repository, and where these headers could be spilled from the 3rd party header zip file. Such a folder could be /include/3rdparty/ or /include/usr/ I like the idea of separated subdirectory with some 3-rd party header files. It will resolve the problem. And to be clear. I do not want to put all 3-rd party header files in this directory and in most cases I will vote against adding new ones. We can keep 3-rd header files only if our library is very important for many users so it should be included in default builds and we do not have to worry much about binary compatibility with different releases of 3-rd party library. In this case (ACE and ZLIB) all these conditions are passed. In the future we will have to add zlib support to core code probably like hbpcre so it can be easy replaced by native libraries. zlib support will be necessary to implement some important features like online inet socket compression or compressed memo files. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-02-04 09:31 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Thanks Przemek. I'll look into this header package problem tomorrow. One thing that would help a lot here, is to have a separate include dir inside the Harbour source tree, which is empty in the repository, and where these headers could be spilled from the 3rd party header zip file. Such a folder could be /include/3rdparty/ or /include/usr/ Then, all make our systems could be extended to look for headers in that folder too. Otherwise, we'd need to end up spilling lots of foreign header files into /include/, which is not very good, maybe even a show stopper, or I need to rethink the way BC/VC non-GNU makes files are looking for the headers to be compatible with this new method (currently these are getting the root path of the package, and each contrib will know where to look for headers inside that package root dir) I'm not sure I was clear :-/ Brgds, Viktor On 2008.02.09., at 13:53, Przemyslaw Czerpak wrote: On Fri, 08 Feb 2008, Szakáts Viktor wrote: [...] With all due respect if someone creating an official binary release is not able to do this, we may have some other problems too. Viktor, the most important is that it will be necessary to make some modifications before compilation. I intentionally always tried to reduce them to avoid problems and typos during manual updating. I do not expect that packager will have any deep knowledge about OS or programming. I only want to ask him to run one of the build script and send us the results. It will greatly reduce differences between binary builds of the same release we had in the past. I also think that it will be good to add sth like make_tgz.sh for Windows users who do not use *nix like shell for BCC, MSVC, POCC binaries. We also still do not have make_os2.cmd which is necessary for OS2 users - now they are using make_gnu.cmd from older Harbour versions or from xHarbour. As an alternate solution we might as well distribute all those headers as a separate download, so that all headers can be copied to one dir, or to each contrib dir, and do the build as usual. This way it's not in the SVN, but still easy to access for everyone with just one easy extra step (to be done once) to extract to /include/. I can even prepare such a file. What do you think about it? It will help and maybe it's quite good final solution though it will not resolve the problem of RPMs for cross builds when user do not have write access to cross compiler environment. But I do not understand why it's important to make the packagers' life harder during RC tests. We already spend more time discussing it then it's worth. Anyhow I'll update spec files and add optional support for zlib so if someone will want create Harbour RPMs native or for cross build (Win32 and WinCE) with ZLIB support then it will be necessary to use --with zlib switch. Of course after adding the header files to one of include paths. At least it will reduce the problem. I can understand your POV and I'd definitely miss your contributions. I also plan to move away, especially since I still have no direct business interest in contributing to Harbour, but other things are constantly growing on me. Maybe making a few clients switch to the Win32 version of my app could change that. Each of us has own life which is the most important of us. I will also miss your contributions. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
On Feb 9, 2008 9:43 PM, Szakáts Viktor [EMAIL PROTECTED] wrote: It could certainly help in the future that such concerns would be expressed before deciding about these changes, yet, all I got was silence (from you) and a few approvals. At that time I thought that all the core developers agreed on it. In this case my opinion doesn't matter but when the change showed to be more complex than expected I simply suggested a quick solution: revert and plan it more carefully. Now it's clear that even other core developers had not a clear idea of the results of this change and so I expressed my opinion with the aim to find a solution. Why gtwvw moved to hbgtwvw and back to gtwvw? Because gt libs are drivers exactly like dbfcdx. What I mean is that rtl lib is never referenced in the code while dbfcdx need a REQUEST and a RddSetDefault so DBFCDX name will never die and adding rddcdx will not make things more clear. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-02-09 22:42 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-02-09 22:42 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/harbour.spec * harbour/harbour-ce-spec * harbour/harbour-w32-spec * harbour/make_rpm.sh * harbour/make_rpmce.sh * harbour/make_rpmw32.sh * updated for recent changes in library names * added '--with zlib' build switch * changed '--without odbc' to '--with odbc' * changed '--with adsrdd' to '--with ads' * harbour/debian/control * updated note about supported platforms best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-02-04 09:31 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
have make_os2.cmd which is necessary for OS2 users - now they are using make_gnu.cmd from older Harbour versions or from xHarbour. Yes, unfortunately it means to update every such file in one more copy, which work will fall back to us, or they won't really be updated ever. This is true for make_*os2.cmd, bld.cmd, etc. If these were updated by the OS/2 users here (David?), I think they're okey, once we've agreed on the filenames. I'd suggest /make_gnu_os2.cmd which is uglier, but clearer IMO, since it also suggest we're talking about the GNU make system, not something fully separate OS/2 stuff. Long filenames, we already have. For the other batch file: /bin/bld_os2.cmd Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
I think we should rename the libs as they were and revert HB_GTI to GTI_. 1.0 RC should be usable by a beta3 user without any modification. To me, this is just resistance to change for the matter of past convenience. It's not a very compelling argument. Like all changes, soon this one will seem normal. For now, it will disturb a smaller number of people. If not changed, it will disturb a larger number of people for a longer time. Actually if I'd felt a stronger support for this matter, I'd have most probably moved these GTI_* #defines away to hbcompat.ch (or nowhere). Since I believe these don't belong to Harbour. Still, if we want to do this, I agree with Phil to do it rather now, than later, to have as small impact as possible for end users. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about stopping the release process?
Hi Przemek, So since it's unlike we'll have a 1.1 I think we should at least leave the lib names as they have been in the last 8 years and do a favor to poor users. It's also important argument though in fact there is a problem that we do not have compiler and linker wrapper which can work in non bash environment. Sth like hb* scripts which fully hides library names for end users so they will not notice any difference. Creating sth like that in C seems to be important. It would definitely be useful. HBMAKE has similar purpose, but it's a fully broken app. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OLE Implementation - xHarbour Compatibility
Hello Everybody Has anybody been able to use xHarbour's win32ole.prg in Harbour ? I am in a process of porting an huge application which is heavily based on Active-X's. The application takes advantage of FreeWin (SourceForge) library and hosts many objects. I am struck at hb_oleItemToVariant() and hb_oleVariantToItem() functions which is used in FreeWin's AxEv.c and are not available in Harbour. Can someone convert these function to honor Harbour API ? Thanks and regards Pritpal Bedi, INDIA-USA -- View this message in context: http://www.nabble.com/OLE-Implementation---xHarbour-Compatibility-tp15392521p15392521.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
