[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-11 Thread fs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673


User fs changed the following:

  What|Old value |New value

Status|RESOLVED  |VERIFIED





--- Additional comments from [EMAIL PROTECTED] Wed Jan 11 00:05:53 -0800 
2006 ---
verified in CWS dba202e

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-10 Thread fs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673


User fs changed the following:

  What|Old value |New value

OtherIssuesDependingOnThis|59674 |59674,60062

  Target milestone|OOo 2.0.3 |OOo 2.0.2





--- Additional comments from [EMAIL PROTECTED] Tue Jan 10 23:26:36 -0800 
2006 ---
Added this issue to CWS dba202e, which is targeted for 2.0.2.
Reason is that without the split, the fix for issue 60062 would need to be
duplicated: one time with splitted libs, one time without. To prevent this
duplication of work, I decided to fix both this issue here and issue 60062 in
one CWS.

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-10 Thread fs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673


User fs changed the following:

  What|Old value |New value

OtherIssuesDependingOnThis|59674,60062   |59674





-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-04 Thread fs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673


User fs changed the following:

  What|Old value |New value

Status|NEW   |RESOLVED

Issue type|DEFECT|TASK

Resolution|  |FIXED





--- Additional comments from [EMAIL PROTECTED] Wed Jan  4 03:37:45 -0800 
2006 ---
 basically, you want to alter the source code for the sake of pecular build
 environments.

Ehm, yes, in some sense. But given that our build environments are complex
enough (this does hold for both the SO and the OOo build env), I don't consider
this *per se* a Bad Thing.

 The source code will be more complex and perharps slower, just for building
 considerations. I feel this is Not Good (TM).

I don't believe in it being slower, except perhaps for the very first connection
attempt where the library has to be loaded. All subsequent calls should suffer a
very minmal penalty only, since instead of
  pConn = new KabConnection( this );
the code would be
  pConn = static_cast KabConnection* ( (m_pConnectionFactoryFunc*)( this ) );
, i.e. one additional re-direction through a function pointer.

More complex ... yes, slightly. But IMO still a cleaner architecture to separate
the UNO component (the mere driver) from the system-dependent implementation.


Since you did not have strong opposition :) against this, I implemented it in
CWS kabrefine. Changes are in connectivity/source/drivers/kab and scp2/source.

For the potential conflicts with CWS configure13: I will resync kabrefine once
configure13 is integrated, this will unveil the conflicts.

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-03 Thread fs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673


User fs changed the following:

  What|Old value |New value

  Target milestone|not determined|OOo 2.0.3





--- Additional comments from [EMAIL PROTECTED] Tue Jan  3 05:54:35 -0800 
2006 ---
targeting

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-03 Thread fs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673





--- Additional comments from [EMAIL PROTECTED] Tue Jan  3 01:29:04 -0800 
2006 ---
 Well, one could build for example OOo on a Redhat system with GNOME and no
 KDE. Am I correct if I say that it can happen exactly the same for OOo than
 for StarOffice?

In theory: yes. In practice: Such a scenario would require a faked build
environment on the GNOME system, similar to what Ause described for the SO build
env. There is no mechanism for this in place in the OOo build env (AFAIK), and
it's surely a non-trivial task to set it up, so I don't expect that tomorrow
some Linux distributor will come up with it :)

 4) A clean solution would be to split the KAB driver 
   a) Isn't that a generic problem of all drivers? 

Of all drivers which link to libraries which are not built in OOo itself. To my
best knowledge, this is the mozab driver (which already *is* split into two
libs), and now KAB.
Another driver which is potentially affected is the evoab2 driver, but this one
is currently not built for StarOffice (exactly because has a lot of dependencies
to Evolution libs, so it cannot be built on non-Evo systems. The original
authors did not address this, and I did not yet find time/priority to do so.)

   b) For which version would we target that? I have other bug reports 
  related to the KDE address book driver, so we could do that together 
  in one big CWS, although I suspect that splitting the
  might involve more work than the other bug reports. 
I want to do this in the next few days, this shouldn't be much of a problem,
hopefully. Finally, I've done it before for mozab :)

Shall I create a new CWS kabrefine?

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-03 Thread ebischoff
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673





--- Additional comments from [EMAIL PROTECTED] Tue Jan  3 04:14:55 -0800 
2006 ---
Thanks hjs and fs for the detailed explanations. 
 
To rephrase them, the purpose is to do cross-compilation from an environment 
that does not necessarily have everything at hand, to obtain a binary that 
could run in much richer environments. Tell me whether I got the point or 
missed it. 
 
I still feel uncomfortable with that from a principle point of view: 
basically, you want to alter the source code for the sake of pecular build 
environments. The source code will be more complex and perharps slower, just 
for building considerations. I feel this is Not Good (TM). 
 
Besides the fact that I do not like the approach of the problem, I have no 
strong opposition to it, if you do it yourself ;-). Just take care that Rene 
changed a few things to the driver in his configure13 CWS, so a conflict might 
arise between both CWS... 
 

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-02 Thread hjs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673





--- Additional comments from [EMAIL PROTECTED] Mon Jan  2 08:35:13 -0800 
2006 ---
1) it's quite unlikely to set ENABLE_KDE if there is no way to have access to it
2) here, KDE is supplied in a (shared) custom installation and not taken from
the system to have all developers use the same version - regardless of their
system. note that these libraries were used for linking up to now. with the
pre-registration of the KDE addressbook component, it is now required to have
the runtime linker find the whole bunch of KDE libraries for registering this
component only.
3) the main goal behind this is to have the build and the system seperated
to allow (build)-prerequisites to be supplied in a shared place and to have less
restrictions for the machines building with. increasing the runtime requirements
for the build itself makes this yet another bit harder ;)

leaving 4) for fs



-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2006-01-01 Thread ebischoff
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673





--- Additional comments from [EMAIL PROTECTED] Sun Jan  1 04:54:04 -0800 
2006 ---
1) Unfortunately, building StarOffice (as opposed to building OpenOffice.org)  
  
does not necessarily happen on a KDE system.
 
Well, one could build for example OOo on a Redhat system with GNOME and no
KDE. Am I correct if I say that it can happen exactly the same for OOo than
for StarOffice? (although I suspect that packagers at RedHat will use a build 
machine with every possible desktop environment on it). 

2) For the moment, this was fixed by hacking the installation-builder process  
 
so that the LD_LIBRARY_PATH also includes the KDE libs (thanks Ause).   
   
But you were saying that you were building on a non-KDE system? So how can it   
gain access to the KDE libs? Can you please elaborate a bit more?   
   
3) This hack is to be removed.  
  
I suppose that I need the answer to item 2) to understand why this hack is so  
bad. Or perharps you could explain a bit more here as well?  
  
4) A clean solution would be to split the KAB driver 
 
 a) Isn't that a generic problem of all drivers? 
 b) For which version would we target that? I have other bug reports 
related to the KDE address book driver, so we could do that together 
in one big CWS, although I suspect that splitting the driver library 
might involve more work than the other bug reports. 
 
  
Sorry for the newbye questions, but I am not very familiar with the StarOffice 
build process, as you may imagine... 
 

-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dba-issues] [Issue 59673] please split KAB SDBC dri ver library into two libs

2005-12-22 Thread fs
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=59673


User fs changed the following:

  What|Old value |New value

OtherIssuesDependingOnThis|  |59674





-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]