wxcode-users — Submission, Questions, Information

Re: [wxCode-users] bakefile problems with --enable-shared option

[Francesco M. <f18...@ya...>]

Ulrich Telle ha scritto:
> Hi Francesco,
> 
>> same here. The --enable-shared/--disable-shared options are simply 
>> ignored by wxCode component build systems (not only by wxsqlite3).
> 
> Interestingly the log messages of the configure tell exactly what the 
> user wants (static build of the wxCode component used with a shared 
> build of wxWidgets), only the generated makefile does not work like 
> expected.
> 
> It would be better if the configure script would complain about 
> mismatched options instead.
this should be already done: try to give --enable-shared --without-wxshared.

It doesn't complain on the opposite case since it should be allowed to 
give --disable-shared --with-wxshared; it's just that the bakefile part 
for the SHARED option is missing.

>> Currently the configuration you give to the configure script (using the 
>> --enable-debug,--enable-unicode,--with-wxshared options) or to the win32 
>> makefiles (using WX_DEBUG, WX_UNICODE, WX_SHARED) _must_ match the 
>> configuration of a wxWidgets build.
>>
>> I hope I cleared the issue :)
> 
> Well, yes, but I remember there was a discussion quite long ago 
> regarding exactly this issue, that is, building a wxCode component with 
> options not matching the used wxWidgets build options. And I thought the 
> WX_SHARED option was introduced just to solve this issue. But I may be 
> mistaken.
I think we discussed something similar (i.e. whether we should use as 
option names BUILD/SHARED/UNICODE as win32 wx makefiles do or rather 
WX_DEBUG/WX_SHARED/WX_UNICODE option names -- we decided for the 
latter)... but I don't think they we decided about coexistence of SHARED 
and WX_SHARED...

>> The question is: how useful is the ability to do a static build of a 
>> wxCode component against a shared build of wx?
>>
>> Under linux it may be useful: so that you can build an ELF 
>> self-contained _except_ for wx DLLs (or better "shared objects) which 
>> are included by deafult in almost all linux distro...
>>
>> What's your thoughts?
> 
> I'm a bit undecided. Up to now I myself have never used different build 
> options for wxCode components and wxWidgets itself, but if there are 
> users demanding this option I guess the wxCode components should offer 
> it if it's not too difficult to implement.
actually I tried to implement it and it results easier than I thought.

> If you decide to change the wxCode build system accordingly it should be 
> thoroughly tested before releasing any components using it. At least the 
> current version of the wxCode build system is stable.
sure. I have just committed updated version of wxCode bakefiles both to 
CVS and SVN.

I tested the changes with 'gnu' and 'autoconf' format for now and they 
works well. Before I proceed changing all wxCode bakefiles from

    <lib ... cond="WX_SHARED=='0'">
    <dll ... cond="WX_SHARED=='1'">

to:

    <lib ... cond="SHARED=='0'">
    <dll ... cond="SHARED=='1'">

I'd appreciate if other peoples tested the modified build system...

Francesco

Re: [wxCode-users] bakefile problems with --enable-shared option

[Ulrich T. <ulr...@gm...>]

Hi Francesco,

> same here. The --enable-shared/--disable-shared options are simply 
> ignored by wxCode component build systems (not only by wxsqlite3).

Interestingly the log messages of the configure tell exactly what the 
user wants (static build of the wxCode component used with a shared 
build of wxWidgets), only the generated makefile does not work like 
expected.

It would be better if the configure script would complain about 
mismatched options instead.

> Currently the configuration you give to the configure script (using the 
> --enable-debug,--enable-unicode,--with-wxshared options) or to the win32 
> makefiles (using WX_DEBUG, WX_UNICODE, WX_SHARED) _must_ match the 
> configuration of a wxWidgets build.
> 
> I hope I cleared the issue :)

Well, yes, but I remember there was a discussion quite long ago 
regarding exactly this issue, that is, building a wxCode component with 
options not matching the used wxWidgets build options. And I thought the 
WX_SHARED option was introduced just to solve this issue. But I may be 
mistaken.

