Bug 295748 - Not all binaries are recognized in imported standard make project until close/reopen
Summary: Not all binaries are recognized in imported standard make project until close...
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-core (show other bugs)
Version: 0 DD 1.1   Edit
Hardware: PC Linux
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-20 12:51 EST by Ivan Yosifov CLA
Modified: 2020-09-04 15:21 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Yosifov CLA 2009-11-20 12:51:22 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Build Identifier: M20090917-0800

The problem was experienced as a result of the poppler/cmake secenario described here. 
However I don't suppose it's specific to either poppler or cmake. The procedure is as
follows:

1) Download the poppler release http://poppler.freedesktop.org/poppler-0.12.1.tar.gz
2) Unpack somewhere resulting in a poppler-0.12.1 directory containing the sources
3) Create a build directory at the same level as poppler-0.12.1 to do the out-of-source 
   build in. Hierarchy should look like:

        $ ls
        build  poppler-0.12.1

4) cd to the build directory
5) Configure the build system with:

        cmake -G"Eclipse CDT4 - Unix Makefiles" \
              -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE \
              ../poppler-0.12.1/

   Resulting in a CDT project in the build directory that references the sources in 
   ../poppler-0.12.1/ and built using standard make files as far as CDT is concerned.

6) Import the project into eclipse ( with copy-into-workspace NOT checked )
7) Observe the project compiling. When it's done under Binaries are listed only:

        libpoppler.so
        libpoppler.so.5
        libpoppler.so.5.0.0

    However probably 30-40 other binaries that aren't listed. 
8) Close and reopen the project. Now the full list is shown. Including for example
   built utilities from the utils directory like pdftohtml, pdftoppm, pdftotext and
   many many others.

The problem was experienced using the CDT 6.0.2 pre-release builds:

cdt-master-6.0.2-I200909180606.zip
cdt-master-6.0.2-I200911200607.zip

and also using the current release build:

6.0.0.200906161748

This might be related to bug #91622 even though the platforms are different.


Reproducible: Always
Comment 1 Ivan Yosifov CLA 2009-11-20 13:09:26 EST
Restarting the IDE seems to fix the issue as well.
Comment 2 Marc-André Laperle CLA 2009-11-20 21:30:01 EST
(In reply to comment #0)
> This might be related to bug #91622 even though the platforms are different.

I don't think it's related, I can't reproduce bug 91622. On the other hand, I think your bug looks similar to Bug 293148, like I said there : "I added a linked folder with plenty of binaries and only a .a showed up. I restarted Eclipse and they all appeared." Closing and reopening the project worked as well.
Comment 3 Ivan Yosifov CLA 2009-11-21 02:49:19 EST
You cold be right. I think, however, that in this case it's the source folder that is linked. As I mentioned in the instructions above you import the build folder and that links to the sources. The binaries are under the build folder.

Also, just refreshing the project does NOT fix the issue. I wonder what restart does that refresh doesn't...