570373 - Remove library search paths from the project

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Stuart noticed the other night that we still have a bunch of library search paths specified in the project, rather than the xcconfig; once all the duplicates are removed and dead paths are pruned, we ought to be able to move the remaining ones into the xcconfig.

(Xcode will still keep trying to add them whenever you add a core lib, but it should be easy enough to catch in review.)

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If I haven't screwed anything up, our library search paths after bug 570361 should be like this:

All:

../dist/bin/
../staticlib/

../embedding/base/ (libembed_base_s.a)
../profile/dirserviceprovider/src/ (libprofdirserviceprovider_s.a)

Shared only:

../dist/bin/components/

Static only:

../dist/lib/ (libcrmf.a, libmozz.a, libmozqcms.a)
../staticlib/components/

../gfx/cairo/cairo/src/ (libmozcairo.a)
../gfx/cairo/libpixman/src/ (libmozlibpixman.a)
../jpeg/ (libmozjpeg.a)
../modules/libimg/png/ (libmozpng.a)

The .xcconfig currently only has ../dist/bin and ../dist/lib http://mxr.mozilla.org/camino/source/config/Camino.xcconfig#16

I assume there's no reason we can't just list all of these there.

We currently have 6 sets of library search paths in the project:

History-Debug+Release: ../dist/lib

Camino-Debug+Release: ../embedding/base, ../dist/bin, ../dist/lib,../dist/bin/components, ../profile/dirserviceprovider/src, ../db/morkreader, ../staticlib/components,

CaminoStatic-Debug+Release: "$(LIBRARY_SEARCH_PATHS)", ../staticlib, ../staticlib/components, ../embedding/base, ../js/src/liveconnect, ../js/src/xpconnect/loader, ../jpeg, ../modules/libimg/png, ../gfx/cairo/cairo/src, ../gfx/cairo/libpixman/src, ../profile/dirserviceprovider/src, ../dist/bin/components, ../db/morkreader,

I'm not sure what History is looking for in ../dist/lib; I think it's the last prefPane still using Gecko (bug 410030).  If we can eliminate this entirely, that would be great, but otherwise setting those to "$(LIBRARY_SEARCH_PATHS)" seems good.

For the four Camino combinations, the only ../js/src/xpconnect/loader and ../js/src/liveconnect are not in the current list.

xpconnect/loader dates from http://hg.mozilla.org/camino/rev/eb233b6aada6 ("Landing changes from CHIMERA_M1_0_1_BRANCH. (I know I'm breaking the static build, I'll fix it later). Code depending on other Mozilla changes is #ifdef'd BRANCH_CHANGES_NEED_MERGED. "), presumably from adding the now-long-gone ../js/src/xpconnect/loader/libjsloader.a

liveconnect dates from http://hg.mozilla.org/camino/rev/624499debacb ("Landing the changes for Chimera static builds (not on by default).").  Since libjsj.a is what comes out of liveconnect, and we've moved it to a standard path, I think we're fine to remove this library search path.

Stuart, is there any reason not to dump the whole lot of these (minus xpconnect and live connect) into the .xcconfig and replace them with "$(LIBRARY_SEARCH_PATHS)" in the project file?

And what about History?  Is it looking for the xpcom libs (which the rest of the project has been referencing from ../dist/bin)?  Is it OK to move History over to "$(LIBRARY_SEARCH_PATHS)", too, or should we just leave it be/move it to dist/bin (and, regardless, make a note somewhere to clean up its project section after it no longer is a Gecko consumer)?

Comment 2

[Stuart Morgan]

History is looking for libxpcom_core.dylib; it should have whatever the right place to find that is. Given that it's a temporary anomaly, I'd rather leave it defined for the target until it's removed. The alternatives: putting it PrefPane where it will affect all the pref pane targets, or making History use a new, different xcconfig, are uglier.

As for the rest, I'd rather not have one big blob when there really are two distinct groups. My vote would be to separate the groups in the xcconfig:

CORE_LIBRARY_SEARCH_PATHS: <your All section>
SHARED_LIBRARY_SEARCH_PATHS: <your Shared section>
STATIC_LIBRARY_SEARCH_PATHS: <your Static section>

Then set the targets to:
$(CORE_LIBRARY_SEARCH_PATHS) $(SHARED_LIBRARY_SEARCH_PATHS)
and
$(CORE_LIBRARY_SEARCH_PATHS) $(STATIC_LIBRARY_SEARCH_PATHS)


For the paths that are dead, definitely remove them. If we still need them, we'll find out real fast ;)

Comment 3

[Stuart Morgan]

To capture from IRC, COMMON_ is probably a better prefix than CORE_ to avoid meaning overload.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Implements said plan

This implements the plan; my, doesn't that look cleaner! ;)

CaminoApp, CaminoStaticApp, and History successfully relink with the patch.

(Stuart, when this lands, it should merge with your project changes for autocomplete without problem, since they're touching different parts of the file.)

Comment 5

[Stuart Morgan]

Comment on attachment 476595 [details] [diff] [review]
Implements said plan

sr=smorgan

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

http://hg.mozilla.org/camino/rev/8af15dced012