> Now there are two solutions to fix this problem:
> 
> 1) remove from the configure.ac of all wxCode components the "wxshared" 
> option and leave only the "shared" option. Then set in the 
> WXCODE_OPTIONS macro WX_SHARED=$SHARED (just like it does for 
> WX_DEBUG=$DEBUG and WX_UNICODE=$UNICODE).
> This would mean that you can build your component only with a 
> combination of debug/unicode/shared settings matching an existing 
> wxWidgets build.

I think this is too restrictive. At least I know there are several users 
using a shared wxWidgets build but a static wxCode component build.

> 2) add to wxCode bakefiles the declaration of an option called "SHARED", 
> which can be used to build a wxCode component with SHARED!=WX_SHARED. So 
> that you can build your component in static mode against a shared build 
> of wxWidgets (the viceversa is not possible for linking reasons).
> 
> Then change in the bakefiles of all components the lines:
> 
>    <lib ... cond="WX_SHARED=='0'">
>    <dll ... cond="WX_SHARED=='1'">
> 
> to:
> 
>    <lib ... cond="SHARED=='0'">
>    <dll ... cond="SHARED=='1'">
> 
> Last, add the necessary modification to wxCode autoconf macros to handle 
> the SHARED option as a separed option from WX_SHARED.
 >
> Solution #2 is more difficult but I've already implemented it 
> successfully for wxLua a while ago, so that I could copy the required 
> portions of code.
> However it requires a change in all wxCode bakefiles and also makes them 
> somewhat less intuitive.
> 
> The question is: how useful is the ability to do a static build of a 
> wxCode component against a shared build of wx?
> 
> Under linux it may be useful: so that you can build an ELF 
> self-contained _except_ for wx DLLs (or better "shared objects) which 
> are included by deafult in almost all linux distro...
> 
> What's your thoughts?

I'm a bit undecided. Up to now I myself have never used different build 
options for wxCode components and wxWidgets itself, but if there are 
users demanding this option I guess the wxCode components should offer 
it if it's not too difficult to implement.

If you decide to change the wxCode build system accordingly it should be 
thoroughly tested before releasing any components using it. At least the 
current version of the wxCode build system is stable.

A third solution would be to change only the behaviour of the configure 
script, that is, it should reject mismatched shared/static options.

A user wishing to make a static build while using a shared wxWidgets 
build can always add the wxCode component's source files to his own project.

Regards,

Ulrich

[wxCode-users] bakefile problems with --enable-shared option

[Francesco M. <f18...@ya...>]

[sending this reply to wxcode-users, too]


Hi Ulrich, and all wxCode devs,

Ulrich Telle ha scritto:
> Although the option --enable-shared=no (or --disable-shared) is 
> specified when running ./configure running make does not build wxSQLite3 as a 
> static library but as a shared library.
same here. The --enable-shared/--disable-shared options are simply 
ignored by wxCode component build systems (not only by wxsqlite3).

I'm not sure when this bug was introduced (I tried to search in the 
CVS/SVN history without success)... but I'm sure it worked originally.

> Is there anything wrong with my bakefile?
there's nothing wrong with your bakefile... however I've found that the 
problem is deeper. The fact is that your component (like all other 
wxCode components! I've checked this!) uses

WXCODE_OPTIONS([debug,unicode,shared,toolkit,wxshared,wxversion])

in the configure.ac i.e. specifies not only wxshared but also "shared" 
option. This is wrong. In fact, there's no SHARED option declared in the 
wxCode bakefile or in your component's bakefile.

wx autoconf macros and wx bakefile presets in fact are affected only by 
the value of WX_SHARED (the --with-wxshared option in fact works as 
intended).

This is confirmed also by the fact that the components' win32 makefiles 
do not show any SHARED option. I.e. in the way the wxCode presets are 
currently written, there's no way (both on Windows and on Unix) to build 
a static version of a component against a shared build of wxWidgets.

Currently the configuration you give to the configure script (using the 
--enable-debug,--enable-unicode,--with-wxshared options) or to the win32 
makefiles (using WX_DEBUG, WX_UNICODE, WX_SHARED) _must_ match the 
configuration of a wxWidgets build.

I hope I cleared the issue :)

