Observations from new user

[Chris Meyer-11]

I'm a new/prospective user of TagLib. I'm integrating it into a Qt
project and building on Mac OS 10.5 with Xcode but no extra ports
installed.

Here are a few observations of the trunk r1033357:

1/
The TagLib website (http://developer.kde.org/~wheeler/taglib.html)
says to get the source via

svn co svn://anonsvn.kde.org/home/kde/trunk/kdesupport

This grabs a whole lot of extra stuff (and uses unnecessary bandwidth).

svn co svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib

would work just as well, right?


2/
The taglib/taglib/taglib.pro project is incomplete. There are missing
files such as:

mpeg/id3v2/frames/privateframe.cpp \
riff/rifffile.cpp \
riff/aiff/aifffile.cpp \
riff/aiff/aiffproperties.cpp \
riff/wav/wavfile.cpp \
riff/wav/wavproperties.cpp \
mp4/mp4tag.cpp \

Also, the INCLUDES needs to include ../includes to build properly.


3/
The WITH_MP4 define is used interchangeably with the TAGLIB_WITH_MP4 define.
For instance in 'fileref.cpp' TAGLIB_WITH_MP4 is used.
In 'mp4file.cpp' WITH_MP4 is used.
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

On Sat, Oct 10, 2009 at 3:20 AM, Chris Meyer <cmeyer1969+kde@...> wrote:

> 1/
> The TagLib website (http://developer.kde.org/~wheeler/taglib.html)
> says to get the source via
>
> svn co svn://anonsvn.kde.org/home/kde/trunk/kdesupport
>
> This grabs a whole lot of extra stuff (and uses unnecessary bandwidth).
>
> svn co svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib
>
> would work just as well, right?

Yes, I thought that was the preferred way. Scott, could you please
update the page?

> 2/
> The taglib/taglib/taglib.pro project is incomplete. There are missing
> files such as:
>
> mpeg/id3v2/frames/privateframe.cpp \
> riff/rifffile.cpp \
> riff/aiff/aifffile.cpp \
> riff/aiff/aiffproperties.cpp \
> riff/wav/wavfile.cpp \
> riff/wav/wavproperties.cpp \
> mp4/mp4tag.cpp \
>
> Also, the INCLUDES needs to include ../includes to build properly.

I'm sorry, I forgot about this file. I've never used it myself. It
seems it was generated using qmake -project, so updating it *might* be
easy. I wonder if it's still necessary though. As far as I understand,
the project file was only introduced in order to build a Mac
framework. I see that CMake can create build a framework now [1].
Could somebody test if really works, please?

Btw, no, it should not include from ../includes. The "includes"
directory is a kde-specific hack which I'd like to remove. The project
file should include the necessary directories from the "taglib"
directory.

> 3/
> The WITH_MP4 define is used interchangeably with the TAGLIB_WITH_MP4 define.
> For instance in 'fileref.cpp' TAGLIB_WITH_MP4 is used.
> In 'mp4file.cpp' WITH_MP4 is used.

Yes, I should update everything back to WITH_MP4. TAGLIB_WITH_MP4 is a
public macro that is provided for applications that use TagLib, while
WITH_MP4 is a private one.

--
Lukas Lalinsky
lalinsky@...
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

2009/10/10 Lukáš Lalinský <lalinsky@...>:

>> 2/
>> The taglib/taglib/taglib.pro project is incomplete. There are missing
>> files such as:
>>
>> mpeg/id3v2/frames/privateframe.cpp \
>> riff/rifffile.cpp \
>> riff/aiff/aifffile.cpp \
>> riff/aiff/aiffproperties.cpp \
>> riff/wav/wavfile.cpp \
>> riff/wav/wavproperties.cpp \
>> mp4/mp4tag.cpp \
>>
>> Also, the INCLUDES needs to include ../includes to build properly.
>
> I'm sorry, I forgot about this file. I've never used it myself. It
> seems it was generated using qmake -project, so updating it *might* be
> easy. I wonder if it's still necessary though. As far as I understand,
> the project file was only introduced in order to build a Mac
> framework. I see that CMake can create build a framework now [1].
> Could somebody test if really works, please?

Sorry, I meant to include a link to
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:FRAMEWORK
for "[1]".

--
Lukas Lalinsky
lalinsky@...
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

[Scott Wheeler]

On Oct 10, 2009, at 8:12 AM, Lukáš Lalinský wrote:

> On Sat, Oct 10, 2009 at 3:20 AM, Chris Meyer  
> <cmeyer1969+kde@...> wrote:
>>
>> svn co svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib
>>
>> would work just as well, right?
>
> Yes, I thought that was the preferred way. Scott, could you please
> update the page?

Done.  It used to be that TagLib required some of the things that were  
higher up in the directory tree.

> As far as I understand, the project file was only introduced in  
> order to build a Mac
> framework.

That's correct.

> Btw, no, it should not include from ../includes. The "includes"
> directory is a kde-specific hack which I'd like to remove.

Incidentally, I agree.  I wasn't thrilled about those being added.  
Perhaps they could just be removed when building the tarballs; the  
idea there basically is that they were added so that Amarok / TagLib-
extras can include things directly from the svn tree without requiring  
TagLib to have first been installed.

-Scott

_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

Scott Wheeler wrote:
>> Btw, no, it should not include from ../includes. The "includes"
>> directory is a kde-specific hack which I'd like to remove.
>
> Incidentally, I agree.  I wasn't thrilled about those being added.  
> Perhaps they could just be removed when building the tarballs; the  
> idea there basically is that they were added so that Amarok / TagLib-
> extras can include things directly from the svn tree without requiring  
> TagLib to have first been installed.

As the README says:

"These are only necessary at build-time when building the entire
kdesupport module; they do not need to be installed on a running system."

When TagLib-Extras got moved to kdesupport, it introduced a dependency
problem when building the entire kdesupport module. If the system was
fresh and the TagLib includes weren't installed yet, building kdesupport
would break because TagLib-Extras would try to find the installed TagLib
includes and would fail. It got moved there in the first place because
distros complained about packaging something that lived in playground.
Apparently the same code, when in playground, is less stable or
trustworthy than when it's copied into kdesupport. No joke.

Anyways, this can change soon; either if/when the TagLib development
moves out of KDE SVN, or otherwise we can find another place for
TagLib-Extras now that most of the formats are in released TagLib.

--Jeff



_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

On Sat, Oct 10, 2009 at 4:41 PM, Jeff Mitchell <mitchell@...> wrote:
> When TagLib-Extras got moved to kdesupport, it introduced a dependency
> problem when building the entire kdesupport module. If the system was
> fresh and the TagLib includes weren't installed yet, building kdesupport
> would break because TagLib-Extras would try to find the installed TagLib
> includes and would fail.

Well, the right thing to do was to include files from the "taglib"
directory. Yes, it's more work, but duplicating the files is a larger
maintaince problem. The files were out of date even before the 1.6
release. I didn't feel comfortable updating something which I believe
is a wrong solution, but on the other hand I didn't want to break
kdesupport, so I just left them alone.

--
Lukas Lalinsky
lalinsky@...
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

Lukáš Lalinský wrote:
> On Sat, Oct 10, 2009 at 4:41 PM, Jeff Mitchell <mitchell@...> wrote:
>> When TagLib-Extras got moved to kdesupport, it introduced a dependency
>> problem when building the entire kdesupport module. If the system was
>> fresh and the TagLib includes weren't installed yet, building kdesupport
>> would break because TagLib-Extras would try to find the installed TagLib
>> includes and would fail.
>
> Well, the right thing to do was to include files from the "taglib"
> directory.

But the files in the taglib directory are all spread out over a large
number of directories, unlike when they are installed in a running system.

> Yes, it's more work, but duplicating the files is a larger
> maintaince problem.

Duplicating??

> The files were out of date even before the 1.6
> release.

They haven't been out of date since they were put there, since TagLib
hasn't had any more header files added .


--Jeff



_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel