exchndl related patch because win32/lib folder is empty in SVN

[stahta01]

By inspecting the build log?

That a lot of work for very little gain.

I will let you all to continue to waste time that way if you wish.

Tim S.

[MortenMacFly]

I thought being in separate folders would be enough; if you wish I can add the suffixes back.
Do you wish me to to that?

Oh - maybe I misunderstood the folder structure then. If they are in separate folders it would be fine... Maybe I should apply the interim patch and see myself. I just waited because you said there would be an update...

[MortenMacFly]

Also do we need to have such complex file structure in the libs folder?
Why don't you flatten or at least group libs by purpose - sdk and plugins for example.

I can flatten if you want me to; but, it seemed safer to keep them in separate folders.

I don't know if complete flattening is good. Third party libs may be needed in different versions (as the bzip lib, for example). So if the folders are "too flat" you would probably overwrite a library with a wrong version which is bad. Every target (being plugin or SDK) should have an own folder to cope with such.

[stahta01]

I thought being in separate folders would be enough; if you wish I can add the suffixes back.
Do you wish me to to that?

Oh - maybe I misunderstood the folder structure then. If they are in separate folders it would be fine... Maybe I should apply the interim patch and see myself. I just waited because you said there would be an update...

OK, I will remove the 30/64 once more.

Tim S.

[stahta01]

Also do we need to have such complex file structure in the libs folder?
Why don't you flatten or at least group libs by purpose - sdk and plugins for example.

I can flatten if you want me to; but, it seemed safer to keep them in separate folders.

I don't know if complete flattening is good. Third party libs may be needed in different versions (as the bzip lib, for example). So if the folders are "too flat" you would probably overwrite a library with a wrong version which is bad. Every target (being plugin or SDK) should have an own folder to cope with such.

I will add back the contrib folders; but, NOT the sdk and base folders.

Tim S.

[stahta01]

Still building several contrib projects; wxContribItem and wxSmith are the main ones to change output below:

Code Select Expand


$ tree src/lib
src/lib
|-- contrib
|   |-- SpellChecker
|   |   |-- libhunspell.a
|   |   `-- libwxSpellChecker.a
|   |-- devpak_plugin
|   |   `-- libbz2.a
|   |-- help_plugin
|   |   |-- libbzip2.a
|   |   `-- libz.a
|   |-- source_exporter
|   |   `-- libwxPdfDocument.a
|   `-- wxSmithPlot
|       `-- libMathPlot.a
|-- libcodeblocks.a
|-- libdepslib.a
|-- libsqplus.a
|-- libsqstdlib.a
|-- libsquirrel.a
|-- libtxml.a
|-- libwxchartctrl.a
|-- libwxflatnotebook.a
|-- libwxpropgrid.a
`-- libwxscintilla_cb.a

6 directories, 17 files


Tim S.

[stahta01]

MortenMacFly: Link to updated patches. Tried PM, also.

https://github.com/stahta01/cb_misc/tree/master/Patches/Git-am

[oBFusCATed]

I don't know if complete flattening is good. Third party libs may be needed in different versions (as the bzip lib, for example). So if the folders are "too flat" you would probably overwrite a library with a wrong version which is bad. Every target (being plugin or SDK) should have an own folder to cope with such.

Keep in mind that this will lead to a disaster if it happens on linux!
There we are building with every symbol being visible. Which means that the first symbol named X to load wins and will be called, no matter if the code is expecting the other symbol. This is named symbol collision and it is pretty bad.

Why are there two different bzip implementations? As far as I can see they are named differently (bz2 and bzip2). Are they the same thing? Same API?

[stahta01]

I don't know if complete flattening is good. Third party libs may be needed in different versions (as the bzip lib, for example). So if the folders are "too flat" you would probably overwrite a library with a wrong version which is bad. Every target (being plugin or SDK) should have an own folder to cope with such.

Keep in mind that this will lead to a disaster if it happens on linux!
There we are building with every symbol being visible. Which means that the first symbol named X to load wins and will be called, no matter if the code is expecting the other symbol. This is named symbol collision and it is pretty bad.

Why are there two different bzip implementations? As far as I can see they are named differently (bz2 and bzip2). Are they the same thing? Same API?

I have no idea why there is  two different bzip implementations; will check in the furture about why.

Here's the layout I am trying to use in Linux; still have a ways to go before the patch is ready.
Any reasons why this layout is bad? Or ways to improve it?

Code Select Expand


$ tree src/lib src/lib28 src/lib30
src/lib
+-- contrib
|   +-- help_plugin
|       +-- libbzip2.a
|       +-- libz.a
+-- libdepslib.a
+-- libsqplus.a
+-- libsqstdlib.a
+-- libsquirrel.a
+-- libtxml.a
src/lib28
+-- contrib
|   +-- source_exporter
|   |   +-- libwxPdfDocument.a
|   +-- SpellChecker
|       +-- libwxSpellChecker.a
+-- libwxscintilla_cb.a
src/lib30
+-- contrib
|   +-- source_exporter
|   |   +-- libwxPdfDocument.a
|   +-- SpellChecker
|       +-- libwxSpellChecker.a
+-- libwxscintilla_cb.a

8 directories, 13 files


Tim S.

[oBFusCATed]

One thing for sure - don't build or use libz.a. We should use the system provided version on linux!

[stahta01]

One thing for sure - don't build or use libz.a. We should use the system provided version on linux!

Thanks, that is the type of feedback I need.
FYI: I do NOT think I added building of libz.a; so, it might be that way in trunk.

Tim S.

[oBFusCATed]

Yes, it is that way but this should be fixed. The zlib stuff should be removed from unix projects (hopefully osx has libz).

[MortenMacFly]

Yes, it is that way but this should be fixed. The zlib stuff should be removed from unix projects (hopefully osx has libz).

I think it is. These libs are only for Windows, where bz2 and zlib are not guaranteed to be shipped with the compiler.

For the record: BZIP and ZLIB are used in the devpacks and help plugin.

I've updated the sources in SVN so that they use the same (up-to-date) versions of the lib.

[MortenMacFly]

For the record: BZIP and ZLIB are used in the devpacks and help plugin.

Oh well, we have another location: The wxSpellChecker uses bzlib2, too... :-/ Its now the same version, but is looks like this lib should be put into the core...