Now there are two solutions to fix this problem:

1) remove from the configure.ac of all wxCode components the "wxshared" 
option and leave only the "shared" option. Then set in the 
WXCODE_OPTIONS macro WX_SHARED=$SHARED (just like it does for 
WX_DEBUG=$DEBUG and WX_UNICODE=$UNICODE).
This would mean that you can build your component only with a 
combination of debug/unicode/shared settings matching an existing 
wxWidgets build.

2) add to wxCode bakefiles the declaration of an option called "SHARED", 
which can be used to build a wxCode component with SHARED!=WX_SHARED. So 
that you can build your component in static mode against a shared build 
of wxWidgets (the viceversa is not possible for linking reasons).

Then change in the bakefiles of all components the lines:

   <lib ... cond="WX_SHARED=='0'">
   <dll ... cond="WX_SHARED=='1'">

to:

   <lib ... cond="SHARED=='0'">
   <dll ... cond="SHARED=='1'">

Last, add the necessary modification to wxCode autoconf macros to handle 
the SHARED option as a separed option from WX_SHARED.


I'm unsure about the right way to proceed.
Solution #1 is the simplest one and it's a "safe" route (very easy to 
implement). Basically it avoids added complexity to wxCode build system 
at the cost of excluding the build possibility: wx shared + wxCode comp 
static.

Solution #2 is more difficult but I've already implemented it 
successfully for wxLua a while ago, so that I could copy the required 
portions of code.
However it requires a change in all wxCode bakefiles and also makes them 
somewhat less intuitive.

The question is: how useful is the ability to do a static build of a 
wxCode component against a shared build of wx?

