there is no easy way to split it.  It shouldn't be a problem for eclipse builds as it's not only problem with swt but with every other jar in the platform.
Also swt.jar is installed in %{_jnidir}/swt.jar which can be used for non-eclipse builds. Is this sufficient or I misunderstood the problem? If there is still a problem please give a concrete example.

As per comments in https://fedorahosted.org/fpc/ticket/161:

> It is fine to use %{_libdir} for its intended purpose at build-time of noarch packages. It would be very wrong to use it for other than its intended purpose.

> Correct usage in a noarch package could be something like this:

> # We link against libeclipse.so at build time. # At runtime, /usr/bin/eclipse has already loaded the correct version for our arch sed -i 's!/usr/lib/eclipse/libeclipse.so.1!%{_libdir}/eclipse/libeclipse.so.1!g' Makefile

> Incorrect usage in a noarch package could be something like this:

> # We install into the eclipse directory sed -i 's!INSTALLDIR=/usr/lib/eclipse/plugins/!INSTALLDIR=%{_libdir}/eclipse/plugins/!'"

And:

>> The problem that we observed was that during noarch buildtime, for some reason, %{_libdir} did not pointed to the proper Eclipse installation. We guessed that it is %{_libdir} failing to point to an appropriate Eclipse location.

>This would be incorrect.

The last point is that libdir macro should always work, in arch and noarch builds.

I took an eclipse plugin (swt-chart) that I know uses %{_eclipse_base} and replaced it's useage with %{_libdir}/eclipse.
(See http://pkgs.fedoraproject.org/cgit/swt-chart.git/tree/swt-chart.spec?id=86982257644f4d0def91a6ecc008eb9184cc9b14#n39)

I did a scratch build with this change, and made sure to hit an x86_64 machine. The result clearly shows that %{_libdir} is resolving to /usr/lib. http://kojipkgs.fedoraproject.org//work/tasks/7321/4377321/build.log.

Am i missing something ? I remember when I tested out the macro, I made sure to hit both primary arch types (x86 and x86_64). For some time now, %{_eclipse_base} has hit both arch types and been able to resolve.

I have opened clarfication request: https://fedorahosted.org/fpc/ticket/203.
Let's sort this out.

Summary of the trac ticket:
It would be the best to not use arch macros in a noarch packages at all.
If it is not possible, then it would be good to have the macro expanded at Eclipse build time. 

The question is: in how many projects do we really use %{_eclipse_base} ?

I agree with the suggestion made in the ticket. It should work the same way if just expanded at eclipse's build-time.

Tycho needs to use the bundles in eclipse's libdir as part of the target platform when resolving dependencies. This means any noarch package using Tycho for a build doesn't have to worry about it. On the other hand, jfreechart (http://pkgs.fedoraproject.org/cgit/jfreechart.git) currently uses %{_libdir}/java/swt.jar in the ant build, and so the macro would solve their current issue.

The ticket evolved into:

"Noarch packages must not use %{_libdir} (or any macro
 that contains the literal string "%{_libdir}" in its expansion), since the
 %{_libdir} macro has no useful value in noarch build environments."

"As an exception to this rule, noarch packages may use %configure (which
 uses %{_libdir} to set the --libdir value), but packagers should be very
 careful to ensure that the build/install logic does not actually use this
 value for anything."

The suggested solution for jfreechart is:
 {{{
  ant -f ant/build-swt.xml \
 -         -Dswt.jar=%{_libdir}/java/swt.jar \
 +         -Dswt.jar=$(build-classpath swt) \
          -Djcommon.jar=$(build-classpath jcommon) \
          -Djfreechart.jar=lib/jfreechart-%{version}.jar
 }}}

Is there any other case where we need %{_eclipse_base} ?

There's only other cases I can think of :

1) eclipse plugins that use pdebuild (Ideally they should all move to using maven/tycho but perhaps upstream doesn't support this yet?)

I'm not sure how many examples there are, but eclipse-vrapper (currently ftbfs for f18,f19) seems to define '%global eclipse_base   %{_libdir}/eclipse' and then proceed to use that when calling pdebuild (which needs to know the location of the platform). I guess this could be covered by defining the macro at eclipse's build time ?

But there is already eclipse-pdebuild in bin, which is always right...

My mistake. It seems the specfile just needs to be updated. the eclipse-pdbuild script uses 'datadir=`rpm --eval "%{_libdir}"`' to get the directory. This is similar to what Tycho is doing. Is this ok?

True. I have not checked that. But since it is an arch package, I can change that to contain a symlink to eclipse folder (and I think it will be legal).

(In reply to comment #7)
> 
> The suggested solution for jfreechart is:
>  {{{
>   ant -f ant/build-swt.xml \
>  -         -Dswt.jar=%{_libdir}/java/swt.jar \
>  +         -Dswt.jar=$(build-classpath swt) \
>           -Djcommon.jar=$(build-classpath jcommon) \
>           -Djfreechart.jar=lib/jfreechart-%{version}.jar
>  }}}
> 
> Is there any other case where we need %{_eclipse_base} ?

Thanks Kris! I had forgotten that jpackage-utils is now arch-specific. Jfreechart build with above change worked perfectly.

I really haven't followed here but can we close this now ?

(In reply to comment #13)
> I really haven't followed here but can we close this now ?

Ok from my point of view. jfreechart builds fine with this for a while now.

Yes - the policy is clear now:
it's ok to have dependency from noarch to arch given that noarch is really noarch - no arch specific paths is hardcoded into it. This means that we should get rid off eclipse_base (and I think we are doing it).

I'm marking it as a 'notabug' because it was rather a clarification request (and fix for jfreechart is just a side effect).