Under linux it may be useful: so that you can build an ELF 
self-contained _except_ for wx DLLs (or better "shared objects) which 
are included by deafult in almost all linux distro...

What's your thoughts?

Francesco



-- 

Re: [wxCode-users] Database encryption

[Ulrich T. <Ulr...@gm...>]

Hi Chong,

> I am not living in United States. Would there be any issue if the
> encryption implementation is included in the software product to
> be market worldwide including United States?

I don't see any such issues if you are using the encryption implementation as an integral part of your product to protect your database against manipulation from outside your application. It might depend on the kind of product you have in mind, though. If the purpose of your product is legal, you're certainly on the safe side. But as said before I'm not a lawyer.

Regards,

Ulrich

Re: [wxCode-users] Database encryption

[Chong T. S. <tie...@my...>]

Hi Ulrich,

Thanks for the information.

I am not living in United States. Would there be any issue if the encryption
implementation is included in the software product to be market worldwide
including United States?

Thanks.

Regards,
Chong

-----Original Message-----
From: wxc...@li...
[mailto:wxc...@li...] On Behalf Of Ulrich Telle
Sent: Wednesday, July 09, 2008 4:37 PM
To: wxc...@li...
Subject: Re: [wxCode-users] Database encryption

Hi,

> I am interested in the database encryption implementation in wxSQLite3.
> It is using 128 bit AES.
> 
> Does this falls under EAR (Export Administration Regulations)?
> 
> Is there ECCN number to export or use in Japan?

I'm not a lawyer but to the best of my knowledge this software does not fall
under the regulation of the Wassenaar agreement of the European Union since
it is free open source software.

But if you live in the United States and want to export products using this
software you may require a specific license from the United States
Government. It would be your responsibility to obtain such a license before
exporting.

Regards,

Ulrich

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
wxCode-users mailing list
wxC...@li...
https://lists.sourceforge.net/lists/listinfo/wxcode-users

Re: [wxCode-users] Database encryption

[Ulrich T. <Ulr...@gm...>]

Hi,

> I am interested in the database encryption implementation in wxSQLite3.
> It is using 128 bit AES.
> 
> Does this falls under EAR (Export Administration Regulations)?
> 
> Is there ECCN number to export or use in Japan?

I'm not a lawyer but to the best of my knowledge this software does not fall under the regulation of the Wassenaar agreement of the European Union since it is free open source software.

But if you live in the United States and want to export products using this software you may require a specific license from the United States Government. It would be your responsibility to obtain such a license before exporting.

Regards,

Ulrich

[wxCode-users] Database encryption

[Chong T. S. <tie...@my...>]

Hi all,

 

I am interested in the database encryption implementation in wxSQLite3. It is
using 128 bit AES.

 

Does this falls under EAR (Export Administration Regulations)?

 

Is there ECCN number to export or use in Japan?

 

Thanks.

 

Regards,

Chong

 

 

 

ChongTien-Sen

 

Communication Development Centre

Panasonic R&D Centre Malaysia Sdn. Bhd.

' Tel : 603-8318-1228  Ext: 129

* Fax : 603-8318-1226

* Email : tie...@my...

 

This e-mail and any attachments are intended only for the use of the
individual or entity named above and may contain information that is
confidential and privileged. If you are not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify PRDCM immediately by return e-mail or telephone the above
number and destroy the original message

 

Re: [wxCode-users] from where to get wxPlotCtrl and wxThings

[John L. <jla...@gm...>]

On Sun, May 18, 2008 at 3:08 PM,  <fa...@gm...> wrote:
> Hello,
>
> from where can I download recent stable version of wxPlotCtrl and wxThings ?
> Is a newer tarball availiable than from sourceforge (there it is from
> 2006-04-27) ?
>
> Or does anybody have a complete cvs address incl. revision for me to c/o these
> packets ?

You can browse it here
http://wxcode.cvs.sourceforge.net/wxcode/wxCode/components/wxplotctrl/

or check it out using these directions
http://sourceforge.net/cvs/?group_id=51305

cvs -z3 -d:pserver:ano...@wx...:/cvsroot/wxcode
co -P modulename
cvs -z3 -d:pserver:ano...@wx...:/cvsroot/wxcode
co wxCode/components/wxplotctrl


Someday... when I get some free time I should make another release.


Regards,
    John

Re: [wxCode-users] wxCode Wiki Plea

[Francesco M. <f18...@ya...>]

[sending this reply also to wxcode-users]

Charles Brockman ha scritto:
> Message body follows:
> 
> Francesco -
> 
> Could you or some other wxCode administrator activate the
> AuthUser system in the wxCode Wiki?
> (http://www.pmwiki.org/wiki/PmWiki/AuthUser) Many pages have
> been defaced and much content removed.
> 
> More people would maintain the Wiki if they thought it that
> the spammers wouldn't destroy their work.
right. However my free time is very limited and will be even more in the 
future... I think that since wxCode wiki is not much used in any case, 
we should switch to use the SF-provided wiki (so that we have not to 
care about wiki backups/maintainance anymore). Then we could give all 
maintainers the rights to edit the pages and lock them for outsiders.

If noone objects I'll move the main pages of our current pmWiki to SF 
wiki in the next week and will add those protection features against SPAM.

Francesco


-- 

Re: [wxCode-users] News item at wxCode web site

[Francesco M. <f18...@ya...>]

Hi,
  sorry for the delay with this reply... I'm quite busy now.

Arne Steinarson ha scritto:
> As seen from previous email, an update of the wxRL component.
> 
> Is there some way of generating a small news item at the wxCode web site?
Sure, just go to the project page of wxCode and submit a new "news item".

The website will then "automatically" be updated to reflect the news in 
a few days.

Francesco

[wxCode-users] News item at wxCode web site

[Arne S. <ast...@gm...>]

Hello [Francesco],

As seen from previous email, an update of the wxRL component.

Is there some way of generating a small news item at the wxCode web site?

Regards
// ATS.

[wxCode-users] wxRecursiveLayout - Release 0.6

[Arne S. <ast...@gm...>]

Hello,

The wxRL (rlayout) component at wxCode has been updated. ReadMe and
change notes below.

Regards
Arne steinarson

-----------------------------------------------------------

wxRL ReadMe
-------------

Website: http://wxcode.sourceforge.net/components/rlayout
Author: Arne Steinarson
Version: 0.6


Intro:
------
wxRecursiveLayout is a window layout manager for top-level windows, child
windows, panels and dialogs. It uses general sizing / area packing algorithms,
and as such, does not enforce a central 'document' area. Support for window
panes, toolbars, dragging panes & toolbars, floating and docking,
saving/loading
layouts (aka perspectives). It is very flexible in terms of what layouts it
permits. It also provides a light-weight class for drawing customized window/
tool decorations and borders.


Version:
--------
0.6, running on Linux & Win32 (and hopefully MacOS-X)


Requirements:
-------------
Requires wxWidgets >-2.8.5
Tested with wxMSW and wxGTK. No platform specific features so it should
be straight forward to build for other desktop platforms. If you do,
please inform me.

NOTE: wxRL builds straight with wx2.9 (from SVN). For wx2.8.x one will
have to integrate object tracking (C++ weak references) into the wx build
manually. The files are: {wx/tracker.h wx/weakref.h, wx/meta/int2type.h,
wx/meta/convertible.h}. Also, wxWrapSizer should be built with wxWidgets
(or the project).


License:
--------
Free to use in open source / educational / non commercial projects. If
used in any commerical context, please contact the author for terms.


Changes:
--------
Version 0.6 adds bug fixes and enhancements from around six months of
development.

- Layout handling for dialogs is much improved with wxRlDialog1.
  Layouts can change size dynamically as parts of it are expanded,
  contracted. The dialog minimum size wil track that of contained
  items.

- It now uses weak references internally to eliminate any
  possibilty of dangling pointers to layout items.

- A loop blocker prevents the possibility of 'mutual layout update
  loops' (can happen due to rounding errors when handling NoteBook
  pages and in similar situations [nested size tracking]).

- The layout script language (XML) has been expanded (grid, flexgrid
  and wrap sizers are now supported).

- Better support for querying types and capabilities from child and
  parent items (GetParentWithType, GetChildWithCapab, ...).

- Build system. Simplified and removed some un-needed dependencies.

- Stability. A large number of minor bugs and improvements.


Building:
---------
There are two ways of building wxRL and the samples in this package.

1 - Using CMake.
Let CMake generate IDE or makefiles. Then use the IDE or 'make'to build
the programs.

2 - With the hand written makefiles that are in the samples directory.
These makefiles have been tested under Linux and Windows (mingw GCC).
Some editing is needed to get it to run on other systems. See readme.txt
in the build directory.


Author:
-------
Arne Steinarson. Questions, bug-reports and suggestions to:
   asteinarson at gmail dot com

[wxCode-users] components recently moved to SVN

[Francesco M. <f18...@ya...>]

Hi,
    I forgot to ask to all developers which had their component(s) moved 
to SVN to update the wxCodeDB going to: 
http://wxcode.sourceforge.net/edit.php

Please update for all your components the "Repository" field setting it 
to "Subversion".

Otherwise you'll get a monthly reminder about the fact that your 
component has no sources in the wxCode repo.

Thanks,
Francesco

[wxCode-users] Cron job: there are 4 empty components

[Francesco M. <fr...@us...>]

[automated message for informative purposes].

>From an heuristic check it results that 4 components have no sources in the CVS/SVN; here follows the list of these components and the relative maintainers:
wxSQLite3, maintainer: Ulrich Telle
wxAudio, maintainer: Ryan Norton
wxActiveRecordGenerator, maintainer: mszeftel
wxXmlSerializer, maintainer: MichalBliznak

The relative maintainers have already been notified by mail of this issue.

Your friendly wxCode script.

[wxCode-users] Cron job: wxCoolBar is pending approval

[Francesco M. <fr...@us...>]

name: wxCoolBar
wxversion: all
category: window container,control,window layout,wrapper
language: cpp
description: wxCoolBar is a wrapper around the mickeysoft rebar control for use with the famous wxWidgets gui library. So developers can easily add the nice looking toolbars known from ms ie or other applications to their existing wxWidgets apps. Only if compiled against wxMSW on Win > 95 of course.
location: coolbar
cdate: 2005-04-08
id: 119
status: beta
docs: hand
buildsys: makefiles
extdep: none
wiki: disabled
wxport: wxmsw
samples: 1
approved: 0
author: Martin Simon
version: 0.9
inCVS: 1
maintainerid: 43

Maintainer SF username: martinsfromb
Maintainer name: MartinSfromB
Maintainer mail address: mar...@pl...

[wxCode-users] Cron job: wxDom is pending approval

[Francesco M. <fr...@us...>]

name: wxDom
wxversion: 2.6
category: data container,text processing
language: cpp
description: This is a modification of wxXML that allows loading from a File, URL, or XML String. Also allows dumping the Dom to String insted of just saving it to a file. I changed the class names, and some of the function names soas to not conflict with wxXML. 
location: wxdom
cdate: 2006-09-20
id: 102
status: beta
docs: notavailable
buildsys: projectfiles
extdep: none
wiki: enabled
wxport: all
samples: 0
approved: 0
author: Vaclav Slavik
version: 1.0
inCVS: 1
maintainerid: 24

Maintainer SF username: Digitalxero
Maintainer name: Dj Gilcrease
Maintainer mail address: dig...@us...

[wxCode-users] [ wxcode-Bugs-1944584 ] Linkiing problem

[SourceForge.net <no...@so...>]

Bugs item #1944584, was opened at 2008-04-16 21:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462816&aid=1944584&group_id=51305

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: wxpdfdoc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linkiing problem

Initial Comment:
An application witch has the library made from wxpdfdoc
has error of link after compilation

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462816&aid=1944584&group_id=51305

[wxCode-users] Cron job: wxCoolBar is pending approval

[Francesco M. <fr...@us...>]

name: wxCoolBar
wxversion: all
category: window container,control,window layout,wrapper
language: cpp
description: wxCoolBar is a wrapper around the mickeysoft rebar control for use with the famous wxWidgets gui library. So developers can easily add the nice looking toolbars known from ms ie or other applications to their existing wxWidgets apps. Only if compiled against wxMSW on Win > 95 of course.
location: coolbar
cdate: 2005-04-08
id: 119
status: beta
docs: hand
buildsys: makefiles
extdep: none
wiki: disabled
wxport: wxmsw
samples: 1
approved: 0
author: Martin Simon
version: 0.9
inCVS: 1
maintainerid: 43

Maintainer SF username: martinsfromb
Maintainer name: MartinSfromB
Maintainer mail address: mar...@pl...

[wxCode-users] Cron job: wxDom is pending approval

[Francesco M. <fr...@us...>]

name: wxDom
wxversion: 2.6
category: data container,text processing
language: cpp
description: This is a modification of wxXML that allows loading from a File, URL, or XML String. Also allows dumping the Dom to String insted of just saving it to a file. I changed the class names, and some of the function names soas to not conflict with wxXML. 
location: wxdom
cdate: 2006-09-20
id: 102
status: beta
docs: notavailable
buildsys: projectfiles
extdep: none
wiki: enabled
wxport: all
samples: 0
approved: 0
author: Vaclav Slavik
version: 1.0
inCVS: 1
maintainerid: 24

Maintainer SF username: Digitalxero
Maintainer name: Dj Gilcrease
Maintainer mail address: dig...@us...

[wxCode-users] wxCurl Stuff (Was: CVS to SVN reprise)

[Casey O'D. <cas...@gm...>]

On Tue, Mar 18, 2008 at 3:15 PM, Francesco Montorsi
<f18...@ya...> wrote:
> Casey O'Donnell ha scritto:
>
> > I'm happy to have wxCurl move over to SVN.
>  actually wxCurl is already in wxCode SVN :)

Hahaha... Super then. I remember this now, looking at my directory.

>  I'd really like to make the first release but I never managed to fix
>  that Unicode/ANSI problem; also since this is a thing which deeply
>  changed in new wx3 / upcoming wx2.9, probably it's worth doing the
>  release once 2.9.0 is out and make it compatible with wx >= 2.9

Sounds like a plan. We should also add a download package.

Best.
Casey

-- 
Casey O'Donnell
RPI STS Department - PhD Candidate

http://homepage.mac.com/codonnell/

Re: [wxCode-users] CVS to SVN reprise

[Ulrich T. <ulr...@gm...>]

Bryan Petty schrieb:
> It might be possible that you'll need to delete your files, and check
> them out again in order for the change to be evident on your machine.
> I don't think TortoiseSVN (or SVN itself) would modify your existing
> files.

Yes, deleting the files in my working copy and restoring them via SVN 
update did the trick.

Thanks a lot!

Regards,

Ulrich

Re: [wxCode-users] CVS to SVN reprise

[Bryan P. <br...@ib...>]

On 3/19/08, Ulrich Telle <ulr...@gm...> wrote:
>
>  enable-auto-props = yes
>
>  [auto-props]
>  *.c = svn:eol-style=native
>  *.cpp = svn:eol-style=native
>  *.h = svn:eol-style=native
>  ...

Yes, this should add that property to those files automatically when
you 'svn add' them.

> Since Francesco moved the files from CVS to SVN, all files exist already
>  in SVN. Where do I have to set the property? I tried to add the property
>  manually for one source file, but the line ending did not change.

It might be possible that you'll need to delete your files, and check
them out again in order for the change to be evident on your machine.
I don't think TortoiseSVN (or SVN itself) would modify your existing
files.

Regards,
Bryan Petty

Re: [wxCode-users] CVS to SVN reprise

[Ulrich T. <ulr...@gm...>]

Bryan Petty schrieb:
> When you say that you "enabled native line endings in TortoiseSVN",
> what exactly do you mean?

I added/activated the following lines in TortoiseSVN:

enable-auto-props = yes

[auto-props]
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.h = svn:eol-style=native
...

> You will need to set the "svn:eol-style" property on all files that
> you want to change the behavior for. You can setup TortoiseSVN to set
> that property by default on all files of certain kinds, but it won't
> set those properties if the file already exists in SVN. You'll need to
> add the property to those files by hand.

Since Francesco moved the files from CVS to SVN, all files exist already 
in SVN. Where do I have to set the property? I tried to add the property 
manually for one source file, but the line ending did not change.

Regards,

Ulrich

Re: [wxCode-users] CVS to SVN reprise

[Bryan P. <br...@ib...>]

On 3/18/08, Ulrich Telle <ulr...@gm...> wrote:
>  As I'm quite new to SVN I need a bit of advice. As you know I work
>  mainly on a Windows platform. Although I enabled native line endings in
>  the TortoiseSVN settings I got all my source files with Unix line
>  endings when I checked out my wxCode components. How can I accomplish to
>  get Windows line endings? What happens, when I add new files having
>  Windows line endings? Are they converted correctly when committed to SVN?

When you say that you "enabled native line endings in TortoiseSVN",
what exactly do you mean?

You will need to set the "svn:eol-style" property on all files that
you want to change the behavior for. You can setup TortoiseSVN to set
that property by default on all files of certain kinds, but it won't
set those properties if the file already exists in SVN. You'll need to
add the property to those files by hand.

Regards,
Bryan Petty

Re: [wxCode-users] CVS to SVN reprise

[Ulrich T. <ulr...@gm...>]

Hi Francesco,

Francesco Montorsi schrieb:
>> ... So I'd like to ask you for adding my components
>>
>> wxsqlite3
>> wxpdfdoc
>>
>> to SVN. Thanks.
> done!


Thanks.

As I'm quite new to SVN I need a bit of advice. As you know I work 
mainly on a Windows platform. Although I enabled native line endings in 
the TortoiseSVN settings I got all my source files with Unix line 
endings when I checked out my wxCode components. How can I accomplish to 
get Windows line endings? What happens, when I add new files having 
Windows line endings? Are they converted correctly when committed to SVN?

Regards,

Ulrich